在GET请求中实现getOrCreateIfNotExist是否符合REST最佳实践？

首先明确REST规范的核心原则：GET请求应该是幂等、无副作用的只读操作，仅用于获取资源，不应该修改服务器端的状态（比如创建实体）。基于这个原则，我们来分析你提到的两种实现方式：

两种实现的问题分析 #

第一种实现 #

直接在@GetMapping方法中调用创建逻辑，本质上是让GET请求触发了资源创建操作，违反了GET的语义约定。这种做法会带来几个问题：

• 客户端通常预期GET请求不会改变服务器状态，容易引发误解；
• 可能导致缓存异常（比如CDN、浏览器缓存了首次GET的空响应，但服务器已经创建了资源，后续请求无法获取到最新数据）；
• 不符合REST架构的设计理念，不利于接口的可维护性和扩展性。

第二种实现 #

在@GetMapping中先查询，不存在则调用@PostMapping的create方法，本质和第一种没有区别——依然是在GET请求中修改了服务器状态。额外的问题包括：

• 代码逻辑混乱：GET方法内部调用POST方法的业务逻辑，打破了HTTP方法的语义边界；
• 如果create方法未做幂等处理，重复的GET请求可能导致重复创建资源；
• POST方法的权限校验、参数处理逻辑可能与GET不一致，容易引入潜在bug。

最佳实践方案 #

如果业务上需要实现"获取或创建"的功能，正确的做法是：

1. 遵循REST语义拆分请求：让客户端先发起GET请求查询资源，若不存在则发起POST请求创建资源。这是最符合规范的方式，清晰明确，也便于客户端理解和维护。

2. 用POST请求实现单接口的getOrCreate：如果必须在单个请求中完成该操作，应该使用@PostMapping来定义这个端点，因为POST语义允许创建/修改资源，允许有副作用。示例代码如下：

@PostMapping("/get-or-create")
public List<SOMEOBJECT> getOrCreateIfNotExist(SOME DATA) {
    return questionService.getOrCreateIfNotExist(SOME DATA);
}

如果业务场景限制必须使用GET（比如某些客户端只能发送GET请求），这属于妥协方案，需要注意：

• 确保getOrCreateIfNotExist是幂等操作（重复请求不会创建重复资源）；
• 在接口文档中明确标注该GET请求会创建资源，存在副作用，避免客户端误解。

内容的提问来源于stack exchange，提问作者Oleksandr Zhytariuk