Http请求方式的正确使用场景



前言

我们从大一刚开始学习Java到现在已经写了两三次项目后,我们的编程能力在逐渐提升,但是有个很容易忽略的点,虽然说平时对开发没有太大的影响,但是即使是很小的错误,都极有可能会对我们未来的开发和工作造成打击性的影响。所以今天我就来记录一下这个学习过程。


一、问题引入

时日至今,我很荣幸能够成为一名web后端学习者,在我们前后端合作写项目的同时,我们后端的任务就是维护数据和写接口,总所周知,接口决定了一个功能的实现,所以对于接口的问题,就是http的请求方式的正确与否。

依稀记得,我们第一次写项目,由于对http请求方式不是很了解,所以使用的最多的就是post请求和get请求,当时只是简单的记得,post请求能够隐藏请求参数,get请求的参数会加在url后面。当时这种简单的认知只是觉得虽然说是这样,但是其实并没有太大的区别,就是说,登录使用post,其他的都行。但是其实这种是不对的,每种请求方式都有自己的特性,使用的方式、场景也不尽相同。

印象最深刻的一次,就是我当时在网上查资料学习了一些关于这些http请求方式的知识,并且当时在项目中使用了,我们的前端人员竟然问我,这种请求方式是什么,怎么没有见过。我当时觉得这并没有什么,但是随着知识、项目的学习,我觉得这些却变得极其重要了起来。

下面就让我们一起来学习下,http几种请求方式吧。


二、http几种请求方式的使用


1.GET

(1)get请求是用来获取数据的,就是说只是用来查询数据,不对服务器的数据进行任何的修改、添加、删除等操作,就可以使用get请求;

(2)get请求会把请求的参数加在url后面,这样会产生安全问题,稍微懂点编程的人员都可以通过url来获取你网址的参数和值;

(3)get请求的参数对于请求的url来说并没有大小限制,但是对于不同的浏览器可能会有不同的限制。

//比如,使用id来查询演员信息
@GetMapping("/findActorMessage")
public Result findActorMessage(Integer actorId) {
    return actorService.findActorMessage(actorId);
}

 这样的话,对于接口的请求的url就是以下这种

Request URL:
    http://localhost:8080/video/actor/findActorMessage?actorId=1

2.POST

(1)post请求一般是对服务器的数据的操作,常用来使用数据的提交,新增操作,这种请求会改变数据的种类等资源;几乎目前所有的提交操作都是通过post来实现;

(2)post请求的请求参数一般都是放在请求体中,不会显示在url后面

(3)post请求的大小也会被服务器限制,这种限制的主要因素是服务器的处理能力。

    //用于向数据库添加用户操作
    @PostMapping("/addUser")
    public ResponseResult addUser(User user) {
        User user1 = userService.findUserByAccount(user.getAccount());
        if (user1 == null) {
            userService.addUser(user);
            return ResponseResult.success("添加成功");
        } else {
            return ResponseResult.error("用户已存在");
        }
    }

这种方式的请求URL如下 

Request URL
    http://localhost:8080/video/user/addUser?account=zzal123456&password=123456

 但是post中的请求参数会隐藏在方法的请求体当中。

3.PUT

 (1)PUT请求是向服务端发送数据、改变信息的,即使POST和PUT请求一样都会改变服务器的数据,但是PUT的侧重点在于对数据的修改操作,而POST则是对数据的添加操作;

(2)PUT请求需要注意的是,虽然和POST请求的执行都是改变动作,但是它采用的参数传递需要使用query格式,否则是拿不到传递的参数的,也就是说如果不使用query格式,那么就只能享受空指针异常了。

    //这里用于修改操作
    @ApiOperation(value = "用户修改邮箱")
    @PutMapping("/findAllUser")
    public ResponseResult updateEmail(String email, int userId) {
        return userService.updateEmail(email, userId);
    }

4.DELETE

 DELETE请求顾名思义,很简单,就是删除资源,一般用于数据库数据的删除操作,这里不再赘述。

   //这里用于删除操作
    @ApiOperation(value = "根据id删除用户")
    @DeleteMapping("/deleteById")
    public ResponseResult deleteById(int userId) {
        User user = userService.findUserById(userId);
        int i = userService.deleteUserById(userId);
        if (i > 0) {
            return ResponseResult.success("删除成功", user);
        } else {
            return ResponseResult.error("抱歉未找到");
        }
    }

5.HEAD

(1)HEAD请求与GET请求类似,区别在于它只是请求页面的头信息,用来获取报头信息,返回的响应中没有内容,GET请求的返回中有实体信息。

(2)HEAD请求一般用来判断类型、根据返回状态确定资源是否存在、资源是否更新以及更新的时间等。

(3)HEAD请求常常被忽略,但是能提供很多的有效信息,特点主要有:只请求资源的头部、可以检查超链接的有效性、检查网页是否被修改、更多用于自动搜索机器人获取页面的某些认证信息等。

6.OPTIONS

(1)由于OPTIONS请求暂时我还没有接触到,所以此部分只是查询资料后总结,这里只是对这种请求方式的简单介绍。

(2)OPTIONS请求是用于获取由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项,通过这个方法,客户端可以在才取具体资源之前,决定对该资源采用何种必要措施,或者了解服务器的性能;

(3)POPTIONS请求方法的主要用途有两个:

        1)获取服务器支持的HTTP请求方法;

        2)用来检查服务器的性能。



总结

以上的http的请求方式基本上可以满足我们现阶段的开发需求,同时,正确使用请求方式也是一个小的细节,希望能对大家有所帮助。

### 关于Spring Security处理`/error`请求 在Spring Security框架中,当客户端访问未授权资源或者发生异常时,默认情况下会触发`/error`请求。此行为通常由嵌入式Servlet容器(如Tomcat)提供支持,并且可以通过自定义配置来调整其响应逻辑。 #### 默认错误处理机制 默认情况下,Spring Boot应用程序中的`/error`映射到`BasicErrorController`类[^1]。该控制器负责捕获所有未匹配的异常并将其转换为HTTP响应。如果启用了Spring Security,则会对这些请求应用安全约束。这意味着即使是一个简单的错误页面也可能受到身份验证或授权的要求。 #### 自定义`/error`请求的方式 为了实现更灵活的行为,可以采取以下几种方法来自定义`/error`请求: 1. **通过覆盖Default Error Page** 可以创建一个新的HTML文件作为全局错误页,并指定它用于显示所有的服务器端错误消息。 ```html <!-- src/main/resources/templates/error.html --> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Error</title> </head> <body> <h1>Oops! Something went wrong.</h1> <p>Status Code: {{ status }}</p> <p>Message: {{ message }}</p> </body> </html> ``` 2. **修改Security Configuration** 使用`HttpSecurity`对象允许特定路径无需认证即可访问,从而确保错误信息能够正常传递给用户代理而不会再次陷入循环重定向问题。 ```java @Configuration public class WebSecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/error").permitAll() // Allow access to the error endpoint without authentication. .anyRequest().authenticated(); http.csrf().disable(); // Disable CSRF protection for simplicity (not recommended in production). } } ``` 3. **注册Custom ErrorHandler Bean** 实现自己的`ErrorHandler` bean 并注入到上下文中替代原有的实例。这样做的好处是可以完全掌控如何呈现最终的结果形式以及附加额外的数据字段至JSON响应体里去满足API消费者的需求。 ```java import org.springframework.boot.web.servlet.error.ErrorAttributes; import org.springframework.context.annotation.Bean; import org.springframework.http.HttpStatus; import org.springframework.stereotype.Component; @Component public class CustomErrorHandling { @Bean public ErrorAttributes customErrorAttributes(){ return new DefaultErrorAttributes() { @Override public Map<String, Object> getErrorAttributes(WebRequest webRequest, boolean includeStackTrace){ Map<String,Object> errorAttributes = super.getErrorAttributes(webRequest,includeStackTrace); HttpStatus statusCode = getStatus(webRequest).orElse(HttpStatus.INTERNAL_SERVER_ERROR); String errorMessage = "An unexpected condition was encountered."; if(errorAttributes.containsKey("message")){ errorMessage = errorAttributes.get("message").toString(); } Map<String,String> responseMap=new HashMap<>(); responseMap.put("status",String.valueOf(statusCode.value())); responseMap.put("error",errorMessage); return Collections.unmodifiableMap(responseMap); } }; } } ``` 以上三种策略可以根据实际项目需求单独采用或是组合运用达到理想效果的同时兼顾安全性考量[^2][^3]. ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值