REST和多种数据格式

Question

好的,这是事实.StackOverflow实现了REST风格.当您访问特定问题/ $ id/URL时,您会看到问题.内容以HTML格式返回,因为它是浏览器理解的内容.

我必须开发自己的REST服务.事实是我必须为相同的信息返回多种格式.例如,默认值可以是HTML,但我也可以返回XML或JSON.

问题是:实现这个的推荐方式是什么？三种选择(更多来自您的有用建议)

1. URL中的选项(例如http://example.com/questions/12345/?format=json)
2. 不同的界面(例如:对于json数据,您有http://example.com/questions/1234/json/或http://example.com/json/questions/12345/,对于xml数据,您有http://示例.com/questions/1234/xml / etc ...你明白了)
3. http标头接受:application/json

PUT(POST)操作也是如此.如果我想以不同的格式提交数据,我需要通知接收者我提供的格式,因此相同的情况(和问题)成立.

谢谢!

编辑:其他提案如下

4)为每种格式指定正确的URL,例如http://example.com/questions/12345.json.这看起来不错,但这不意味着,为了保持一致性,我们还应该有http://example.com/questions/12345.html吗？听起来如此1995 ... :)

PS:我讨厌降价将任意订单列入清单.如果我想从4开始,我应该能够做到.

Answer 1

选项#3,设置HTTP"Accept"标头,更符合HTTP规范,并且在REST纯粹主义者中,被认为是最正确的.它还意味着无论表示形式如何,您都保留相同的URL(资源).

但是,您可能会遇到无法设置Accept标头的用户代理,因此建议使用支持指定响应格式的备份机制.在这种情况下,我建议使用URL查询字符串参数.使用URL查询字符串参数意味着您保留相同的核心URL,无论返回的内容类型如何.这使得客户端应该只向该URL发出PUT而不是/foo/bar.json或/foo/bar.xml URL更清楚.

编辑:如果您决定使用URL后缀(即foo.json与foo？format = json),则需要考虑的另一件事是,您可能会遇到缓存代理问题.如果有人向/foo.json发出PUT,代理将不会将其解释为使/foo.xml无效的请求.但是,如果使用/ foo？format = json,则它们都存储在代理中的相同资源(/ foo)下.

Answer 2

我会选择选项 1（URL 参数），因为它最符合 REST 的原则，也是最实用的。

选项 2 听起来很糟糕 - 您正在谈论同一资源的不同表示形式，因此您应该为它们使用相同的 URI。

选项 3 有点难以控制——例如，您将如何在浏览器中手动测试它？

（同样的论点适用于PUT/ POST。）