类型：它应该基于扩展名还是Accept头？

2018-06-25 11:01:57

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

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

资源可能有多个表示。有四种常用的方式向消费者提供正确的资源表示形式：

服务器驱动的协商。服务提供者根据其客户的先前知识来确定正确的表示，或使用HTTP头中提供的信息，如Accept，Accept-Charset，Accept-Encoding，Accept-Language和User-Agent。这种方法的缺点是服务器可能没有关于客户真正想要的最佳知识。

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

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

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

这不是问题。

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

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

理想的做法是实现：/ resource（支持conneg的通用uri）/resource.xml /resource.json

基于协商的媒体类型，由/ resource返回的连接版本可以简单地重定向到正确的uri。或者，可以从通用uri中返回正确的表示形式，并使用Content-Location来指定返回的特定表示形式。

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

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

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

干杯!
Shonzilla

链接地址: http://www.djcxy.com/p/71271.html