为啥我们需要 RESTful Web 服务？

Posted 2023-02-15

【中文标题】为啥我们需要 RESTful Web 服务？

【英文标题】：Why do we need RESTful Web Services?为什么我们需要 RESTful Web 服务？

【发布时间】：2010-11-24 23:27:59

【问题描述】：

我将学习 RESTful Web 服务（最好说我必须这样做，因为它是 CS 硕士学位课程的一部分）。

我在 Wikipedia 上阅读了一些信息，我还在 Sun Developer Network 上阅读了一篇关于 REST 的文章，我发现这不是一项简单的技术，有用于构建 RESTful 应用程序的特殊框架，并且经常将其与 SOAP 进行比较Web 服务和程序员应该了解何时使用 SOAP 以及何时使用 REST 是不错的方法。

我记得几年前 SOAP 非常流行（时尚？），并且每个好的简历中都必须出现“SOAP”项。但在实践中，它很少被使用并且用于实现非常简单的目的。

在我看来，REST 是另一个“时尚的最后一句话”（或者我可能完全错了，因为我从未在实践中见过 REST）。

您能否举一些例子，说明应该使用 REST，以及为什么没有 REST 我们不能做同样的事情（或者为什么我们应该花更多的时间在没有 REST 的情况下做同样的事情）？

UPD：不幸的是，我看不到任何具体的论据可以让我在第一次参加比赛时大吃一惊。让我觉得 REST 是很棒的技术！

我希望看到这样的答案：

我正在开发另一个综合体 HelloWorld 应用程序，我们需要 传输大量/微小的数据，我 向我的同事提出 REST 解决方案：

– 哦，该死的！强尼，我们应该 当然使用 REST 来实现 这个应用程序！ – 是的，比利，我们 可以使用 REST，但我们最好使用 肥皂。相信我，因为我知道一些 关于开发 HelloWorld 应用程序。 – 但是 SOAP 是 过去的老式技术 世纪，我们可以更好地使用 一。 – 比利，你准备好了吗 花了 3 天的时间进行实验 休息？我们可以在 2 中使用 SOAP 来做到这一点 小时.. – 是的，我确定 我们将花费更多时间 达到相同的安全性/性能/ /可扩展性/SOAP 的任何其他内容。 我确定 HelloWorld 应用程序 应该只使用 REST 开发 从现在开始。

【问题讨论】：

这不是一项了不起的技术——它是一项不同的技术。如果您想让某人说服您它很棒并且应该每次都使用，请尝试咨询顾问。

【参考方案1】：

我可以肯定地说，作为一个初学者，我花了很多时间来理解这一点，但这是从头开始使用 REST 的最佳链接！ http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

只是为了吸引你，

想想什么是“传统网络服务”。它是一个接口 暴露“方法”。客户知道方法的名称、输入和输出 因此可以调用它们。

现在想象一个不公开“方法”的接口。相反，它 暴露“对象”。所以当客户端看到这个界面时，它看到的都是 是一个或多个“对象”。 “一个对象”没有输入和输出—— 因为“它什么都不做”。它是名词，不是动词。它是一个 事物”，而不是“动作”。

例如，考虑一个传统的 Web 服务，它提供 当前的天气状况，如果您提供城市的话。大概 有一个像 GetWeatherInfo() 这样的网络方法，它将城市作为输入， 提供天气数据作为输出。到目前为止，您很容易 了解客户端将如何使用此 Web 服务。

现在想象一下，在上面的 web 服务的地方，有一个新的 将城市暴露为对象。因此，当您将其视为客户时， 你看到的是纽约、达拉斯、洛杉矶，而不是 GetWeatherInfo()， 伦敦等。而这些城市没有任何申请 悬挂在他们身上的具体方法——他们显然是惰性的 气体 - 它们本身不会发生反应。

您一定在想——好吧，这对作为客户的您有何帮助？ 了解达拉斯的天气吗？我们将在稍后讨论。

如果您从 Web 服务中获得的只是“一组对象”，那么显然您 需要一种“对他们采取行动”的方法。对象本身没有方法 供您调用，因此您需要一组可以应用的操作 这些对象。换句话说，您需要“将动词应用于名词”。 如果你看到一个物体，比如一个苹果，它是“名词”，你可以申请 “动词”就像吃一样，给它。但并非所有动词都可以应用于所有 名词。比如，你可以开车，但不能开电视。

因此，如果 Web 服务只公开对象，而您被问到 - 好吧， 现在让我们设计一些标准动作或动词，“所有客户 可以应用于他们看到的所有对象”，...

【讨论】：

那么用对象代替方法有什么好处呢？

【参考方案2】：

REST 是一种用于设计网络应用程序的架构风格。这个想法是，不是使用复杂的机制，如 CORBA、RPC 或 SOAP 来连接机器，而是使用简单的 HTTP 在机器之间进行调用。

在许多方面，基于 HTTP 的万维网本身可以被视为基于 REST 的架构。 RESTful 应用程序使用 HTTP 请求来发布数据（创建和/或更新）、读取数据（例如，进行查询）和删除数据。因此，REST 对所有四个 CRUD（创建/读取/更新/删除）操作都使用 HTTP。

REST 是 RPC（远程过程调用）和 Web 服务（SOAP、WSDL 等）等机制的轻量级替代方案。稍后，我们将看到 REST 是多么简单。

尽管简单，但 REST 功能齐全；在 Web 服务中，基本上没有什么是 RESTful 架构无法完成的。 REST 不是“标准”。例如，永远不会有针对 REST 的 W3C 推荐。尽管有 REST 编程框架，但使用 REST 非常简单，您通常可以使用 Perl、Java 或 C# 等语言的标准库功能“自行开发”。

【讨论】：

"在许多方面，基于 HTTP 的万维网本身可以被视为基于 REST 的架构。RESTful 应用程序使用 HTTP 请求来发布数据（创建和/或更新)、读取数据（例如，进行查询）和删除数据。因此，REST 将 HTTP 用于所有四个 CRUD（创建/读取/更新/删除）操作。“这是另一个很好的实际示例远离这个职位。谢谢。

【参考方案3】：

大多数关于 REST 的“专业”答案似乎来自从未使用为任务提供适当工具的环境开发 SOAP Web 服务或客户端的人。他们抱怨我在使用 Visual Studio .NET 和 IBM 的 Rational Web Developer 时从未遇到过的问题。我想，如果您必须使用脚本语言或其他几乎没有或根本没有工具支持的语言开发 Web 服务或客户端，那么这些都是有效的抱怨。

我还必须承认，有几个“专业”观点听起来可能是真的——但我从未见过能说明它们价值的例子。特别是，如果有人发表评论，其中包含指向 REST Web 服务的一个很好示例的链接，我将不胜感激。这应该是一个使用多个级别的资源，可能在一个层次结构中，并且正确使用媒体类型。或许我看一个好例子就明白了，这种情况下，我会回到这里承认。

【讨论】：

迄今为止公开可见的最佳示例是 Sun Cloud API。这是一个演练kenai.com/projects/suncloudapis/pages/… 只是为了证明我对 SOAP 的体验。我已经使用来自 Patterns and Practices 组的 Microsoft 的 Web Service Software Factory 构建并且仍然支持 ASMX Web 服务。我使用同一软件工厂的更高版本构建了基于 WCF 的服务。自 2007 年 5 月首次与 Biztalk 服务 SDK 一起发布以来，我还使用了 WCF 的 System.ServiceModel.Web。

John- REST API 的一个例子是 Amazon 的。它们同时具有@SOAP 和 REST API。它可能对你有用-docs.amazonwebservices.com/AmazonS3/latest/…

【参考方案4】：

如果在分布式应用程序中最小化客户端和服务器组件之间的耦合对您非常重要，则应使用 REST。

如果您的服务器将由您无法控制的许多不同的客户端使用，则可能会出现这种情况。如果您希望能够定期更新服务器而不需要更新客户端软件，也可能会出现这种情况。

我可以向您保证，实现这种低级别的耦合不容易做到。遵循 REST 的所有限制以取得成功至关重要。保持纯粹的无状态连接很困难。选择正确的媒体类型并将数据压缩成格式是很棘手的。创建自己的媒体类型可能更难。

将丰富的服务器行为适应统一的 HTTP 接口可能会令人困惑，与相对简单的 RPC 方法相比，有时会显得迂腐。

尽管有困难，但好处是您拥有一个客户端开发人员应该能够轻松理解的服务，因为始终使用 HTTP 协议。该服务应该由于超媒体而易于发现，并且客户端应该非常对服务器上的变化具有极高的弹性。

超媒体的好处和避免会话状态使负载平衡变得简单，服务分区变得可行。对 HTTP 规则的严格遵守使得调试器和缓存代理等工具的可用性变得非常棒。

更新

在我看来，REST 是另一种 “时尚的最后一句话”（或者我可以 完全错误，因为我从来没有 在实践中见过 REST）。

我认为 REST 已经成为时尚，因为尝试执行 SOA 类型项目的人们发现使用 SOAP 堆栈他们没有实现所承诺的好处。人们不断地回到网络作为简单集成方法的一个例子。不幸的是，我认为人们低估了创建网络所需的计划和远见，他们过度简化了需要做的事情才能允许在网络上发生的那种偶然重用。

您说您在实践中从未见过 REST，但如果您曾经使用过 Web 浏览器，这不可能是真的。 Web 浏览器是一个 REST 客户端。

为什么不需要做浏览器 当有人更改某些 html 时更新 在网站上？ 为什么我可以添加一套全新的 网页到网站和“客户” 仍然可以访问那些新页面 没有更新？ 为什么我不需要提供 “服务描述语言”到 网络浏览器告诉它什么时候去 http://example.org/images/cat 返回类型将是 jpeg 图像 当你去 http://example.org/description/cat 返回类型将是 text/html？ 为什么可以使用网络浏览器访问 时不存在的网站 浏览器发布了？怎么可能 客户知道这些网站吗？

这些问题听起来可能很无聊，但如果您知道答案，那么您就可以开始了解 REST 的全部内容了。 查看 *** 以了解 REST 的更多好处。当我查看问题时，我可以为该页面添加书签或将网址发送给朋友，他可以看到相同的信息。他不必浏览该网站即可找到该问题。

*** 使用各种 OpenId 服务进行身份验证，使用 gravatar.com 提供头像图像，使用 google-analytics 和 Quantserve 提供分析信息。这种多公司集成是SOAP 世界梦寐以求的事情。最好的例子之一是用于驱动 *** UI 的 jQuery 库是从 Google 的内容交付网络中检索到的。 SO 可以引导客户端（即您的 Web 浏览器）从第三方站点下载代码以提高性能这一事实证明了 Web 客户端和服务器之间的低耦合。

这些是工作中的 REST 架构的示例。

现在一些网站/应用程序确实违反了 REST 规则，然后浏览器无法按预期工作。

臭名昭著的

后退按钮问题

是由使用服务器端引起的 会话状态。 负载平衡可能会变得很痛苦 你有服务器端会话状态。 Flash 应用程序通常会阻止 来自特定标识的 URL 代表。 断网的另一个问题 浏览器不符合 媒体类型标准。我们听到所有 关于IE6需要如何的时间 被杀。问题在于 没有正确遵守标准， 或因任何原因被忽略。 登录会话的使用是 许多安全漏洞的来源。

REST 无处不在。它是网络的一部分，使它运行良好。如果您想构建可以像 Web 一样扩展的分布式应用程序，像 Web 一样灵活地进行更改并像 Web 一样促进重用，那么请遵循他们在构建 Web 浏览器时的相同规则。

【讨论】：

@Darrell：REST 到底如何减少 SOAP 上的耦合？或者，SOAP 如何增加 REST 上的耦合？您指的是 SOAP 客户端实际上需要了解 SOAP，而 REST 客户端只需要了解媒体类型？

@John 通常使用 SOAP 的方式会导致客户端要求“编译”了解每个服务器端端点、每个参数数据类型和每个返回类型。 SOAP 世界中没有尝试使用标准化类型在客户端和服务器之间传递数据的指南。这意味着客户端开发人员使用的每项新服务都有自己独特的一组类型、端点和交互协议。这就是耦合。

@John REST 尝试将交互协议标准化为 HTTP 动词的语义、IANA 注册类型的数据格式以及所有端点应该是动态可发现的。这意味着客户端/服务器耦合本地化为媒体类型的定义。正如 Rich 所说，“您的服务将耦合范围缩小到一件事——媒体类型。”

@Darrell：这不是传统意义上的耦合。客户端可以被认为是“耦合”到元数据（WSDL），而不是服务。考虑一个返回“Employee”的服务：int id;字符串名字，姓氏，街道地址1，街道地址2，城市，州；国际邮编;。您似乎建议我们向 IANA 注册“员工”，或者我们只是将“员工”视为名称/值对的关联数组。

@John 让我定义一下我所说的 WSDL 术语中的耦合是什么意思。想象一下能够拥有一个服务契约，您可以添加方法、删除方法和重命名方法，而无需重新编译客户端。还要考虑可以指导客户端使用这些新方法而无需重新编译。消息合约由 HTTP 固定，但可通过标头扩展，并且数据合约是唯一可能破坏客户端的更改，但是使用消息合约中的元数据，服务器可以动态地向客户端提供适当版本的数据合约。跨度>

【参考方案5】：

这里有一些想法：

REST 将您的服务限制为使用统一接口。您不必浪费时间做白日梦（或争论）您的服务可能的所有工作方式 - 您可以正确地识别系统中的资源。事实证明，这本身就是一项艰巨的工作，但幸运的是，这些问题往往得到了更好的定义。 有了资源、它们的关联和它们的代表，在实施您的服务时几乎没有什么可做的，因为已经为您做出了许多决定。 您的系统将与其他 RESTful 系统非常相似；队友、合作伙伴和客户的学习曲线将会缩短。 您将拥有一个通用词汇来与其他开发人员讨论设计问题，甚至与那些缺乏技术意识的人（例如客户）讨论设计问题。 正如 Darrel 所说，因为您使用的是 hypertext-driven 设计，所以您的服务将耦合范围缩小到只有一件事 - 媒体类型。这有助于您作为开发人员，因为对系统的更改包含在一个狭窄的联系范围内。这有助于您的客户减少您的更改会破坏他们的代码。 您在实施 REST 时可能遇到的几乎所有问题都可以通过 exposing a new resource 或重新考虑您的资源模型来解决。在国际海事组织看来，这一重点是生产力的巨大提升。

最重要的是，REST 从您的团队的工作流程中移除了许多最耗时和最有争议的设计和实施决策。它将您的注意力从实施您的服务转移到设计它。而且它不会在 HTTP 协议上堆积 gobbledygook。

【讨论】：

@John 如果我启动 VS 并创建一个 WCF 项目并创建一个具有 [ServiceContract] 属性的接口，我可以添加任何我喜欢的方法调用。 CreateCustomer(), MakeOrder(), ConfirmOrder(), VerifyOrder(), SubmitOrder(), CheckStockAvailability(), CancelOrder() 从这些方法中，你能告诉我应该使用什么顺序来处理订单吗？你能告诉我什么时候可以调用 CancelOrder() 吗？在确认订单之前我应该​​检查可用性吗？我应该在检查可用性之前验证订单吗？这个界面不太可能与做工资单的界面一致。

@Darrel：我看不出 REST 如何帮助解决这个问题。 MakeOrder 是否给出了 ConfirmOrder 和 CancelOrder 的 URL？客户端是否还不知道如何调用服务，而是需要数据驱动？

@John 没错。客户端知道可能会向它提供 ConfirmOrder url 和 CancelOrder url，但它不知道这些 url 是什么样的，并且只有在提供时才会跟随它们。你称它为数据驱动，Roy 称它为超媒体作为应用程序状态的引擎。

@Darrel：我想我从来没有见过任何关键业务服务，我想根据上一次调用传递的 URL 来确定下一次调用什么。

@JohnSaunders：那是因为 REST 调用不是关于方法调用，而是状态转换（想想状态机）。在任何给定状态下，RESTful 服务器都会指定有效的状态转换，并且用户或用户代理会选择它想要遵循的转换。

【参考方案6】：

考虑到我们在我所在的位置使用 REST 服务的原因，为已经给出的答案添加一个稍微平淡无奇的答案是，如果您知道您可以向业务合作伙伴提供一个 URL，并且知道他们将收到作为回报，一个精心布置的无论他们是在 .Net xx、php、Python、Java、Ruby 还是天知道，它都可以大大减少头痛。

这也意味着，在非技术方面，我们的销售人员可以向人们吹嘘我们的多功能 API，而不必担心看起来像个完整的木偶。

除了技术优势之外，任何对非技术人员来说很容易解释、演示和感到自信的事情都是一件好事。 SOAP，虽然对技术人员来说很酷，但对非技术人员来说却远不那么容易接受，因此并不那么容易“出售”。

我倾向于注意到，非技术人员可以理解的事情往往会坚持下去。因此，我怀疑 REST 作为一种技术是否会像 SOAP 一样容易受到时尚潮流的影响。

但所有关于不在 REST 服务中放入任何应该被锁定的东西的说法都是双重正确的，如果仅仅是因为技术很容易被没有技术头脑的人理解的话。

【参考方案7】：

据我所知，REST 是由 Roy Fielding 的论文 Architectural Styles and the Design of Network-based Software Architectures 启动的，如果您没有看过它，值得一读。

论文的顶部是引用：

几乎每个人都觉得与大自然和平相处：聆听大海的声音 海浪拍打着岸边，平静的湖边，草地上， 风吹的荒地。有一天，当我们学会了永恒的方式 再一次，我们会对我们的城镇有同样的感觉，我们也会有同样的感觉 在他们身上很平静，就像我们今天在海边散步一样，或者 伸展在草地的长草中。

— Christopher Alexander，《永恒的建筑方式》（1979 年）

这确实总结了那里。 REST 在许多方面更加优雅。

SOAP 是 HTTP 之上的协议，因此它绕过了许多 HTTP 约定以在 SOAP 中构建新约定，并且在许多方面与 HTTP 是多余的。然而，对于通过 HTTP 检索、搜索、写入和删除信息来说，HTTP 绰绰有余，这就是 REST 的大部分内容。因为 REST 是用 HTTP 构建的，而不是在它之上构建的，这也意味着想要与其集成的软件（例如 Web 浏览器）不需要了解 SOAP 就可以做到这一点，只需 HTTP，它必须是最广泛理解并与目前使用的协议集成。

【讨论】：

SOAP 是在 1998 年定义的。当时有多少 HTTP“约定”是约定？

据此w3.org/Protocols/HTTP/1.0/spec.html HTTP 自 1990 年以来一直在使用。那又如何？我们都知道 SOAP 使用 http 的唯一原因是因为端口 80 最有可能在防火墙上打开。微软不会再犯 DCOM 的错误了。

"REST 是用 HTTP 构建的，而不是在它之上" +1。整个线程对我理解使用 REST over SOAP 的有效性非常有帮助，反之亦然。

【参考方案8】：

来自here：

REST 优势：

轻量级 - 没有太多额外的 xml 标记 人类可读的结果 易于构建 - 无需工具包

同时检查this out：

公平地说，REST 并不是每个 Web 服务的最佳解决方案。需要安全的数据不应作为 URI 中的参数发送。大量数据（例如详细采购订单中的数据）很快就会变得繁琐甚至超出 URI 范围。在这些情况下，SOAP 确实是一个可靠的解决方案。但重要的是首先尝试 REST 并仅在必要时使用 SOAP。这有助于保持应用程序开发的简单性和可访问性。

【讨论】：

缺点评论不是很正确。通过将参数从 URI 移动到正文中，这仍然是不安全的。使用 SSL 确保安全。此外，当 uri 中的数据可能很长时，您可以使用 post 并将其放入正文中。大多数服务器端语言结合了来自 URI 参数和 POST 参数的数据，因此不需要对服务器进行任何更改。

@Emil - 请记住，SSL 并不总是可用的。有些人想要基于消息的安全性而不是基于传输级别的安全性。至于使用 POST 的主体...POST 是用于处理 REST 请求的动词之一。您不能总是重复使用它来满足您的需求。

一个大骗局：没有标准化的“描述”语言，如用于 SOAP 服务的 WSDL - 每个 REST 服务可能会或可能不会记录，并且文档质量与提供的服务非常不同.....

@Marc_s 如果正确完成 REST，则不需要像 WSDL 这样的“描述语言”。确实需要记录使用的媒体类型，但不应存在将端点与媒体类型耦合的文档。

@Darrel：对不起，我不买“无描述语言”的废话。即使文档类型已记录在案，也需要对其进行描述。此外，有些人实际上喜欢将内容反序列化为编程语言中的对象。在这种情况下，对服务可以发送和接收的内容进行机器可读的定义非常有用，因此您的工具可以创建相应的类和序列化代码。