REST Content-Type：它是基于扩展还是Accept头？

Question

由REST风格的Web服务返回的表示（html，xml，json）应由url还是由Accept HTTP头确定？

Answer 1

两者都有效。从xml.com引用：

资源可能有多个 表示形式。有四种 常用交付 正确的资源表示，以 消费者的方式：

1. 服务器驱动的协商。服务提供者根据其客户端的先前知识 来表示正确的 表示，或者使用在诸如接受， 接受字符集，接受编码， 接受语言和用户代理的HTTP报头中提供的信息 。这种方法的缺点是 服务器可能没有关于客户真正想要什么的最佳知识 。
2. 客户端驱动的协商。客户端向 服务器发起请求。服务器返回可用于表示的 列表。 客户端然后选择它想要的表示 ，并向服务器发送第二个请求到 。缺点是一个 客户端需要发送两个请求。
3. 代理驱动的协商。客户端通过代理向服务器 发起请求。代理将 请求传递给服务器，并获得 表示列表。代理 根据 选择一个表示设置客户端设置， 将表示返回到 客户端。
4. URI指定的表示。客户指定它在 想要在URI查询字符串中的表示。

Answer 2

由于很多基于REST的网址没有扩展名，你应该/必须立足于内容类型

编辑：我不是说这听起来确实苛刻，更多的您将不得不注意内容类型，并且不总是能够引用分机

Answer 3

如果提供，使用Accept标头，URI作为故障转移。

Answer 4

这是一个没有问题的问题。

接受依赖于conneg（内容协商）。 Conneg会让客户通过Accept：标题决定他们接受什么媒体类型。然后，响应将采用该格式，并附带Vary：Accept标头。

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

理想的是实现两个： /资源（支持连接的通用uri） /resource.xml /资源。json

/resources返回的conneg'd版本可以根据协商的媒体类型简单地重定向到正确的uri。或者，可以从通用uri中返回正确的表示形式，并使用Content-Location来指定返回的特定表示形式。

Answer 5

由于您提到的是RESTful Web服务而不是任何Web服务，我会强烈推荐底层标准支持的内容 - HTTP 1.1及其依赖于Accept HTTP标头的内容协商。

正如我在Can I change the headers of the HTTP request send by the browser的回答中所解释的，地址（URI）和表示是RESTful设计的两个截然不同的支柱，它们不需要混合。 当存在Accept标头时，不应该滥用URI来嵌入可接受的表示。

只有当您的Web应用程序有可能在中间节点涉及的HTTP头过滤的环境中运行并使用时，您应该支持基于URI的内容协商。真相被告知，如果任何可能和可行的话，这种侵入性或不正确的功能代理应该被替换。

干杯！
Shonzilla

Answer 6

有使用内容类型的问题...我讨论这在我的博客http://shouldersofgiants.co.uk/Blog终于在包括在URI表示在REST Web服务建议的理查森和Ruby

Answer 7

见Chapter 5 - Representational State Transfer (REST)入驻，节5.2.1.2 表征的罗伊菲尔丁的dissertation上建筑风格：

的表示的数据格式被称为媒体类型[48]。

看看链接，我们看到它指的是MIME。因此，我假定用HTTP的说法是用POST/PUT的Content-Type标题和GET的标题Accept来表示。

这里是第（用于完整性）的其余部分：

的表示可以根据消息的控制数据和的性质 被包括在消息中并且由 收件人处理媒体类型。某些媒体类型旨在用于自动处理，其中一些媒体类型旨在呈现供用户查看， 以及一些媒体类型都可以同时处理。复合媒体类型可用于在单个消息中包含多个表示。

P.S：我不知道为什么人们从来不看的地方，剩下的就是真正定义...