【发布时间】：2011-09-11 04:31:30
【问题描述】：
看起来有两种方法可以制作我的 REST API。我可以在不指定 URI 的情况下使用 POST 创建用户，它将创建用户并返回 URI，或者我可以使用 PUT 创建用户并指定 URI他们自己。
什么时候应该使用一个而不是另一个？这里的关键区别在于，在一种方法中，我的系统决定了资源的唯一 ID 和 URI 应该是什么，而在另一种情况下，他们在我创建时指定它应该是什么。
【问题讨论】：
【发布时间】：2011-09-11 04:31:30
【问题描述】：
这基本上归结为您是否愿意将资源命名的控制权交给客户端。
最大的问题就是处理冲突（如果我 PUT /photo.png 而你 PUT /photo.png，可以吗？）。
回答这些问题，你就上路了。
【讨论】：
-
不正确。让客户端自己构建 URI 违反了 RESTful 风格的原则之一。
-
是的，没有。 “分配资源标识符的命名机构，使引用资源成为可能，负责随着时间的推移维护映射的语义有效性”。没有什么可以说明客户端不能成为命名机构并负责命名空间的维护以及资源在该命名空间中的含义。此外，“...REST 依赖于作者选择最适合所识别概念的性质的资源标识符”。该“作者”可以是系统或客户端，由应用程序及其语义定义。
-
@tomc 允许客户端构造媒体类型中定义的基于 URI 的规则。菲尔丁在这篇文章roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven“允许服务器指导客户端如何构造适当的 URI”中这样说
当您的用户指定资源 ID 时，他们可以 PUT 到 URI；他们执行 PUT 的 ID 是资源 ID 的规范。
当你指定资源ID时，它们可以POST到父/组的URI；您的系统将为资源分配一个 URI，并将其返回给客户端，以便他们可以引用他们创建的资源。
【讨论】：
这个问题的答案取决于两个更具体的问题：
- 客户端是否知道要创建的资源的位置？ （例如，如果通过用户的名称而不是服务器分配的 ID 访问用户，则可能会出现这种情况。）
- 客户端是否具有要创建的资源的完整表示？ （如果您的资源的某些部分由服务器计算，则可能不会出现这种情况。）
如果这两个问题的答案都是“是”，那么 PUT 可能是合适的。如果您对其中任何一个都回答“否”，那么您应该坚持使用 POST。
【讨论】：
-
您仍然可以 PUT 表示并让服务器计算其中的一部分。
-
@Darrel Miller：确实可以！但是，我会将HTTP spec 解释为规定 PUT 使用完整资源完成，而不是在幕后修改的部分资源。 （例如“请求存储包含的实体”，或“标识请求包含的实体”。）
-
但是 HTTP 中没有任何关于资源表示的说明，所以这当然让应用程序确切地知道适当的表示是什么以及“完整”和“部分”的定义是什么.
-
PUT 的解释已经在 Httpbis 中大大扩展，试图澄清这个问题和其他问题。 tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#page-18
我可以使用 POST 创建用户 不指定 URI，它会 创建用户并返回 URI 或 我可以创建用户 PUT 并自行指定 URI。
什么时候应该使用 其他的？
使用第一个。
在 RESTful HTTP 中，客户端应该从不构造 URI。服务应该连接良好，这意味着客户端应该只遵循服务器提供的 URI 并向这些 URI 发出请求。
它在客户端和服务器之间创建了更好的分离，并且可以更轻松地更改服务而不破坏现有客户端。
（是的，很多个现有 API 都犯了这个错误）
Fielding 有一篇与此主题相关的非常好的帖子：
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
【讨论】：
-
URI templates 可以保持 API 超文本驱动，同时仍然允许客户端自定义请求。
-
在我的 personal 选项中，POST/redirect 是如此简单和标准化的习语，我认为它应该是默认的，除非你有充分的理由否则选择。虽然那肯定不是经典。
-
URI 模板并不是服务器可以指导客户端如何构建 URI 的唯一方式，但它们绝对是更好的方式之一。关键是要确保媒体类型或链接关系规范记录了定制机制。