当您使用PUT端点在REST api中创建资源时，在第一次调用返回201（已创建）后，端点应该为后续调用返回什么？ 403（自资源已经存在以来无法创建）？ 200（更新为同一个确切的对象？）如果您在一次通话（201-> 200或403）后更改状态代码，是不是违反了幂等性？我到处寻找，但我能找到的是你可以使用PUT来创建但是在资源创建之后它没有说明状态代码的变化。 简而言之，我的问题是PUT是一种幂等方法，但是当它用于资源创建时，它是否仍然可以通过以下调用更改它的返回状态代码？
P.S。 第一次通话后，它将是幂等的（不断为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（无内容）响应代码 应该被发送以表示请求的成功完成。
http://zalando.github.io/restful-api-guidelines/http/Http.html
PUT请求通常可以抵御资源的不存在 在更新之前隐式创建
成功的PUT请求通常会产生200或204（如果是 资源已更新 - 有或没有返回实际内容），和 201（如果资源已创建）
答案 0 :(得分：1)
Idempotency是关于服务器状态 - 而不是关于响应。例如。 DELETE是幂等的，但在第二次尝试后，将找不到资源，您可以选择使用404进行响应。但是服务器的状态将是相同的 - 资源被删除。
与PUT相同 - 您可以多次调用它，但在操作完成后服务器的状态将始终相同。
理想情况下，您可以重复使用PUT来更新资源。因此，当第二个请求到达时，您可以使用它进行更新而不是返回错误。这可能会简化实施和合同。