REST - 为什么我们需要百万网址和不同的HTTP请求？

Question

  

可能重复：
  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}

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

你怎么称呼这种类型的API - 显然不是REST，它不是SOAP。 那么 - 它是什么？

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

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

Answer 1

URL和http方法的原因是允许中介基本了解请求正在做什么。 REST架构风格是一种分层体系结构，允许其他组件位于客户端和源服务器之间。这些组件可以是代理，缓存，防火墙，负载平衡器，几乎任何您想要的东西。 URL是一种与中介进行通信的方式，您正在处理的内容，以及HTTP方法对中间人的粗略解释。

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

如果你的系统没有中介，那么你可以完全按照你所描述的那样做，而且副作用很小。但是，在您认为自己没有使用任何中介之前，请在Windows计算机上实现，Web请求通过WinINetCache路由，这是一个HTTP中介，它位于客户端计算机上。如果其他操作系统没有相同的功能，我会感到惊讶。

分层组件体系结构的使用是REST 中常被忽略的部分，但是当习惯其潜力时可能非常有价值。询问Stack Overflow开发人员。

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

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

Answer 2

我不得不使用按照你的建议设计api的应用程序。我现在编写REST API，因为我使用旧式API。你提出的是大约10年前常见的做法。网络已经学会了，现在知道得更好。

最后，您提出编写API的方式并不容易。这更难。为了所有人。操作长查询字符串并且只使用GET请求，编写起来很麻烦，难以调试，并且实际上并没有使用REST模型购买任何东西。在任何复杂的应用程序中有一个入口点并不是一个胜利 - 这是一个损失。曾经试图筛选这样的应用程序的日志来找到有意义的东西吗？它可以完成，但我宁愿在我的日志中找到一个“删除”而不是'method = delete'。实际上，当知道 HTTP已经有 DELETE方法时，“method = delete”似乎有点多余吗？为什么要编写代码来实现您的Web服务器必须支持甚至声称它支持HTTP？那太傻了！

根据我的经验，编写REST API总是意味着更少的代码，更简单的实现，以及更容易测试和调试的代码。

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

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

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

简而言之，与REST API相比，单个入口点并不简单，效率不高，并且没有任何好处（并且只有更多问题）。

Answer 3

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

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

会更容易吗？这太主观了。你叫它什么名字？无论你想要什么。