RESTful 资源表示 - 人类网络与可编程网络

Question

我正在设计用于访问媒体的 RESTful 资源。媒体可以是实时流或存档流。我使用 O'Riellys 文本“RESTful Web 服务”作为指南，但我正在努力处理与“可编程网络”和“人类网络”相关的资源表示。对于人类网络请求，我想返回HTML 表示。对于可编程的 Web 请求，我想返回 XML。话虽如此，请考虑：

GET http:// localhost :8080/stream - returns a list of streams

GET http:// localhost :8080/search?stream=abc - return a specific stream

我如何区分来自“人类网络”和“可编程网络”的请求，以便我可以返回正确的表示？

O'Reillys 的文字似乎建议设计两个单独的资源。从 PDF 的第 24 页他说：

我会使用相同的工具来获取和处理网页。 这两个 URI： 1）http://api。 search.yahoo.com/WebSearchService/V1/webSearch?appid=restbook&query=jellyfish 2) http://search.yahoo.com/search?p=jellyfish 指向同一事物的不同形式：“查询‘jellyfish’的搜索结果列表。” 一个 URI 服务于 HTML 并供 Web 浏览器使用；另一个发球 XML，旨在供自动化客户端使用。

处理人类网络和可编程网络的两种不同资源是规范还是有替代方案？欢迎提出想法。

Answer 1

我会说官方“符合字段”的答案是使用 ACCEPTS 标头使用内容类型协商。 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm 有很多好东西

如果客户端请求 text/html，则提供人类可读的 html。如果客户端请求 text/xml，则提供 xml。这里的诀窍是，实际上这并不总是得到客户很好的支持，因此您经常需要使用查询字符串或资源名称修饰的一堆后备，如您发布的示例中所示。

就我个人而言，我会尽可能地遵循意识形态，然后根据需要开始务实地添加后备方案。在遇到无法正确处理发送接受标头的客户端之前，我不会为编程或人工消费创建单独的资源。

Answer 2

您的示例与问题不匹配，因此我将同时回答。

在您给出的示例中，您有两种不同的资源：流列表和单个流。因此，它们应该被分配单独的 URI，并且我强烈建议不要将查询字符串用于有一个干净且明显的替代方案的地方。

在这种情况下，它是经典的 ReST。 /stream/ 是由可用流列表组成的资源，此列表应显示为人类或计算机（或最好两者）的 URI 列表，因此（如 text/html）：

<ul>
  <li><a href="/stream/abc">ABC</a></li>
  ...
</ul>

这就引出了你的下一个问题，如何识别流列表资源的不同表示。我使用了三种技术：内容协商、格式查询参数和 RDFa。

RDFa 是我的首选替代方案，在这种情况下，您只有一种表示可以编码人类和机器可读的内容。在简单列表的情况下，这是对 HTML 的微不足道的更改：

<ul>
  <li><a rev="rdfs:member" href="/stream/abc">ABC</a></li>
  ...
</ul>

如果您的数据有一个或多个纯机器序列化，那么我使用了两种替代方案；通常，两者同时进行。

内容协商是最纯粹、最方便的。只要有一个text/html，另一个application/xml或application/json，让客户端选择。

从浏览器、命令行 (curl/wget/etc) 或脚本测试机器版本时，这并不方便。所以我也喜欢支持格式查询参数。为方便起见，请采用 mime 类型。

我更喜欢让我的资源由同一个控制器/servlet/etc 处理，让它从文件系统/数据库/其他任何东西中获取信息，然后根据 mime 类型（内容否定或格式）将其分派到适当的视图参数）用于显示。无论哪种方式，您都在处理同一资源的不同表示形式，因此无论您决定支持何种替代方法，最好确保它们可从同一基本 URI 获得。