REST - 为什么我们需要百万个 url 和不同的 HTTP 请求？ [复制]答案

【问题标题】：REST - why we need million urls and different HTTP request? [duplicate]REST - 为什么我们需要百万个 url 和不同的 HTTP 请求？ [复制]
【发布时间】：2011-06-02 06:52:30
【问题描述】：

可能重复：
REST API - why use PUT DELETE POST GET?

我问过这个question。但是我还是不明白为什么我们需要使用不同的 HTTP 请求：DELETE/PUT/POST/GET 来构建好的 API

在请求参数中传递所有信息并为您的 api 设置一个单一入口点不是更简单吗？：

GET www.example.com/api?id=1&method=delete&returnformat=JSON
GET www.example.com/api?id=1&method=delete&returnformat=XML

或

POST www.example.com/api {post data: id=1&method=delete&returnformat=JSON}
POST www.example.com/api {post data: id=1&method=delete&returnformat=XML}

然后 - 我们可以在内部处理所有方法和数据，而无需数百个 url...

您如何称呼这种类型的 API - 显然它不是 REST，也不是 SOAP。那么 - 它是什么？

更新我在这里没有提出任何新标准。我只是问了一个问题，以便更好地理解为什么 Web 服务会以它们的工作方式工作。

更新 2 唔。好的——在谷歌搜索了一段时间并查看了各种 API 之后——看起来这种方法最接近 JSON-RPC 的方法。看起来很有趣。它在雅虎邮件中实现，例如：yahoo mail json-rpc api

【问题讨论】：

我将这种类型的 API 或 URL 命名为“丑陋”。您需要使用不同的 HTTP 请求，因为这是创建这些请求的目的。
如果您认为您的系统有“更少”的网址，那您就是在自欺欺人。您正在以简单的路径换取更复杂的查询参数。其余的都是主观的......
AFAIK，SOAP over HTTP 对所有 Web 服务请求使用 POST 方法。但这是可行的，因为 SOAP 是另一种协议（和抽象），它独立于其底层协议，而纯 HTTP 服务（或我们应该称之为 RESTful 服务）当然不是这种情况。
嗯。看起来我在这里要描述的最好描述为：json-rpc

标签： web-services json rest soap

【解决方案1】：

利用 HTTP 动词是 RESTful 的一部分。通过使用查询字符串参数来指定您要对资源执行的操作，它不再是 REST。

REST 使用 HTTP 动词，因为它们在那里，它们是标准化的，而且您不必弄清楚方法名称可能是什么，这可能因 API 而异。当然，您可以制作一个新的 ANDREful 方法并指定方法参数必须始终称为方法，并且它只能包含某些值。

会更容易吗？这太主观了。你会给它取什么名字？随心所欲。

【讨论】：

拥有一个单一的 API 入口点主观感受如何？
我希望您的意思是“通过使用查询字符串参数 [指定 HTTP 方法]，它不再是 REST”，而不是完全禁止查询字符串参数。 REST 非常乐意让您使用查询字符串参数来识别资源。
一切都是主观的安德烈。 REST 只是一种做事方式，SOAP 也是。
糟糕，是的，谢谢 Darrell，更新了。

【解决方案2】：

我不得不使用按照您的建议设计 API 的应用程序。我现在编写 REST API，因为我有使用旧式 API 的经验。您提出的建议是大约 10 年前非常普遍的做法。从那以后，网络已经学会了，现在知道得更好了。

最后，您提议编写 API 的方式并不容易。这更难。为了每一个。操作长查询字符串并且只使用 GET 请求编写起来很麻烦，更难调试，并且实际上并没有比使用 REST 模型为您带来任何好处。在任何复杂的应用程序中拥有单一入口点并不是胜利——而是失败。曾经尝试过筛选此类应用程序的日志以找到有意义的内容吗？可以做到，但我宁愿在我的日志中找到一个“DELETE”，而不是“method=delete”。实际上，当您知道 HTTP 已经有一个 DELETE 方法时，'method=delete' 看起来不是有点多余吗？为什么要编写代码来实现您的网络服务器必须支持的东西，甚至声称它支持 HTTP？这简直太傻了！

根据我的经验，编写 REST API 始终意味着更少的代码、更直接的实现以及更容易测试和调试的实现。

从编写代码反对您的 API 的人的角度来看，同样的好处也适用。更少的代码，更直接，更容易测试。当我与编写有问题的 API 的编码人员一起工作时，确定问题的根源通常涉及将“curl -XDELETE”调用的输出与其代码的输出进行比较。不，真的——就是这样。如果 curl 有效而他们的代码无效，它通常会删除我的 API 作为问题的根源。

HTTP 请求的正文中也没有混乱的信息解析。在很多情况下，调用代码可以从标头中获取最重要的信息。如果你调用一个 PUT 或 DELETE 方法，你主要只是想知道它是否成功，在这种情况下你读取头部中的 HTTP 状态码。这也有使事情变得更快的副作用，因为在这些情况下，在标头之外不需要解析。

如果您只是按照自己提议的方式编写 API，我可以理解这种犹豫，但是当您第一次使用 REST 部署真正的生产应用程序时，您会发现该提议很愚蠢。

简而言之，与 REST API 相比，单个入口点并不简单，效率也不高，而且好处为零（而且问题更多）。

【讨论】：

在浏览器中使用 aPUT 和 DELETE 充满了问题。 Web 服务器通常禁用这些方法。防火墙通常会过滤这些方法。资源识别和统一界面的限制更多地与可见性和自描述性有关，而不是与服务器端开发工作的简易性有关。
他们是例子。此外，您显然不会在禁用所需方法的 Web 服务器上部署 REST 服务，并在过滤它们的防火墙后面。此外，REST API 不仅适用于浏览器。
哦，关于可见性和描述性的内容已包含在 OP 原始帖子的答案中，但他不明白。他似乎想要一些更具体、更少理论的理由来朝这个方向发展。
@jonesy 如果您编写要销售的产品，您将无法控制部署它的服务器。如果您将服务部署到 Web 上，您将无法控制位于您和客户端之间的防火墙。我知道网络浏览器并不是唯一的用户代理，但它们占了很大一部分。
@jonesy 当我谈论可见性和自我描述性时，我并不是在谈论 URI 的可读性。 URI 对系统组件是不透明的。然而，幂等/安全请求的问题绝对是请求的自描述性的重要部分，但不是唯一的部分。

【解决方案3】：

使用 URL 和 http 方法的原因是让中介对请求的作用有一个基本的了解。 REST 架构风格是一种分层架构，允许其他组件位于客户端和源服务器之间。这些组件可以是代理、缓存、防火墙、负载平衡器，几乎任何你想要的东西。 URL 是一种与中介交流您正在做什么的方式，而 HTTP 方法是对中介您正在做什么的粗略解释。

如果没有 URL 和 HTTP 方法，像 Squid 或 nginx 这样的缓存就无法工作。他们不知道用户正在尝试访问什么资源，也不知道何时使缓存条目无效。

如果您有一个没有中介的系统，那么您可以完全按照您的描述进行操作，并且几乎没有负面影响。但是，在您认为您没有使用任何中介之前，请意识到在 Windows 计算机上，Web 请求是通过 WinINetCache 路由的，WinINetCache 是位于客户端计算机上的 HTTP 中介。如果其他操作系统没有相同的功能，我会感到惊讶。

分层组件架构的使用是 REST 中通常被忽略的部分，但当使用它的潜力时，它可能会非常有价值。询问 Stack Overflow 开发人员。

另一个需要解决的关键问题是，毫不奇怪，您假设 REST 是关于创建 API 的。 REST 实际上是关于构建分布式系统。可以参与 REST 系统的逻辑服务器的数量没有限制。如果您再次考虑 stackoverflow 站点，图像来自一组不同的服务器，而不是来自另一组服务器而不是实际站点内容的 javascript 库。

定义所有数据应来自的单个端点严重限制了您对应用程序资源进行分区的能力。 RESTful 客户端不应耦合到系统的单个入口点，它们应该不知道资源的位置，而应该简单地遵循服务器在先前请求中为它们提供的 URL。这允许分布式系统随着时间的推移而发展，最初它托管在一个位置，并且随着需求的变化，它可以移动并在许多服务器上拆分。如果您的客户端绑定到单个入口点，您将无法执行此操作。

【讨论】：