为什么我们需要 RESTful Web 服务？

Question

我将学习 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 开发 从现在开始。

Answer 1

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

只是为了吸引你，

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

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

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

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

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

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

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

Answer 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# 等语言的标准库功能“自行开发”。

Answer 3

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

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

Answer 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 的全部内容了。 查看 StackOverflow 以了解 REST 的更多好处。当我查看问题时，我可以为该页面添加书签或将网址发送给朋友，他可以看到相同的信息。他不必浏览该网站即可找到该问题。

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

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

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

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

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

Answer 5

这里有一些想法：

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

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

Answer 6

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

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

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

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

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

Answer 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，它必须是最广泛理解并与目前使用的协议集成。

Answer 8

来自here：

REST 优势：

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

同时检查this out：

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