Question

我正在设计用于访问媒体的RESTful资源。媒体可以是直播流或存档流。我正在使用O'Riellys的文本“RESTful Web Services”作为指南，但我正在努力处理与'programmagable 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'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 指向同一事物的不同形式：“查询'水母的搜索结果列表。'” 一个URI提供HTML，供Web浏览器使用;另一个服务 XML，旨在供自动客户端使用。

处理人类网络与可编程网络的两个独立资源是常态还是有替代方案？欢迎思考。

Answer 1

我会说官方的“fielding compliance”答案是使用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-type。

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

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

2 个答案: