RESTful 架构中的给定 URI 是否应该总是返回相同的响应？答案

【问题标题】：Should a given URI in a RESTful architecture always return the same response?RESTful 架构中的给定 URI 是否应该总是返回相同的响应？
【发布时间】：2011-02-10 05:33:36
【问题描述】：

这是this one 的后续问题。

那么对于任何给定的 URI 有一个独特的响应是 RESTful 架构的核心租户吗？这里的很多讨论都倾向于这个方向，但我在任何地方都没有将其视为“硬性”规则。

我了解它的价值（用于缓存、抓取、传递链接等），但我也看到 twitter API 违反了它（对http://api.twitter.com/1/statuses/friends_timeline.xml 的请求将根据给定的用户名而有所不同），我了解有时可能需要 - 更不用说按时间顺序分页的资源也会随着新元素的添加而改变。

我是应该努力完全消除来自同一 URI 的各种响应，还是我只是接受有时它不切实际，只要我尽量减少它的发生，我的状态就会很好。

【问题讨论】：

REST 规则 #1。永远不要将 Twitter API 用作指南 ;-)
Touché ;) ...我想隐含的问题是 RESTful 是布尔状态还是滑动比例。很多“大牌”应用程序会破坏或打破某些规则，但仍称自己为“RESTful”。

标签： rest uri

【解决方案1】：

不是相同的响应，而是相同资源的表示（取决于连接和条件请求标头）。在 Rest Architecture 中，一个 URI 标识一个且仅一个资源（但一个资源可以有多个 URI）。根据授权用户呈现不同的资源（如 HTTP Auth、cookie、...）是不好的做法，因为相同的 URI 代表每个用户的不同资源，如 Twitter 示例中所示。我不能让您查看我的时间线并向您提供 URI，因为这与 your 时间线的 URI 相同。用户必须在 URI 中编码，并且访问受授权机制的限制。要让单个访问点根据经过身份验证的用户呈现不同的资源，请使用重定向（例如 303 See Other, 302 Found, ...）

【讨论】：

您的“不良做法”声明有任何参考资料吗？根据登录的用户返回不同的内容是完全合法的。例如，我可以定义一个快捷方式 URL /my/things，它为登录用户返回内容，并返回将 Content-Location 标头设置为 /users/123/things 的响应以指示该资源的规范位置（请参阅 RFC 2616 第 14.14 节）
如果 /my/things 和 /users/123/things 应该代表相同的资源，那么只有一个应该返回 200，另一个应该返回 303 See Other。
Content-Location 应该用于给出返回的资源变体的 URI（不同的表示形式，例如 conneg）或在 POST 的情况下返回创建的资源（而不是使用 201 +位置，后者更严格）。在您展示的情况下，它是一种不同的资源。您无法通过获取此 URI 来确定客户端将检索什么资源。如果 UA 是浏览器，则不能复制/粘贴 URI，因为 Content-Location 不能直接访问。 URI 是资源标识符，即它们标识一个资源，总是相同的（参见 Roy 论文的 sect.5.2）
另见：Web 架构的公理 1 和 2 (w3.org/DesignIssues/Axioms.html#unique)
使用重定向的有趣方法。我喜欢这样，特别是因为my/things 示例正是我正在查看的（嗯，这是我的两个用例之一）。用户不必知道他们的 ID 即可轻松输入 URI 来访问特定资源，而这样他们就不必知道了。

【解决方案2】：

REST 中没有任何内容表示相同的响应 - 但您应该准备好在它们有意义时处理诸如“如果修改后”请求标头之类的东西;)

tritter API 显然还有其他问题 - 例如：这是一个设计决策。例如，一旦您允许隔离朋友时间线，将时间线放在朋友姓名元素下方是有意义的 - 他们显然决定不这样做;)

它归结为设计决策。查看 OData（如 http://odata.netflix.com/Catalog/） - 这里它使 snse 在给定的时间（缓存）内为每个 URL 返回相同的数据，因为它是一个完全公共的目录。对于其他情况，这可能没有意义。

【讨论】：

【解决方案3】：

一些请求标头确实会改变返回的内容（同时仍然是 RESTful）：

显然，缓存标头将用于确定返回 304 还是 200
Accept 标头可用于确定响应的格式（HTML、XML 和 JSON）
Authorized 标头至少可以确定返回的是 401、403 还是 200。
此外，资源可以随时间变化。

真正的问题是是否可以使用Authorized 标头（确定用户）来更改响应的内容。我还没有看到任何关于它的官方声明，但我怀疑很多人宁愿在 URL 中使用用户，并使用 Authorized 标头来验证访问权限。我怀疑任何一种方式仍然是 RESTful。

【讨论】：

问题是，有多少中间缓存能够处理基于 auth 标头的响应变化。如果缓存对特定应用程序不重要，那么使用单个 url 就可以了。但为什么要冒这个险呢？