您能否确认以下 PUT 与 POST 的实现是否违反 REST 原则：
如果资源是通过 POST 创建的，则允许通过 POST 更新资源（否则返回 412 错误） 如果资源是通过 PUT 创建的，则允许通过 PUT 更新资源（否则返回 412 错误）
我了解 PUT 和 POST 都可用于创建资源。在这种情况下，我认为不正确的是依赖于资源的创建方式（PUT/POST）并根据它采取行动。你能指出我的 RFC 吗？
【问题讨论】：
标签： rest
如果资源是通过 POST 创建的，则允许通过 POST 更新资源（否则返回 412 错误） 如果资源是通过 PUT 创建的，则允许通过 PUT 更新资源（否则返回 412 错误）
您能否确认以下 PUT 与 POST 的实现是否违反 REST 原则
这可能是错误的，但不一定如此。
特别是，HTTP 中的PUT 具有非常具体的语义
PUT 方法请求创建目标资源的状态或将其替换为请求消息负载中包含的表示定义的状态。
也就是说，PUT 适合替换，但不适合修改。
因此，您的指南实际上暗示的是，如果您通过其表示的 PUT 创建资源，那么对该资源的所有后续更改也必须是完全替换。
对我来说这不是一个好主意，而且 HTTP 中没有什么要求你这么严格；但您的指南作者肯定有一些不好的经历，这可能与这些指南适用的情况有关。
关于使用 412 响应的注意事项是……奇怪。同样，在 HTTP 中，412 具有非常特定的含义；并且该含义与请求中使用的方法无关。使用条件请求来确保您的编辑不会与其他编辑冲突是个好主意。
但如果有人在应该执行 PUT 的地方执行了 POST，反之亦然，那么在这种情况下返回的正确状态代码是 405。
405 (Method Not Allowed) 状态码表示请求行中接收到的方法是源服务器已知的，但目标资源不支持。源服务器必须在 405 响应中生成 Allow 标头字段，其中包含目标资源当前支持的方法列表。
你能告诉我 RFC 吗？
REST 没有“RFC”；从这个意义上说，它不是一个标准。 REST 只是 Roy T. Fielding 在早期 Web 标准化过程中发现的一组架构约束。适当的参考是菲尔丁论文的Chapter 5。
HTTP 作为标准确实（在大多数情况下）使用满足 REST 约束的架构。截至 2016 年底，该标准由 RFC 7230-7235 （包括）记录。
【讨论】：
RESTful URL 通常指向collection 或element。
collection 通常以复数形式表示，可能如下所示：
@987654321@
element 通常使用其标识符进行寻址，可能如下所示：
@987654322@
Collections 可以是elements 的子代：
<code>https://www.example.com/api/v1/workplaces/22/rooms</code>
对collection 执行POST 通常意味着在collection 中创建element，并且新的element 通常与响应一起返回。服务器将负责为新创建的元素创建URI。这是创建elements 的推荐“RESTful”方式。
对element 执行POST 并不经常使用（并且不鼓励），因为这意味着客户端将是分配identifier 的人。如果使用，大多数情况下，这意味着您将element 本身视为collection，并在其中创建一个新的element。
对collection 执行PUT 是完全有效的“RESTful”，但通常意味着替换整个collection。
将PUT 替换为element 很常见，通常意味着替换整个element，这意味着整个element 应该在请求正文中传递。有人认为如果 element 不存在就创建它是可以的（但我认为这是一个错误的请求）。
对element 执行PATCH 通常意味着更新element。应该更新的字段是请求正文中唯一需要的字段。
我从来没有偶然发现将PATCH 改为collection，我可能会建议不要这样做。
【讨论】：