url - ReSTful URL 的标准应该是什么？

Question

由于找不到工作，我一直在阅读 ReST 并创建 Web 服务。按照我的解释， future 就是在构建 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 header 中发送内容类型。

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

另一方面，您可能会争辩说您应该“做最适合您的事情”。但据我所知，这并不真正符合 ReST 的心态，因为目标是要有一个标准。

由于你们中的很多人在 ReST 方面比我有更多的经验，我想我会寻求一些指导。所以，考虑到所有这些......

ReSTful URL 的标准应该是什么？

Answer 1

欢迎来到什么是 REST 和什么不是 REST 的困惑世界。首先，我建议您在错误的地方阅读有关 REST 的信息。试试 RESTWiki作为一个很好的起点。

REST 不是为您的 Web 应用程序提供数据服务的绝佳解决方案。 “Web 服务”(又名 SOAP、XML-RPC、WSDL、HTTP-POX)可能对此有好处，但 REST 架构风格比服务器-服务器场景更面向客户端-服务器场景。

停止思考 URL 的样子。它们的外观与您用来实现 RESTful 服务的服务器端框架有关，而不是服务本身的设计。客户端应该从先前检索到的表示中发现 URL，因此它实际上并不关心 URL 是什么样的。

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

不要版本资源。即，如果您有一个可通过 url http://example.org/TodaysWeather 访问的资源永远不要在 http://example.org/V2/TodaysWeather 创建资源.除了创建一个全新的资源之外，还有许多其他更好的方法来版本表示。搜索 SO 以了解有关此问题的许多其他讨论。

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

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