使用 PUT 端点在 REST api 中创建资源时的状态码

Question

当你使用 PUT 端点在 REST api 中创建资源时，端点在第一次调用返回 201(created) 后应该为后续调用返回什么？ 403（无法创建，因为资源已经存在）？ 200（更新到相同的确切对象？）如果您在一次调用后更改状态码（201-> 200 或 403），那不是违反幂等性吗？我到处找，但我能找到的只是你可以使用 PUT 来创建，但没有地方说资源创建后状态代码的变化。 简而言之，我的问题是 PUT 是一种幂等方法，但是当它用于资源创建时，它仍然可以从以下调用中更改它的返回状态码吗？

附言 第一次调用后，它将是幂等的（恒定为 403 或 200）。理想情况下，我希望能够告诉客户资源已经创建，你不应该再次调用它。（403） 我知道使用 POST 是一种替代方法，但由于客户端在创建时已经知道 ID，我想使用 PUT 方法，但想知道在幂等性方面正确的 REST 方式。

================================================ ===================== 使用 PUT 端点创建资源的参考资料 http://restcookbook.com/HTTP%20Methods/put-vs-post/ https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

POST 和 PUT 请求的根本区别在于 体现在Request-URI的不同含义上。 URI 中的 POST 请求标识将处理封闭的资源 实体。该资源可能是一个数据接受过程，一个通往 其他一些协议，或接受注释的单独实体。在 相反，PUT 请求中的 URI 标识用 请求——用户代理知道 URI 是什么意思 9.6。 PUT 如果创建了新资源，源服务器必须通过 201（已创建）响应通知用户代理。如果现有资源 被修改，200 (OK) 或 204 (No Content) 响应代码 应该发送以指示请求成功完成。

http://zalando.github.io/restful-api-guidelines/http/Http.html

PUT 请求通常对不存在的资源具有鲁棒性： 更新前隐式创建

成功的 PUT 请求通常会生成 200 或 204（如果 资源已更新 - 有或没有返回实际内容），并且 201（如果资源已创建）

Answer 1

幂等性与服务器状态有关，与响应无关。例如。 DELETE 是幂等的，但是在第二次尝试后将找不到资源，您可以选择响应 404。但是服务器的状态将是相同的 - 资源被删除。

与 PUT 相同 - 您可以多次调用它，但操作完成后服务器的状态将始终相同。

理想情况下，您可以重用 PUT 来更新资源。因此，当第二个请求到达时，您可以将其用于更新而不是返回错误。这可能会简化实施和合同。