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心态,因为目标是制定一个标准.

而且由于很多人在使用ReST时会有比我更多的经验,我想我会要求一些指导.所以,考虑到所有这些......

ReSTful URLS的标准应该是什么？

Answer 1

欢迎来到REST是什么和什么不是REST的混乱世界.首先,我建议您在错误的地方阅读REST.尝试使用RESTWiki作为一个很好的起点.

REST不是为您的Web应用程序提供数据服务的绝佳解决方案."Web服务"(又名SOAP,XML-RPC,WSDL,HTTP-POX)可能对此有利,但REST架构风格更倾向于客户端 - 服务器场景而不是服务器 - 服务器场景.

不要再考虑URL的样子了.它们看起来与使用哪个服务器端框架实现RESTful服务有关,而不是服务本身的设计.客户端应该从先前检索的表示中发现URL,因此它实际上并不关心URL的外观.

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

不要版本资源.即如果您有一个由URL访问的资源,则http://example.org/TodaysWeather 不要在其中创建资源http://example.org/V2/TodaysWeather.版本表示有许多其他更好的方法,而不是创建一个全新的资源.在SO上搜索关于此的许多其他讨论.

至于为不同的内容类型创建不同的资源,我认为这是一个特定于上下文的决定.如果您的最终用户使用浏览器访问REST服务,并且他们足够复杂以了解JSON和XML之间的区别,那么请继续创建两个资源.如果它是一个机器客户端,那么我将使用内容协商来获得所需的格式.

最后,要小心,因为REST成为了一个流行词,因为有效的内容存在更多错误的内容.