REST和多种数据格式

时间:2009-08-08 22:40:38

标签: rest

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

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

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

    网址中的
  1. 选项(例如http://example.com/questions/12345/?format=json
  2. 不同的界面(例如:对于你有http://example.com/questions/1234/json/http://example.com/json/questions/12345/的json数据,对于xml数据你有http://example.com/questions/1234/xml/等等......你明白了这一点)
  3. http header Accept:application / json
  4. PUT(POST)操作也是如此。如果我想以不同的格式提交数据,我需要告知接收方我提供的格式,所以同样的情况(和问题)也是如此。

    谢谢!

    编辑:其他提案如下

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

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

3 个答案:

答案 0 :(得分:24)

选项#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)下。

答案 1 :(得分:4)

我会选择选项1 (URL参数),因为它最符合REST的原则,而且最实用。

选项2闻起来很糟糕 - 你在谈论同一资源的不同表示,所以你应该为它们使用相同的URI。

选项3有点难以控制 - 例如,你会如何在浏览器中手动测试?

(相同的论点适用于PUT / POST。)

答案 2 :(得分:2)

在1和2之间没有任何关系。一个URI是不透明的,所以从它的REST接口部分来看,没有区别。

从缓存的角度来看,1。将阻止许多缓存执行其工作。

  1. 如果您想对多个代表进行连接,那就没问题了。
  2. 通常,人们使用带有Accept标头的连接,可能使用/customer/21.json重定向到完全限定的URI