Question

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

但是，对于Restful URL的最佳方案，似乎存在很多矛盾的想法。

有些人提倡简单漂亮的网址

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

此外，有些人喜欢将API版本添加到网址中，如此

为了让事情更加令人困惑，有些人主张添加内容类型来获取请求

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架构风格更倾向于客户端 - 服务器场景而不是服务器 - 服务器场景。

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

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

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

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

最后，请小心，因为REST成为热门话题，因此有更多错误信息的内容比有效内容更多。

Answer 2

动词无法放入网址。这是没有意义的。它已经在请求标题中。当您在URL中发送具有GET的POST请求时，这很疯狂。

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

Answer 3

我和S.Lott在一起 - 动词*不应该*在那里，因为你想使用相同的URL来读取记录，以及更新它以使其符合REST的条件。

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

我唯一被撕裂的是版本号，因为我个人无法想到适当的HTTP头来处理它的这个方面。（期待？接受编码？Pragma？甚至可能升级，但是出于兼容性考虑，你会更频繁地想降级到旧版本，我想）我可能有一个版本较少的访问器，它提供了最新版本生产版本，但可能会考虑为没有向后兼容的重大更改设置版本。

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

Answer 4

版本控制：我通常会在您的示例网址中看到这个位置，如果未指定版本，则应使用最新的生产版本进行响应。一个考虑因素是是否将API版本放在响应字符串中以进行客户端调试。

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

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