使用 RESTful URL 能给我带来什么？答案

【问题标题】：What does using RESTful URLs buy me?使用 RESTful URL 能给我带来什么？
【发布时间】：2014-06-11 00:05:36
【问题描述】：

我一直在阅读有关 REST 的信息，并试图弄清楚使用它的优势是什么。具体来说，REST 样式的 URL 有什么优势，使其值得在更典型的带有查询字符串的 GET 请求中实现？

为什么是这个网址：

    http://www.parts-depot.com/parts/getPart?id=00345

认为不如这个？

    http://www.parts-depot.com/parts/00345

在上面的示例中（取自here），第二个 URL 确实看起来更加优雅和简洁。但这是有代价的……第一个 URL 很容易用任何网络语言实现，开箱即用。第二个需要额外的代码和/或服务器配置来解析值，以及额外的文档和花费时间向初级程序员解释系统并向同行证明它的合理性。

所以，我的问题是，除了拥有看起来很酷的 URL 的乐趣之外，RESTful URL 对我来说还有哪些优势可以让使用它们值得实施成本？

【问题讨论】：

只是好奇：哪些语言需要额外的代码和/或配置来实现后面的 URL？
我特别想到了 Java servlet。第二个 URL 的普通实现将涉及调用 request.getURL()，将 URL 路径拆分为令牌，并使用令牌做一些事情。这不是很多工作，但它不像调用 request.getParameter("parameterName") 那样干净。或者，您可以保留 request.getParameter()，并让 Web 服务器层使用 mod-rewrite 配置重写第二个 URL，使其看起来像第一个 URL……如果您必须更新一个，这似乎是要走的路一堆现有的服务到新的 URL 样式。

标签： web-services url rest

【解决方案1】：

希望如果你让你的 URL 指向一个名词，那么你就有更好的机会正确地实现 HTTP 动词。除此之外，一个 URL 相对于另一个 URL 绝对没有优势。

现实情况是，URL 的内容与 RESTful 系统完全无关。它只是一个标识符。

重要的不是它的样子，重要的是你用它做什么。

【讨论】：

【解决方案2】：

查看 REST 的一种方式：

http://tomayko.com/writings/rest-to-my-wife（遗憾的是，它现在已被删除，但仍可以在 web.archive.org 上看到）

无论如何，HTTP——这个协议和他的朋友们创造的——就是关于将动词应用于名词。例如，当您访问网页时，浏览器对您键入的 URL 执行 HTTP GET 进进出出一个网页。

...

相反，大多数人都很忙编写复杂的层做这些事情的规范一种不同的方式，几乎不像有用的或雄辩的。名词不是通用和动词不是多态的。我们正在扔掉数十年的实际现场使用和证明技术和重新开始看起来很像其他的东西过去失败的系统。我们使用 HTTP 只是因为它帮助我们与我们的网络交谈并保安人少。我们在交易简单的浮华工具和巫师。

【讨论】：

【解决方案3】：

有一件让我印象深刻的事情（顺便说一句很好的问题）就是他们所描述的。第一个描述一个操作（getPart），第二个描述一个资源（part 00345）。

另外，也许您不能将其他 HTTP 动词与第一个一起使用 - 例如，您需要一个新的 putPart 方法。第二个可以使用不同的动词（如 PUT、DELETE、POST）来“操纵”资源？我想你也有点说 GET 两次——一次是动词，一次是方法，所以第二次更符合 HTTP 协议的意图？

【讨论】：

这个答案暗示 REST 不仅仅是拥有漂亮的 URL。它是关于按照设计使用的方式使用 HTTP 协议，即将逻辑动词/方法应用于名词/资源/URL。

【解决方案4】：

作为一个精明的网络用户，我一直很喜欢，但肯定不应该将其用作何时使用此类 URL 方案的指导原则，即这些类型的 URL 是“可破解的”。特别是对于博客之类的内容，我可以在 URL 中编辑日期或页码，而不必查找“下一页”按钮的位置。

【讨论】：

所有 URL 都是可破解的。如果您依靠人们不猜测您的 URLS 作为某种安全机制，那么您做错了，并且 URL 方案是您的问题中最少的。
我认为 Daniel 的意思更像是，而不是浏览你臃肿、无意义的 UI，他可以通过修改 URL 来找到东西。这当然是我更喜欢 RESTful URL 的原因之一。
@notJim 这正是我的意思。如果您的分页控件很糟糕，那么我是否可以轻松地将http://foo.com/article-name/page/1 变成http://foo.com/article-name/page/2 而不是拥有http://foo.com/display_article.php?item=412551 对我来说并不重要

【解决方案5】：

REST IMO 的最大优势在于它允许以简洁的方式使用 HTTP 动词（这是 REST 服务中最重要的）。实际上，使用 REST 意味着您使用的是 HTTP 协议及其动词。

使用你的网址，并想象你想发布一个“部分”，而不是得到它

第一种情况应该是这样的：

您在本应使用帖子的地方使用 GET

http://www.parts-depot.com/parts/postPart?param1=lalala&param2=lelele&param3=lilili

在 REST 上下文中，它应该是

http://www.parts-depot.com/parts

在body上，（例如）这样的xml

<part>
   <param1>lalala<param1>
   <param2>lelele<param1>
   <param3>lilili<param1>
</part>

【讨论】：

我认为这是迄今为止最好的解释，尽管我仍然不相信 RESTful URL 样式正在修复一些被破坏的东西。无论您是在 GET 请求中使用查询字符串还是将该数据存储在 URL 中，它仍然完全可以在同一个 URL 上使用 GET 和 POST。为什么不推荐使用该解决方案以支持 RESTful URL？它真的只是归结为“干净”的 URL 本身就很好吗？或者我可以用 REST URL 做些什么，而这些 REST URL 在普通的旧 HTTP 请求范式下不起作用？
正如我在回答中所说的（也许我不够清楚），REST 打算使用 HTTP 动词，因为它们的设计目的是......你可以用 GET/POST 做任何事情。但是，如果没有 PUT VERB，您应该如何更新幂等资源？您可以使用 POST 甚至 GET 来完成，但是如果 HTTP 协议上有一个 VERB 来执行此操作，为什么不使用它呢？它应该更干净，更容易理解，并且无论如何您都将使用该协议，因此请按照协议本身所期望的那样使用它...... :)
没有 REST URL 这样的东西。

【解决方案6】：

URI 语义由RFC 2396 定义。与这个问题特别相关的摘录是 3.3。 “路径组件”：

路径组件包含特定于权限（或方案，如果没有权限组件），标识资源在该计划和权限的范围内。

和3.4“查询组件”：

查询组件是要被解释的信息字符串资源。

请注意，查询组件不是资源标识符的一部分，它只是要由资源解释的信息。

因此，您的第一个示例所标识的资源实际上只是 /parts/getPart。如果您的意图是 URL 应该标识一个特定的部分资源，那么第一个示例不会这样做，而第二个示例 (/parts/00345) 会这样做。

所以第二种 URL 样式的“优点”是它在语义上是正确的，而第一种则不是。

【讨论】：

这句话引人入胜。我将不得不深入研究这一点，因为我看到罗伊在几次似乎与此直接矛盾的声明中发表了声明。
查看 RFC3986 替换 RFC2396 labs.apache.org/webarch/uri/rfc/rfc3986.html#query。在查询部分 3.4 中有以下引用 查询组件包含非分层数据，这些数据与路径组件中的数据一起用于标识 URI 方案范围内的资源
嗯，有趣...我没有意识到语义已经被更新的 RFC 改变了。我几年前读过原著；我只是假设更新不会显着改变语义。这将教会我落后于时代。好的，所以看起来在 2004 年这个答案是正确的，但现在它是错误的：-S

【解决方案7】：

"第二个需要额外的代码和/或要解析的服务器配置输出值，”

真的吗？那么，你选择了一个糟糕的框架。我的经验是 RESTful 版本的代码量完全相同。也许我只是幸运地进入了一个很酷的框架。

"以及其他文档以及解释系统所花费的时间致初级程序员”

只有一次。得到之后，你就不用再解释了。

“并向同行证明它的合理性。”

只有一次。得到之后，你就不用再解释了。

【讨论】：

这些都是很好的 cmets，我同意你的看法。但我认为你并没有真正回答这个问题。 “我的问题是，除了拥有看起来很酷的 URL 的乐趣之外，RESTful URL 对我来说还有哪些优势可以让使用它们值得实施成本？”
@Diego Das：这个“问题”并不明智。没有实施成本。基本前提是三件看似毫无根据的抱怨。
一切都是有代价的。挖掘文档以了解如何在我们使用的多个框架中实现此功能需要花费时间。如果我必须向 10 位开发人员教授我所学的方法，并且那次会议持续 30 分钟，那么我的公司将花费 500 美元。如果我必须说服持怀疑态度的同事以花哨的新方式做某事，而不是尝试过的和真实的，那会花费我的政治资本。在我完成所有这些之前，我想知道这种改变是否值得以及为什么值得。
@Spike Williams：与长期的维护、增强、适配和运营成本相比，您的“成本”实际上为零。与干净、简单、易于理解的界面的“价值”相比，您的成本实际上为零。学习新事物（并改变你的习惯）是一种好处，而不是成本。我不明白为什么像与同事交谈这样的小事甚至算作“成本”。您确实与他们交谈，不是吗？讨论 REST 与任何其他对话有何不同？
@Spike Williams：假设你告诉你持怀疑态度的同事一种更好的做事方式，我认为从长远来看你会获得政治资本，而不是花钱。

【解决方案8】：

不要在不是查询或搜索的 URL 中使用查询/搜索部分，如果您这样做 - 根据 URL 规范 - 您可能会暗示您并不真正想要的有关该资源的某些内容。

将查询部分用于作为某些更大资源子集的资源 - 分页是一个很好的例子，可以应用它。

【讨论】：