问Restful这是一个很好的实践吗，对于相同的插入api，根据操作返回不同的HttpStatusCode。

EN

忍者编辑我的答案没有多大意义，因为我误解了这个问题，我认为OP使用的是PUT而不是POST。

原始答案

是的，这是一个很好的实践，创建新资源的最佳方法是PUT，因为它是幂等的，并且具有非常特殊的意义(在目标URI处创建/替换资源)。

许多人使用POST创建的原因有一个特定的原因:在许多情况下，客户端无法确定新资源的目标URI。这方面的标准示例是如果URL中有自动递增的数据库ids。但对此并不适用。

因此，PUT可能是您创建的缺省值，如果客户端不控制名称空间，则应该使用POST。实际上，大多数API属于第二类。

并且返回201/200/204取决于是否创建或更新了一个资源也是一个很好的想法。

修订版

我认为，在不知道URI的情况下，使用一种方法“插入”一个项是一种有用的优化。我认为我用于构建API的一般设计是标准管道应该就位(CRUD，每个项目1个资源)。

但是，如果情况需要优化，我通常会将这些优化放在这些标准之上。我不会避免优化，而是在必要的基础上采用它们。知道每个资源是否都有URI仍然很好，而且我有一个URI，我可以在它上调用PUT。

但是，根据自己的身体创建或更新已经存在的内容的POST请求应该：

• 如果创建了新的内容，则返回201 Created和Location头。
• 如果进行了更新，我可能会返回200 OK +更新内容的完整资源主体+现有资源的Content-Location头。
• 或者，这个post端点还可以返回指向更新资源的303 See Other和Location头。
• 或者，我也希望至少发送一个Link: </updated-resource>; rel="invalidates"头，向客户端提示，如果他们有资源的缓存，那么这个缓存现在是无效的。

那么，通过让相同的api返回不同的statusCode (200,201)，基于不同的操作(更新、创建)，这是一个很好的实践吗？

是的如果..。要记住的关键是，HTTP状态代码是通过网络传输文档的元数据。因此，当处理POST请求的结果包括在web服务器上创建新资源时，返回201是合适的，因为当前的HTTP标准规定您应该这样做(请参阅RFC 9110)。

我认为我们应该有两个单独的api来处理更新和创建。

“视情况而定”。HTTP确实希望您将更改文档的请求发送到已更改的文档(请参阅RFC 9111)。考虑这一点的一种方法是，您的HTTP请求处理程序实际上只是一个外观，它应该使您的服务看起来像一个通用文档存储(也就是一个网站)。

使用相同的资源标识符，无论是保存新文档还是保存修改后的文档，都是非常正常的事情。

这绝对是您想要使用PUT语义和贫血文档存储所做的事情。

POST可能有点奇怪，因为请求的目标URI不一定与将要创建的文档的URI相同(例如，在资源模型中，服务器而不是客户端负责选择资源标识符)。一个常见的示例是通过向collection资源发送请求来存储新文档，该资源更新自身并为正在创建的新item资源选择标识符。

(注意:向集合发送更新项的请求是一个奇怪的选择。)