0

我正在设计用于访问媒体的 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，旨在供自动化客户端使用。

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

4

2 回答 2

0

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

在您给出的示例中，您有两种不同的资源：流列表和单个流。因此，它们应该被分配单独的 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 获得，无论您决定支持何种替代方法。

于 2012-06-03T03:52:42.397 回答
0

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

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

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

于 2012-06-03T02:32:31.577 回答