ReSTful URLS的标准是什么？

Question

由于找不到chuffing工作，我一直在阅读ReST和创建Web服务。我已经解释了它的方式，未来就是在构建Web应用程序之前为您的所有数据创建Web服务。这似乎是一个好主意。

然而，似乎有很多矛盾的想法是什么最好的方案是ReSTful网址。

有人主张简单漂亮的URL

http://api.myapp.com/resource/1 

此外，有些人喜欢在API版本添加到URL，像这样

http://api.myapp.com/v1/resource/1

使事情更加混乱，有人主张增加内容类型来获取请求

http://api.myapp.com/v1/resource/1.xml 
http://api.myapp.com/v1/resource/1.json 
http://api.myapp.com/v1/resource/1.txt 

而其他人认为内容类型应该在HTTP标头中发送。

Soooooooo ....这是很多变化，这让我不确定什么是最好的URL方案。我个人认为包含版本号，资源定位器和内容类型的最全面的URL的优点，但我是新手，所以我可能是错的。

另一方面，你可能会认为你应该做“最适合你的任何事情”。但据我所知，这并不符合ReST的思路，因为其目标是制定一个标准。

而且由于很多人会有比我更多的经验，所以我想请教一些指导。因此，考虑到这一切...

ReSTful URLS的标准是什么？

Answer 1

欢迎来到什么是和什么不是REST的混淆世界。首先，我会建议你在错误的地方阅读了关于REST的内容。尝试RESTWiki是一个很好的起点。

REST不是为您的Web应用程序提供数据服务的绝佳解决方案。 “Web服务”（又称SOAP，XML-RPC，WSDL，HTTP-POX）可能会有所帮助，但REST架构风格更倾向于客户端 - 服务器场景而不是服务器服务器场景。

不要再考虑网址的样子。他们看起来像使用哪个服务器端框架来实现RESTful服务，而不是服务本身的设计。客户端应该从以前检索的表示中发现URL，因此它并不关心URL的外观。

话虽如此，使用您的示例网址来尝试和区分你认为应该是不同的资源，我还有一些其他的建议。

不要版本资源。即如果您有一个资源被url http://example.org/TodaysWeather访问，请不要在http://example.org/V2/TodaysWeather创建资源。有很多其他更好的方式来表示版本，而不是创建一个全新的资源。搜索大量的其他讨论。至于为不同的内容类型创建不同的资源，我认为这是一个上下文特定的决定。如果您的最终用户使用浏览器访问REST服务，并且它们足够复杂以了解JSON和XML之间的差异，那么请继续并创建两个资源。如果它是一台机器客户端，那么我会使用内容协商来获得所需的格式。

最后，要小心，因为REST成为流行语，因为周围存在的错误信息远多于有效内容。

Answer 2

动词不能放入URL中。这是没有意义的。它已经在请求标题中。当你发送一个在URL中有GET的POST请求时，这太疯狂了。

响应格式通常最好放入URL中，因为标题不提供简单明确的地方放置该信息。

Answer 3

我与S.Lott - Verb *不应该在那里，因为您想使用相同的URL来读取记录，并更新它以使其符合REST要求。

内容类型是别的东西，因为它是相同的记录，但具有多种编码格式。 （阅读FRBR的方式比您想要了解的区别问题更多）。可以使用HTTP Accept标头处理决定发送哪个版本的响应。

唯一一个我讨厌的是版本号，因为我个人不会想到一个合适的HTTP头来处理它的方面。 （预计接受编码Pragma可能甚至是升级，但出于兼容性的原因，你会更经常地想降级到较旧的版本，我想）我可能会有一个版本较少的访问器，它提供了最新的生产版本，但可能会考虑有一个版本不适合向后兼容的重大更改。

更新：版本问题可能取决于您对连接到您的服务的客户端有多少控制权......如果你有从广泛的公众（我不这样做）访问，你可能更感兴趣的是向后兼容性。根据所做的更改，您可能会认为'版本2'是一种全新的资源，而不仅仅是原始版本的新版本。

Answer 4

版本控制：我通常在您的示例url中看到了它的位置，如果没有指定版本，您应该使用最新的生产版本进行响应。一个考虑因素是是否将API版本放在您的响应字符串中以用于客户端调试目的。

响应格式：返回格式应在用户代理发送的HTTP Accept报头中指定。

请求字符串中的动词：绝对不是。