用户拥有的小部件的 URL 的 RESTful 设计
我的 RESTful API 始终具有身份验证，因此所有调用都会针对特定用户进行身份验证。
哪种 URL 的 RESTful 设计比 HTTP 协议更好？ 请记住，用户 id 3 已通过基本 http auth/digest 进行了身份验证。
http://server.com/users/3/widgets/ （返回用户的所有小部件编号 3)
http://server.com/users/3/widgets/13 （返回小部件 ID 13)
或：
http://server.com/widgets/（返回用户 ID 3 的所有小部件）< br> http://server.com//widgets/13 （返回小部件 ID 13）
是否更好总是有一个唯一的 URL，例如 http://server.com/users/3/widgets/ 即使知道只有用户 #3 是唯一访问它的人？在每次调用时重新指定 /user/3 是否多余，例如 http://server.com/users/3/widgets/
My RESTful API always has authentication so all calls are authenticated for a particular user.
Which is a better RESTful design of URLs over the HTTP protocol?
Remember that the user id 3 is already authenticated via basic http auth/digest.
http://server.com/users/3/widgets/ (Returns all widgets for user id 3)
http://server.com/users/3/widgets/13 (Returns widget id 13)
or:
http://server.com/widgets/ (Returns all widgets for user id 3)
http://server.com//widgets/13 (Returns widget id 13)
Is it better to always have a unique URL like http://server.com/users/3/widgets/ even know only user #3 will be the only one accessing it? Is it redundant to re-specify /user/3 on every call like http://server.com/users/3/widgets/
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我肯定会推荐第一个选项。如果您选择第二个，并且在某个时候您决定允许缓存，那么您必须确保您的变化标头指定表示形式在授权标头上有所不同。如果您使用过期的身份验证令牌，这可能会很痛苦。
这也意味着，如果您想要允许用户查看其他用户的小部件，您可以并且缓存仍然有效。
I would definitely recommend the first option. If you choose the second and at some point you decide you want to allow caching then you would have to make sure that your vary header specified that the representation varies on the authorization header. This can be a pain if you use auth tokens that expire.
It also means that if you ever want to allow users to see the widgets of other users, you can and the caching would still work.
从技术上讲，REST 应该是无状态的，因此更“正确”的实现将是您列出的第一种方式。
但是，我的做法与您建议的第一种方法略有不同——用户获得的有关特定小部件的信息是否会根据用户而变化？如果没有，您可能想尝试一下：
两全其美。正确的“REST-ful”实现，但是当涉及到特定的小部件时，当前用户并不重要。这样，您的客户也可以更轻松地传递对各个小部件的查询，而无需自己更新查询。如果客户端不应该有权查看该特定小部件，那么使用您已有的身份验证来防范应该不难。
我还基于这样一个假设：小部件列表可能因客户端而异 - 如果情况并非如此，并且所有客户端都将看到相同的小部件列表，则没有理由传递用户，所以采用第二种方式。
REST technically should be stateless, so the more "proper" implementation would be the first way you listed.
However, I would do things slightly differently than how you're suggesting for the first method--will the information a user gets back about a specific widget change, depending on the user? If not, you might want to try this:
Gets a best of both worlds. Proper "REST-ful" implementation, but when it comes to specific widgets, the current user doesn't matter. This way, your clients could pass around queries for individual widgets more easily as well--without having to update the query themselves. If the client shouldn't have access to view that particular widget, that shouldn't be difficult to protect against with the authentication you have already.
I'm also basing this all off an assumption that the widget listing could differ from client to client--if that is not true, and all clients are going to see the same widget listing regardless, there's no reason to pass the user, so go with the second way.
我会选择第一个，因为它完全指定了资源。
I'd go with the first because that does fully specify the resource.