REST内容类型:它应该基于扩展名还是Accept头？

RESTful Web服务返回的表示形式(html,xml,json)应该由url还是Accept HTTP标头确定？

1> Darin Dimitr..：

---

两者都有效.来自xml.com的报价:

资源可以具有多个表示.有四种常用的方法可以向消费者提供正确的资源表示:

服务器驱动的协商.服务提供商根据其客户端的先验知识确定正确的表示,或使用HTTP头中提供的信息,如Accept,Accept-Charset,Accept-Encoding,Accept-Language和User-Agent.这种方法的缺点是服务器可能不了解客户真正想要的内容.

客户驱动的谈判.客户端向服务器发起请求.服务器返回可用表示的列表.然后,客户端选择它想要的表示,并向服务器发送第二个请求.缺点是客户端需要发送两个请求.

代理驱动的协商.客户端通过代理向服务器发起请求.代理将请求传递给服务器并获取表示列表.代理根据客户端设置的偏好选择一个表示,并将表示返回给客户端.

URI指定的表示.客户端在URI查询字符串中指定它想要的表示.

---

我不这是一个正确的答案,即使xml.com上的随机人员说它是.通过更改URL,您建议底层资源可能不同,即使您事先知道底层资源始终相同.

---

@ThomasJaskula - 如果同时指定了Accept和URL,则使用a.)最常见的b.)明智或智能默认(例如,如果你可以告诉客户端是UserAgent的浏览器b/c,那么发送浏览器可以轻松处理的内容)

2> SerialSeb..：

---

这不是问题.

接受取决于连接(内容协商).Conneg将让客户通过Accept:标头决定他们接受的媒体类型.然后响应将采用该格式,以及Vary:Accept标头.

另一方面,将资源公开为/resource.json和/resource.xml也是完全有效的.

理想情况是实现:/ resource(支持conneg的通用uri)/resource.xml /resource.json

/ resource返回的连接版本可以根据协商的媒体类型简单地重定向到正确的uri.或者,可以从通用uri返回正确的表示,并使用Content-Location指定返回的特定表示.

---

再次偶然发现 - 我必须收回我最初评论的内容,这是错误的.:)

---

您似乎对资源的概念采取了非常具体和联系的观点.任何有用的单独可寻址的东西都可以分配一个URI.如果您需要区分两种格式,可以将它们"提升"为资源.请参阅W3C关于通用URI的说明和Roy关于应该使用什么内容类型协商的评论:当且仅当两种媒体类型之间的区别不重要时.

---

错了,据REST说.每个RESOURCE应该只有一个URI - 而不是该资源的每个表示.

---

@Wahnfrieden你能指点我们这个位置的官方来源吗？我已经看到很多围绕这个的讨论,但从来没有看到任何具体的决定写下来.

3> Shonzilla..：

---

由于您提到的是RESTful Web服务而不是任何Web服务,因此我强烈要求基础标准支持的内容 - HTTP 1.1及其依赖AcceptHTTP头的内容协商.

正如我在回答中所解释的那样,我可以更改浏览器发送的HTTP请求的标头,地址(URI)和表示是RESTful设计的两个不同支柱,它们不需要混合.当有Accept标题时,不应滥用URI来嵌入可接受的表示.

只有当您的Web应用程序可能在中间节点涉及某些HTTP标头过滤的环境中运行和使用时,您才应支持基于URI的内容协商.说实话,如果可行且可行的话,应该替换这种侵入性或不正常运行的代理.

干杯!
Shonzilla

4> chaos..：

---

使用Accept标头(如果提供),URI作为故障转移.