在什么情况下客户端应该为 REST URI 选择唯一的资源 ID，而服务器应该在什么情况下指定它？
看起来我可以通过两种方式创建 REST API。我可以使用 POST 创建用户而不指定 URI，它将创建用户并返回 URI，或者我可以使用 PUT 创建用户并指定 URI本身。
什么时候应该使用其中一种而不是另一种？这里的关键区别在于，在一种方法中，我的系统决定资源的唯一 ID 和 URI 应该是什么，而在另一种情况下，他们在我创建时指定它应该是什么。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这基本上取决于您是否愿意将资源命名的控制权交给客户端。
最大的问题就是处理冲突（如果我 PUT /photo.png 而你 PUT /photo.png，可以吗？）。
回答这些问题，你就上路了。
It basically comes down to whether you are willing to cede the control of resource naming to the client.
The biggest issue simply being dealing with conflicts (If I PUT /photo.png and you PUT /photo.png, is that OK?).
Answer those questions, and you're on your way.
当您的用户指定资源 ID 时，他们可以 PUT 到 URI；他们执行 PUT 的 ID 是资源 ID 的规范。
当您指定资源ID时，它们可以POST到父/组的URI；您的系统将为资源分配一个 URI，并将其返回给客户端，以便他们可以引用其创建的资源。
When your user is specifying the resource ID, they can PUT to the URI; the ID that they are performing the PUT to is the specification of the resource ID.
When you are specifying the resource ID, they can POST to the URI of the parent / group; your system will assign a URI to the resource, and return that to the client so they can reference their created resource.
这个问题的答案取决于两个更具体的问题：
如果这两个问题的答案都是“是”，那么 PUT 可能是合适的。如果您对其中任何一个问题的回答都是“否”，那么您应该坚持使用 POST。
The answer to this question hinges on two more specific questions:
If the answer to both of those questions is 'yes', then a PUT is probably appropriate. If you answered 'no' to either, then you ought to stick with a POST.
使用第一个。
在 RESTful HTTP 中，客户端应该永远构造 URI。服务应该连接良好，这意味着客户端应该只遵循服务器给出的 URI 并向这些 URI 发出请求。
它在客户端和服务器之间建立了更好的分离，并且可以更轻松地更改服务而不破坏现有客户端。
（是的，很多现有的 API 都犯了这个错误）
Fielding 发表了一篇与此主题相关的非常好的文章：
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Use the first.
In RESTful HTTP the client should never construct URIs. The service should be well-connected, which means that the client should only ever follow URIs given by the server and make requests to those URIs.
It creates better separation between the client and server, and makes it easier to make changes to the service without breaking existing clients.
(And yes, lots of existing APIs get this wrong)
There's a really good post by Fielding related to this topic here:
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven