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

我正在设计用于访问媒体的RESTful资源。媒体可以是实时流或存档流。我使用O'Riellys文本“RESTful Web服务”作为指导，但我正在努力解决资源相对于“可编程Web”和“human Web”的表示。对于human 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'Reilly的文章似乎建议设计两种不同的资源。从PDF的第24页，他指出：

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

处理人类网络和可编程网络的两种不同的资源是标准还是有其他选择？欢迎您的想法。

我认为官方的“符合部署”答案是使用ACCEPTS标头进行内容类型协商。在

如果客户机请求text/html，则提供人类可读的html。如果客户机请求text/xml，则提供xml。这里的诀窍是，实际上，客户机并不总是很好地支持这一点，因此您通常需要使用查询字符串或资源名称混乱的一系列回退，如您发布的示例所示

---

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

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

在您给出的示例中，您有两种不同的资源：一个流列表和一个单独的流。因此，应该为它们分配单独的URI，我强烈建议不要在有明确的替代方案的情况下使用查询字符串

在这种情况下，它是经典的ReST。

/stream/

是由可用流列表组成的资源，该列表应显示为URI的人工或计算机（或最好同时显示两者）列表so（文本/html）：

...

这就引出了您的下一个问题，即如何识别流列表资源的不同表示形式

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类型（content neg或format param）将其分派到适当的视图用于显示。无论哪种方式，您都要处理同一资源的不同表示形式，因此最好确保它们可从相同的基本URI获得，无论您决定支持何种替代方法。

；因此我也喜欢支持格式查询参数。为方便起见，请使用mime类型“”，因此我也喜欢支持ort是一个格式查询参数。为了方便起见，让它采用mime类型。能否提供一个URI示例，该URI采用基于基URI的mime类型？您可以使用我的初始帖子中的URI作为基。当然。进入浏览器将返回HTML，人类可读的版本。也可以从将ACCEPTS标头设置为application/xml将返回与机器可读xml相同的内容。但是，如果您支持format query param，也可以进入浏览器并在那里接收xml版本。我发现这对于调试非常有用。

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