使用PUT端点在REST API中创建资源时的状态码
当您使用PUT端点在REST API中创建资源时，在第一次调用返回201（创建）之后，端点应该为后续调用返回什么？ 403（由于资源已经存在，无法创建）？ 200（更新到同一确切对象？），如果您在一次调用（201-> 200或403）后更改状态代码，是不是违反幂等性？ 我到处寻找，但所有我能找到的是您可以使用PUT创建，但在创建资源之后它没有提到状态代码更改。 总之，我的问题是PUT是一个幂等方法，但是当它用于资源创建时，它是否仍然可以通过以下调用更改它的返回状态代码？
ps第一次调用后，它将是幂等的（一直为403或200）。 理想情况下，我希望能够告诉客户端资源已经创建，并且不应该再次调用它（403）。我知道使用POST是一种选择，但是由于在创建时已经知道客户端ID想要使用PUT方法，但想知道在幂等性方面适当的REST方法。
================================================== =================使用PUT端点创建资源的参考http://restcookbook.com/HTTP%20Methods/put-vs-post/ https：//www.w3 .ORG /协议/ RFC2616 / RFC2616-sec9.html
POST和PUT请求之间的根本区别反映在请求URI的不同含义中。 POST请求中的URI标识将处理封闭实体的资源。 该资源可能是数据接受过程，其他协议的入口或接受注释的独立实体。 相比之下，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（如果资源已创建）
幂等性是关于服务器状态 - 而不是关于响应。 例如DELETE是幂等的，但在第二次尝试之后，资源将不会被找到，并且您可以选择以404响应。但是服务器的状态将会相同 - 资源将被删除。
与PUT一样 - 您可以多次调用它，但操作完成后服务器的状态将始终保持不变。
理想情况下，尽管您可以重用PUT来更新资源。 所以当第二个请求到达时，你可以使用它来更新而不是返回错误。 这可能会简化实施和合同。
链接地址: http://www.djcxy.com/p/7099.html上一篇: Status code when using PUT endpoint to create resource in REST api