RESTful 架构中的给定 URI 是否应该始终返回相同的响应？
那么对任何给定的 URI 拥有唯一的响应是 RESTful 架构的核心租户吗？这里的很多讨论都倾向于这个方向，但我还没有在任何地方将其视为“硬性且快速”的规则。
我理解它的价值（用于缓存、爬行、传递链接等），但我也看到诸如 twitter API 之类的东西违反了它（对 http://api.twitter.com/1/statuses/ 的请求Friends_timeline.xml 将根据给定的用户名而有所不同），我知道有时可能有必要 - 更不用说按时间顺序分页的资源也会随着新元素的添加而改变。
我是否应该努力完全消除来自同一 URI 的不同响应，或者我是否只是接受有时这是不切实际的，只要我尽量减少它的出现，我就会处于良好状态。
This is kind of a follow-up question to this one.
So is having a unique response for any given URI a core tenant of RESTful architecture? A lot of discussion here tends that direction, but I haven't seen it anywhere as a "hard and fast" rule.
I understand the value of it (for caching, crawling, passing links, etc), but I also see things like the twitter API violate it (A request to http://api.twitter.com/1/statuses/friends_timeline.xml will vary based on the username given), and I understand there are times when it may be necessary--not to mention that a chronologically paged resource will also change as new elements are added.
Should I strive for varied responses from the same URI to be eliminated altogether, or do I just accept that sometimes it isn't practical, and as long as I minimize its occurrence, I'll be in decent shape.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不是相同的响应，而是相同资源的表示（取决于 conneg 和条件请求标头）。在 Rest 架构中，一个 URI 标识一个且仅一个资源（但一个资源可以有多个 URI）。根据授权用户（HTTP Auth、cookies 等）提供不同的资源是不好的做法，因为相同的 URI 代表每个用户不同的资源，如 Twitter 示例中所示。我无法允许您查看我的时间线并为您提供 URI，因为这与您的时间线的 URI 相同。用户必须在 URI 中进行编码，并且访问受到授权机制的限制。要让单个访问点根据经过身份验证的用户提供不同的资源，请使用重定向（例如 303 See Other、302 Found，...）
Not the same response, but a representation (wich depends on conneg and conditional request headers) of the same resource. In a Rest Architecture, a URI identify one and only one resource (but a resource can have several URI). Presenting different resource depending on the authorized user (being HTTP Auth, cookies, ...) is bad practice, since the same URI represent a different resource for each user, as in the Twitter example. I can't allow you to view my timeline and give you the URI, since this is the same URI for your timeline. The user must be encoded in the URI, and access limited by the authorization mecanism. To have a single access point presenting different resource depending on the authenticated user, use a redirect (e.g. 303 See Other, 302 Found, ...)
REST 中没有任何内容表示相同的响应 - 但您应该准备好处理诸如“如果修改后”请求标头之类的内容（当它们有意义时）;)
tritter API 显然还有其他问题 - 例如：这是一个设计决策。例如，一旦您允许隔离朋友时间线，则将时间线放在朋友姓名元素下方是有意义的 - 他们显然决定反对这样做；）
这取决于设计决策。查看 OData（例如 http://odata.netflix.com/Catalog/） - 在这里使 snse 在给定时间内为每个 URL 返回相同的数据（缓存），因为它是完全公开的目录。对于其他场景，这可能没有意义。
Nothing in REST says same response - but you shuld be prepared to handle stuff like the "If Modified Since" request headers WHEN THEY MAKE SENSE ;)
The tritter API has other issues, obviously - as in: this is a design decision. Once you allow friend timelines to be isolated, for example, it would make sense to put the timeline below a friend name element - they obviously decided against this ;)
It runs down to design decisions. Look at OData (like http://odata.netflix.com/Catalog/) - here it makes snse to return the same data for every URL for a given time (caching), because it is a fully public cataloque. For other scenarios it may make no sense.
某些请求标头确实会更改返回的内容（同时仍然是 RESTful）：
Accept标头可用于确定返回的内容。响应的格式（HTML、XML、JSON）Authorized标头至少可以确定返回的是 401、403 还是 200。真正的问题是是否可以使用
Authorized标头（决定用户）来更改响应的内容。我还没有看到任何关于它的官方声明，但我怀疑很多人宁愿让用户在 URL 中，并使用Authorized标头来验证访问。我怀疑这两种方式仍然是 RESTful 的。Some request headers do change what is returned (while still being RESTful):
Acceptheader can be used to determine the format of the response (HTML vs XML vs JSON)Authorizedheader can at least determine if a 401, 403, or 200 is returned.The real question is whether the
Authorizedheader (which determines the user) can be used to change the content of the response. I haven't seen any official statement about it, but I suspect a number of people would rather have the user in the URL and theAuthorizedheader used to validate access. I suspect either way is still RESTful.