面试高频:什么是接口的幂等性,如何实现接口幂等性?

本文探讨了接口幂等性的概念及其重要性,包括唯一索引、乐观锁、悲观锁和分布式锁等解决方案。重点介绍了使用token机制实现接口幂等性的详细步骤,涉及token的生成、验证以及配置拦截器和Redis存储。通过实例展示了如何确保在并发请求下,接口操作仅执行一次。

推荐阅读:

(一)幂等性概念

幂等性原本是数学上的概念,用在接口上就可以理解为:同一个接口,多次发出同一个请求,必须保证操作只执行一次。 调用接口发生异常并且重复尝试时,总是会造成系统所无法承受的损失,所以必须阻止这种现象的发生。 比如下面这些情况,如果没有实现接口幂等性会有很严重的后果: 支付接口,重复支付会导致多次扣钱 订单接口,同一个订单可能会多次创建。

(二)幂等性的解决方案

唯一索引 使用唯一索引可以避免脏数据的添加,当插入重复数据时数据库会抛异常,保证了数据的唯一性。

乐观锁 这里的乐观锁指的是用乐观锁的原理去实现,为数据字段增加一个version字段,当数据需要更新时,先去数据库里获取此时的version版本号

select version from tablename where xxx

更新数据时首先和版本号作对比,如果不相等说明已经有其他的请求去更新数据了,提示更新失败。

update tablename set count=count+1,version=version+1 where version=#{version}

悲观锁 乐观锁可以实现的往往用悲观锁也能实现,在获取数据时进行加锁,当同时有多个重复请求时其他请求都无法进行操作

分布式锁 幂等的本质是分布式锁的问题,分布式锁正常可以通过redis或zookeeper实现;在分布式环境下,锁定全局唯一资源,使请求串行化,实际表现为互斥锁,防止重复,解决幂等。

token机制 token机制的核心思想是为每一次操作生成一个唯一性的凭证,也就是token。一个token在操作的每一个阶段只有一次执行权,一旦执行成功则保存执行结果。对重复的请求,返回同一个结果。token机制的应用十分广泛。

(三)token机制的实现

这里展示通过token机制实现接口幂等性的案例:github文末自取 首先引入需要的依赖:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-lang3</artifactId>
    <version>3.4</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

3.1、配置请求的方法体和枚举类

首先配置一下通用的请求返回体

public class Response {
    private int status;
    private String msg;
    private Object data;
    //省略get、set、toString、无参有参构造方法
}

以及返回code

public enum ResponseCode {
    // 通用模块 1xxxx
    ILLEGAL_ARGUMENT(10000, "参数不合法"),
    REPETITIVE_OPERATION(10001, "请勿重复操作"),
    ;
    ResponseCode(Integer code, String msg) {
        this.code = code;
        this.msg = msg;
    }
    private Integer code;
    private String msg;
    public Integer getCode() {
        return code;
    }
    public void setCode(Integer code) {
        this.code = code;
    }
    public String getMsg() {
        return msg;
    }
    public void setMsg(String msg) {
        this.msg = msg;
    }
}

3.2 自定义异常以及配置全局异常类

public class ServiceException extends RuntimeException{
    private String code;
    private String msg;
    //省略get、set、toString以及构造方法
}

配置全局异常捕获器

@ControllerAdvice
public class MyControllerAdvice {
    @ResponseBody
    @ExceptionHandler(ServiceException.class)
    public Response serviceExceptionHandler(ServiceException exception){
        Response response=new Response(Integer.valueOf(exception.getCode()),exception.getMsg(),null);
        return response;
    }
}

3.3 编写创建Token和验证Token的接口以及实现类

@Service
public interface TokenService {
    public Response createToken();
    public Response checkToken(HttpServletRequest request);
}

具体实现类,核心的业务逻辑都写在注释中了

@Service
public class TokenServiceImpl implements TokenService {

    @Autowired
    private RedisTemplate redisTemplate;

    @Override
    public Response createToken() {
        //生成uuid当作token
        String token = UUID.randomUUID().toString().replaceAll("-","");
        //将生成的token存入redis中
        redisTemplate.opsForValue().set(token,token);
        //返回正确的结果信息
        Response response=new Response(0,token.toString(),null);
        return response;
    }

    @Override
    public Response checkToken(HttpServletRequest request) {
        //从请求头中获取token
        String token=request.getHeader("token");
        if (StringUtils.isBlank(token)){
            //如果请求头token为空就从参数中获取
            token=request.getParameter("token");
            //如果都为空抛出参数异常的错误
            if (StringUtils.isBlank(token)){
                throw new ServiceException(ResponseCode.ILLEGAL_ARGUMENT.getCode().toString(),ResponseCode.ILLEGAL_ARGUMENT.getMsg());
            }
        }
        //如果redis中不包含该token,说明token已经被删除了,抛出请求重复异常
        if (!redisTemplate.hasKey(token)){
            throw new ServiceException(ResponseCode.REPETITIVE_OPERATION.getCode().toString(),ResponseCode.REPETITIVE_OPERATION.getMsg());
        }
        //删除token
        Boolean del=redisTemplate.delete(token);
        //如果删除不成功(已经被其他请求删除),抛出请求重复异常
        if (!del){
            throw new ServiceException(ResponseCode.REPETITIVE_OPERATION.getCode().toString(),ResponseCode.REPETITIVE_OPERATION.getMsg());
        }
        return new Response(0,"校验成功",null);
    }
}

3.4 配置自定义注解

这是比较重要的一步,通过自定义注解在需要实现接口幂等性的方法上添加此注解,实现token验证

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface ApiIdempotent {
}

接口拦截器

public class ApiIdempotentInterceptor implements HandlerInterceptor {
    @Autowired
    private TokenService tokenService;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if (!(handler instanceof HandlerMethod)) {
            return true;
        }
        HandlerMethod handlerMethod= (HandlerMethod) handler;
        Method method=handlerMethod.getMethod();
        ApiIdempotent methodAnnotation=method.getAnnotation(ApiIdempotent.class);
        if (methodAnnotation != null){
            // 校验通过放行,校验不通过全局异常捕获后输出返回结果
            tokenService.checkToken(request);
        }
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
    }
}

3.5 配置拦截器以及redis

配置webConfig,添加拦截器

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(apiIdempotentInterceptor());
    }

    @Bean
    public ApiIdempotentInterceptor apiIdempotentInterceptor() {
        return new ApiIdempotentInterceptor();
    }
}

配置redis,使得中文可以正常传输

@Configuration
public class RedisConfig {
    //自定义的redistemplate
    @Bean(name = "redisTemplate")
    public RedisTemplate<String,Object> redisTemplate(RedisConnectionFactory factory){
        //创建一个RedisTemplate对象,为了方便返回key为string,value为Object
        RedisTemplate<String,Object> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        //设置json序列化配置
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer=new
                Jackson2JsonRedisSerializer(Object.class);
        ObjectMapper objectMapper=new ObjectMapper();
        objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        objectMapper.activateDefaultTyping(LaissezFaireSubTypeValidator.instance);
        //string的序列化
        StringRedisSerializer stringRedisSerializer=new StringRedisSerializer();
        //key采用string的序列化方式
        template.setKeySerializer(stringRedisSerializer);
        //value采用jackson的序列化方式
        template.setValueSerializer(jackson2JsonRedisSerializer);
        //hashkey采用string的序列化方式
        template.setHashKeySerializer(stringRedisSerializer);
        //hashvalue采用jackson的序列化方式
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        template.afterPropertiesSet();
        return template;
    }
}

最后是controller

@RestController
@RequestMapping("/token")
public class TokenController {
    @Autowired
    private TokenService tokenService;

    @GetMapping
    public Response token(){
        return tokenService.createToken();
    }

    @PostMapping("checktoken")
    public Response checktoken(HttpServletRequest request){
        return tokenService.checkToken(request);
    }
}

(四)结果验证

首先通过token接口创建一个token出来,此时redis中也存在了该token

在jmeter中同时运行50个请求,我们可以观察到,只有第一个请求校验成功,后续的请求均提示请勿重复操作。

<think>好的,我现在需要回答用户关于HTTP请求方法中GET和POST的区别,特别是安全性与幂等性的问题。首先,我需要回顾一下HTTP协议的基础知识,确保自己理解正确。 用户之前询问了TCP的三次握手和四次挥手,现在转向应用层的HTTP方法,说明他们可能在准备面试或学习网络协议。因此,回答需要结构清晰,重点突出区别,并且涵盖常见的面试考点,比如安全性和幂等性。 首先,我应该明确HTTP的常见方法,但用户主要关注GET和POST。需要先分别解释这两个方法的基本用途,然后对比它们的区别。安全性和幂等性是关键点,这两个概念需要准确解释,避免混淆。 安全性在HTTP中的定义是指方法是否会对服务器资源产生修改。根据RFC规范,安全的方法不应该修改资源,所以GET是安全的,而POST不是。但要注意,虽然GET被设计为安全,但实际应用中如果服务器端处理不当,可能通过GET请求修改数据,但这不符合规范。需要强调规范定义与实际实现的区别。 幂等性是指多次执行同一请求的效果是否相同。GET、PUT、DELETE都是幂等的,而POST不是。幂等性对客户端重试和网络通信很重要,比如在请求失败时,幂等方法可以安全地重试,而非幂等方法则可能需要额外处理。 接下来需要考虑其他区别,比如参数位置:GET参数在URL中,POST在请求体中。这导致GET的参数有长度限制,且可能被日志记录,存在安全隐患,比如密码不应该用GET传输。此外,缓存机制不同,GET可以被缓存,POST通常不行。 用户可能还关心实际应用中的选择,比如何时用GET何时用POST。需要给出例子,比如获取数据用GET,提交表单用POST。同时,可以提到RESTful API设计中对这些方法的应用。 在测试方面,可能需要验证GET请求是否没有副作用,POST是否正确处理数据,幂等性是否正确实现。比如,重复提交POST可能导致多次创建资源,而重复GET则不会改变资源状态。 需要注意常见的误解,比如认为POST比GET更安全。虽然POST数据不在URL中,但如果不使用HTTPS,数据依然可能被截获。安全性更多依赖于传输加密而非方法本身。 最后,总结关键点,确保覆盖安全性和幂等性,以及其他主要区别。结构清晰,分点列出,便于用户理解和记忆。可能还需要准备一些面试题示例,比如“为什么POST不是幂等的?”或“GET请求可以有body吗?”(虽然规范不禁止,但一般不建议) 需要检查是否有遗漏点,比如其他HTTP方法(如PUT、DELETE)的提及是否必要,但用户问题明确是GET vs POST,所以可能不需要展开。确认所有技术细节准确,比如幂等性的定义是否符合RFC标准,避免错误。 现在组织这些思路,分步骤解释,确保逻辑连贯,示例恰当,并且符合用户要求的格式,使用中文,行内公式正确(虽然这个问题可能不需要数学公式,但如果有相关内容需要表达,比如编码方式,可能需要使用)。不过当前问题可能不涉及数学表达式,所以主要使用清晰的结构和重点突出的对比。</think>以下是关于**HTTP请求方法GET与POST区别**的详细解析,重点关注安全性与幂等性,并结合实际场景与面试问题说明: --- ### **一、核心区别概览** | **特性** | **GET** | **POST** | |----------------|----------------------------------|----------------------------------| | **设计目的** | 获取资源(查询) | 提交数据(修改资源) | | **参数位置** | URL末尾(`?key=value`) | 请求体(Body) | | **数据长度限制**| URL长度限制(通常≤2048字符) | 无硬性限制 | | **缓存** | 可被缓存 | 通常不被缓存 | | **历史记录** | 参数保留在浏览器历史 | 参数不保留 | | **安全性** | 不安全(参数暴露) | 相对安全(但依赖HTTPS) | | **幂等性** | 幂等 | 非幂等 | --- ### **二、关键概念深入** #### **1. 安全性(Safety)** - **定义**:HTTP方法是否会对服务器资源产生修改(RFC 7231标准)。 - **GET的安全性**: - 设计上**不应对服务器数据产生副作用**(仅用于读取)。 - *实际风险*:若服务端错误实现GET接口(如用GET删除数据),仍可能导致数据修改。 - *测试用例*:验证GET请求是否触发非查询操作(如数据库写操作)。 - **POST的非安全性**: - 设计用于**提交数据**(如创建订单、修改用户信息)。 - *典型场景*:表单提交、文件上传。 #### **2. 幂等性(Idempotency)** - **定义**:**多次执行同一请求**的效果与**单次执行相同**。 - **GET的幂等性**: - 多次获取同一资源不会改变服务器状态(如刷新页面)。 - *测试验证*:重复发送GET请求,检查响应数据一致性。 - **POST的非幂等性**: - 多次提交可能产生**不同结果**(如重复提交订单会创建多个订单)。 - *解决方案*:服务端需实现防重机制(如Token校验、唯一ID)。 --- ### **三、实际场景与面试问题** #### **1. 参数传输方式** - **GET示例**: ```bash GET /search?q=HTTP+methods HTTP/1.1 Host: example.com ``` - *风险*:敏感数据(如`token`)通过URL暴露,可能被浏览器历史或日志记录。 - **POST示例**: ```bash POST /submit-form HTTP/1.1 Host: example.com Content-Type: application/json {"username": "test", "password": "123456"} ``` - *注意*:即使使用POST,未加密传输(HTTP)仍可能被中间人截获。 #### **2. 缓存机制** - **GET缓存优化**: - 浏览器自动缓存GET响应,可通过`Cache-Control`头控制。 - *测试关注点*:验证缓存策略是否导致数据过期(如商品价格未更新)。 - **POST禁用缓存**: - 默认不缓存,需显式设置`Cache-Control: no-store`。 #### **3. 高频面试题** - **“POST比GET更安全吗?”** - **答案**: - **传输安全性**:两者在不使用HTTPS时均不安全。 - **设计安全性**:POST参数不在URL中,减少了被直接暴露的风险。 - **“如何实现幂等的POST请求?”** - **方案**: 1. 服务端生成唯一ID(如UUID),拒绝重复ID的请求。 2. 客户端预先生成ID并附带在请求中。 - **“GET请求可以有Body吗?”** - **RFC规范**:允许,但**无实际意义**(服务器可能忽略)。 - *实际开发*:避免使用,主流框架(如Spring)可能不支持解析GET的Body。 --- ### **四、测试与调试技巧** 1. **抓包验证**: - 使用**Charles**或**Wireshark**检查GET/POST参数位置与加密情况。 2. **幂等性测试**: - 对POST接口重复发送相同请求,观察是否产生多个资源。 3. **安全扫描**: - 使用**OWASP ZAP**检测GET参数是否泄露敏感信息。 --- ### **五、总结** - **选择依据**: - 用**GET**:获取数据、过滤查询、书签分享。 - 用**POST**:提交数据、涉及敏感信息、非幂等操作。 - **核心注意**: - 安全依赖HTTPS,而非仅靠POST! - 幂等性是服务端逻辑设计的关键约束。 ```plaintext # 示例:RESTful API设计原则 GET /users → 获取用户列表 POST /users → 创建新用户(非幂等) GET /users/{id} → 获取单个用户 PUT /users/{id} → 全量更新用户(幂等) DELETE /users/{id} → 删除用户(幂等) ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值