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

我将学习 RESTful Web 服务(最好说我必须这样做，因为这是计算机科学硕士学位课程的一部分)。

我在维基百科上看到了一些信息，我也在 Sun Developer Network 上看到了一篇关于 REST 的文章，我发现这并不是一项简单的技术，有一些特殊的框架用于构建 RESTful 应用程序，它经常被拿来与 SOAP Web 服务进行比较，程序员应该明白何时使用 SOAP，何时使用 REST 可能是一种不错的方法。

我记得几年前 SOAP 非常流行(流行?)和项目“ SOAP”必须出现在每一个良好的简历。但在实践中，它很少被使用，而且只是为了达到非常简单的目的。

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

你能给我一些应该使用 REST 的例子吗? 为什么我们不能在没有 REST 的情况下做同样的事情(或者为什么我们应该花更多的时间在没有 REST 的情况下做同样的事情) ？

UPD : 不幸的是，我没有看到任何具体的论据可以在第一次评论中让我大吃一惊。让我觉得 REST 是一项了不起的技术！

我想看到这样的答案:

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

哦，该死! 强尼，我们应该 当然可以使用 REST 来实现 这个应用程序! 是的，比利，我们 可以使用 REST，但我们最好使用 SOAP 相信我，因为我知道一些事情 开发 HelloWorld 但 SOAP 是 上一代的老式技术 我们可以使用更好的 比利，你准备好了吗 花三天时间做实验 我们可以在2中使用 SOAP 来做这件事 几个小时. . 是的，我确定 我们会花更多的时间 达到同样的保安/性能/ /可伸缩性/使用 SOAP 的其他任何东西。 我相信 HelloWorld 的应用程序 应该只使用 REST 开发 从现在开始。

73402 次浏览
小开

来自 给你:

休息的好处:

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

还要检查 这个:

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

小开
最佳答案

如果在分布式应用程序的客户机和服务器组件之间使用 最小化耦合非常重要，那么应该使用 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 的更多好处，请查看 StackOverflow。当我看一个问题，我可以书签该页面或 把网址发给朋友，他可以看到相同的信息。他不需要浏览网站就能找到这个问题。

StackOverflow 使用各种 OpenId 服务进行身份验证，Gravatar.com 用于头像图像，google-analytics 和 Quantservice 用于分析信息。这种多公司一体化就是 SOAP 世界只有梦想这种东西。最好的例子之一是，用于驱动 StackOverflow UI 的 jQuery 库是从 Google 的内容传递网路中检索出来的。SO 可以指导客户端(比如你的浏览器)从第三方网站下载代码以提高性能的事实证明了 Web 客户端和服务器之间的低耦合性。

这些是 REST 体系结构的实例。

现在一些网站/应用程序执行 打破 REST 的规则，然后浏览器就不能像预期的那样工作了。

  • 臭名昭著的 < strong > 后退按钮问题 是由于使用服务器端造成的 会话状态。
  • 负载平衡可能成为一个痛苦时 您有服务器端会话状态。
  • Flash 应用程序通常会阻止 特定标识一个 代表。
  • 另一个破坏网络的问题 浏览器与 媒体类型的标准。我们听到的所有 关于 IE6需要怎样的时间 死了，问题是 标准没有得到适当遵守, 或者因为某种原因被忽视。
  • 登录会话的使用是 许多安全漏洞的来源。

REST 无处不在。是网络的一部分让它运行良好。如果你想建立一个分布式应用程序，它可以像网络一样扩展，像网络一样有弹性，可以像网络一样促进重复使用，那么就要遵循他们在建立网络浏览器时所遵循的规则。

小开

据我所知，REST 是由 Roy Fielding 的论文 体系结构风格与基于网络的软件体系结构设计开始的，如果您没有看过它，那么它值得一读。

论文的开头引用了一句话:

几乎每个人都感到与自然和平相处: 聆听海洋 波浪冲击着岸边，在一个平静的湖边，在一片草地上，在一个 有一天，当我们学会了永恒的道路 再一次，我们对我们的城市也会有同样的感觉，我们会像 就像我们今天在海边散步一样 伸展在长长的草地上

克里斯托佛·亚历山大《永恒的建筑方式》(1979)

REST 在很多方面都更加优雅。

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

小开

我们使用 REST 服务的原因是，如果你知道你可以给一个商业伙伴一个 URL，并且知道他们会收到，作为回报，无论他们是否在工作，都会收到一个精心设计的 XML 平板。Net x.x、 PHP、 Python、 Java、 Ruby 或者天知道是什么能够大大减少头痛。

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

除了技术上的好处，任何对于非技术人员来说容易解释、演示和感到自信的事情都是好事。SOAP，虽然对于技术人员来说同样很酷，但是对于非技术人员来说却不那么容易接近，因此也不容易“销售”。

我往往注意到，非技术人员能够理解的东西往往会坚持下去。因此，我怀疑 REST 作为一种技术是否会像 SOAP 一样容易受到时尚的影响。

但是，所有关于不把任何东西放入一个应该被锁定的 REST 服务的说法都是双重真理，因为这项技术很容易被那些没有技术头脑的人所理解。

小开

这里有一些想法:

  • REST 限制您的服务使用统一的接口。你不必浪费时间做白日梦(或争论)所有可能的方式您的服务可以工作-您得到正确的工作，确定在您的系统中的资源。事实证明，这本身就是一项大工程，但幸运的是，问题往往更加明确。
  • 有了资源、它们的关联和它们的表示，在实现您的服务方面真的没有什么可做的，因为已经为您做出了许多决定。
  • 您的系统将与其他 RESTful 系统非常相似; 将减少队友、合作伙伴和客户的学习曲线。
  • 您将拥有与其他开发人员讨论设计问题的通用词汇表，甚至可以与那些技术意识不强的人员(如客户)讨论设计问题。
  • 正如 Darrel 所说，因为您使用的是 超文本驱动设计，所以您的服务将耦合范围缩小到了一件事情——媒体类型。这对开发人员有帮助，因为对系统的更改包含在一个狭窄的联系范围内。这有助于您的客户端，因为您的更改中很少会破坏他们的代码。
  • 几乎在实现 REST 过程中遇到的所有问题都可以通过 暴露新的资源或重新考虑资源模型来解决。在我看来，这个重点是对生产力的巨大提升。

一句话，REST 从您的团队的工作流中移除了许多最耗时、最有争议的设计和实现决策。它把你的注意力从 执行你的服务转移到 设计它。而且它不需要在 HTTP 协议中添加官样文章就可以做到这一点。

小开

大多数关于 REST 的“专业”答案似乎来自那些从未开发过 SOAP Web 服务或使用为任务提供适当工具的环境的客户端的人。他们抱怨的问题，我从来没有遇到过，使用 VisualStudio。NET 和 IBM 的 RationalWebDeveloper。我认为，如果你不得不用脚本语言或其他语言开发网络服务或客户端，而且很少或根本没有工具支持，那么这些抱怨都是有根据的。

我也不得不承认，一些“优点”听起来像事实上可能是正确的事情-但我从来没有看到一个例子，说明他们的价值。特别是，如果有人能发表一条包含 RESTWeb 服务示例链接的评论，我将非常感激。这应该是一个使用多个资源级别，可能在一个层次结构中，并正确使用媒体类型。也许如果我看一个好的例子，我会明白，在这种情况下，我会回到这里，并承认它。

小开

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

只是为了拉你入伙,

想想什么是“传统的 Web 服务” 客户端知道方法的名称、输入和输出 因此可以称之为。

现在想象一个不公开“方法”的接口 所以当客户端看到这个接口时，它所看到的 是一个或多个“对象”。“对象”没有输入和输出- 因为“ It does not do anything”。它是名词，不是动词。它是“ a” “东西”，而不是“行动”。

例如，考虑一个传统的 Web 服务，它提供 当前的天气状况，如果你提供一个城市。它可能 有一个像 GetWeatherInfo ()这样的 web 方法，它将一个城市作为输入和 提供天气数据作为输出 了解客户端将如何使用这个 Web 服务。

现在想象一下，在上述 Web 服务的位置有一个新的 Web 服务 将城市作为对象暴露出来。所以，当你把它看作一个客户端时, 你看到的不是 GetWeatherInfo () ，而是纽约、达拉斯、洛杉矶, 伦敦等等。这些城市没有任何应用 特定的方法挂在他们-他们显然像惰性 气体本身不会发生反应。

你一定在想，作为一个客户，这对你有什么帮助 达拉斯的天气怎么样? 我们一会儿就会讲到的。

如果您从 Web 服务获得的只是“一组对象”，那么显然您 需要一种方法来“对它们采取行动”。对象本身没有方法 所以您需要一组可以应用到的操作 换句话说，你需要“在名词上应用动词”。 如果你看到一个物体，比如说，一个苹果，这是一个名词，你可以应用 “一个动词”喜欢吃，但不是所有的动词都适用于所有的动词 比如，你会开车，但不会开电视。

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

小开

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 # 等语言中的标准库特性“滚动自己的”。


提交答案