我正在尝试为我正在研究的项目上的PUT请求定义约定，我无法确定这两个选项中的哪一个最合适，或者是否是个人喜好。我看过多篇有关REST最佳实践的文章，而且似乎总是在需要时将ID隐含为PUT请求的url的一部分。
目标：通过REST API更新资源。
选项
问题
PUT替换指定uri处的资源。
所以，如果您PUT collection，我希望整个集合都将被覆盖。
所以这实际上不是意见问题，在这种情况下，这完全是错误的事情。
确保您理解PUT的语义很重要>
给定表示形式的成功PUT建议在相同目标资源上进行后续GET将导致在200（OK）响应中发送等效表示形式。
换句话说
PUT /collection意味着”用此消息中包含的表示形式替换/ collection的表示形式。
因此，这是您尝试修改集合资源本身的表示形式时使用的正确请求，而在您尝试修改其他内容的表示形式时执行的错误操作。
例如，如果集合的表示形式是其元素的描述列表，那么您可以使用PUT将列表替换为其他列表。
GET /collection 200 OK [1, 2, 3] PUT /collection [4, 5] 204 No Content GET /collection [4, 5]换句话说，从REST的角度来看，“集合”与其他所有资源都使用具有相同语义的完全相同的消息。
如果您要描述的是对其他资源的更改，则使用该资源的标识符
（和中间组件）永远不要只从表示形式中尝试从URI中提取信息。因此，如果您的消费者用例需要“ 1”，那么它需要出现在资源的表示形式中。PUT /collection/1现在，标识符中是否应包含标识符“ 1”？这取决于-但是这是基本规则：consumers
从这个意义上讲，PUT只是GET的对偶-如果GET需要在响应提供的表示中包含信息，那么PUT需要在请求提供的表示中包含相同信息。
考虑文件内容可能会很有用-我们将读者需要的信息放入文件中，文件名/路径只是告诉读者如何找到它。或者，如果您想到的是Hash / Map / Dictionary，则该键用于将值获取到地图中或从地图中获取，但是信息在值中。
REST在大多数情况下都依赖于其传输层（HTTP）的语义。 HTTP的核心只是一个远程文档管理系统，它负责以无状态方式将文件从一个位置发送到另一个位置。正如Jim Webber所指出的，得出的任何业务规则基本上只是实际文档管理的副作用。