REST内容类型:应该基于扩展还是接受标题?

两者都是有效的。引自 xml.com :

一个资源可以有多个 交付产品的常用方法 将资源表示形式更正为 消费者:

1. 服务器驱动的协商。由服务提供商确定权利 它的客户或使用这些信息 在HTTP头文件(如Accept)中提供, 接受语言和用户代理。这个 服务器可能没有最好的知识 关于客户真正想要什么。
2. 客户驱动的谈判。客户端向客户端发起请求 可供选择的陈述。这个 然后,客户机选择表示 它需要并发送第二个请求到 服务器。缺点是 客户端需要发送两个请求。
3. 通过代理。代理通过 请求服务器并获取 陈述清单。代理 根据需要选择一个表示 由客户端和 将表示返回到 客户
4. URI指定的表示形式。客户机指定它的表示形式

这不是问题。

接受取决于conneg(内容协商)。Conneg将让客户机通过accept:header决定他们接受的媒体类型。然后,响应将采用该格式,并带有Vary:Accept标题。

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

理想情况是实现以下两个方面: /资源(支持conneg的通用uri) /resource.xml /resource.json

由于您提到的是RESTful web服务,而不是任何web服务,因此我强烈支持底层标准—HTTP 1.1及其依赖的内容协商 Accept

正如我在回答问题时所解释的那样 Can I change the headers of the HTTP request send by the browser 、地址(URI)和表示是RESTful设计的两个截然不同的支柱,它们不需要混合使用。 接受 标题 .

干杯
肖齐拉

使用内容类型时出现问题。。。我在博客上讨论了这个问题 http://shouldersofgiants.co.uk/Blog 最后决定按照Richardson和Ruby在RESTfulWeb服务中的建议,在URI中包含表示

Chapter 5 - Representational State Transfer (REST) 部分 5.2.1.2陈述 罗伊·菲尔丁的 dissertation

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

看看这个链接,我们看到它指的是MIME。所以我假设用HTTP的说法,它是用 Content-Type Accept 获取的标题。

以下是本段的其余部分(完整性):

表示可以包含在消息中,并由 收件人根据消息的控制数据和性质 属于媒体类型。某些介质类型用于自动化 处理,其中一些用于呈现以供用户查看, 在一条消息中包含多个表示形式。

旁白:我不知道为什么人们从来不去看真正定义休息的地方。。。

编辑:我的意思并不是说这听起来像是很刺耳,更重要的是你必须注意内容类型,并且不能总是引用扩展