REST内容types：它应该基于扩展还是Accept头？
应该由REST式Web服务返回的表示（html，xml，json）由url还是由Accept HTTP头确定？
两者都是有效的。 从xml.com报价：
一个资源可能有多个表示。 有四种常用的方式向消费者提供正确的资源表示forms：
- 服务器驱动的协商。 服务提供者根据其客户的先前知识来确定正确的表示，或者使用HTTP报头（如Accept，Accept-Charset，Accept-Encoding，Accept-Language和User-Agent）中提供的信息。 这种方法的缺点是服务器可能不了解客户真正想要的东西。
- 客户驱动的谈判。 客户端启动对服务器的请求。 服务器返回可用表示的列表。 客户端然后select它想要的表示，并向服务器发送第二个请求。 缺点是客户端需要发送两个请求。
- 代理驱动的协商。 客户端通过代理向服务器发起请求。 代理将请求传递给服务器并获取表示列表。 代理根据客户设置的偏好来select一个表示，并将表示返回给客户。
- URI指定的表示。 客户端在URI查询string中指定它想要的表示forms。
这不是一个问题。
接受取决于conneg（内容协商）。 Conneg将允许客户通过Accept：头来决定他们接受的媒体types。 然后，响应将采用该格式，以及Vary：Accept标头。
另一方面，将资源公开为/resource.json和/resource.xml也是可能的，也是完全有效的。
理想的是同时实现：/ resource（支持conneg的通用uri）/resource.xml /resource.json
/资源返回的连接版本可以根据协商的媒体types简单地redirect到正确的URI。 或者，可以从通用uri返回正确的表示forms，并使用Content-Location来指定返回的特定表示forms。
由于您提到的是REST风格的Web服务，而不是任何Web服务，所以我会强烈推荐底层标准支持的内容 – HTTP 1.1及其依赖于Accept HTTP标头的内容协商。
正如我在我的答案中解释的那样，我可以更改浏览器发送的HTTP请求的标头 ，地址（URI）和表示是RESTfuldevise的两个截然不同的支柱，它们不需要混合。 有Accept头时，不应滥用URI来embedded可接受的表示 。
只有当您的Web应用程序可能在中间节点所涉及的HTTP头过滤的环境中运行和使用时，您应该支持基于URI的内容协商。 说实话，这样的侵入性或不正常的代理应该被replace，如果有可能和可行的话。
干杯!
Shonzilla
如果提供了Accept头，则使用URI作为故障转移。
使用内容types存在问题…我在我的博客http://shouldersofgiants.co.uk/Blog上讨论过这个问题，最后决定将这个表示包含在URI中，正如Richardson和Ruby在RESTful Web Services中所build议的那样
由于很多REST风格的URL没有扩展名，您应该/必须基于Content-Type
编辑：我不认为这听起来像苛刻，更多的是你将不得不注意内容types，并不总是能够引用扩展
请参阅第5章 – 具象状态转移（REST） ，第5.2.1.2节Roy Shapeing关于build筑风格的论文的 表示 ：
表示的数据格式被称为媒体types[48] 。
看链接，我们看到它指的是MIME。 所以我假设用HTTP的说法是用POST / PUT的Content-Type头和GET的Accept头来表示。
这是段落的其余部分（为了完整性）：
表示可以被包括在消息中并且由接收者根据消息的控制数据和媒体types的性质来处理。 一些媒体types是用于自动处理的，一些是为了供用户观看而呈现的，而另外一些媒体types则兼具两者的function。 复合媒体types可用于将多个表示forms包含在单个消息中。
PS：我不确定为什么人们不会在REST实际定义的地方看
