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

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

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

我记得几年前，SOAP非常流行（流行吗？），并且每个好的CV中都必须包含“ SOAP”项。但是实际上，它很少被使用并用于实现非常简单的目的。

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

您能否举几个例子说明应该使用REST的原因，为什么没有REST我们不能做同样的事情（或者为什么没有REST我们应该花更多的时间做同样的事情）？

UPD：很遗憾，我看不到任何具体的论点会在第一批评论中引起我的注意。让我认为REST是一项了不起的技术！

我想看到这样的答案：

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

- 哦，该死的！Jonny，我们当然应该使用REST来实现此应用！
–是的，比利，我们可以使用REST，但最好使用SOAP。相信我，因为我对开发HelloWorld应用程序有所了解。
–但是SOAP是上世纪的老式技术，我们可以使用更好的技术。
– Billy，您准备好花3天的时间试用REST吗？我们可以在2个小时内使用SOAP来完成此操作。–
是的，我敢肯定，我们将花费更多的时间来实现相同的安全性/性能/可扩展性/其他任何与SOAP相同的功能。我敢肯定，从现在开始，HelloWorld应用程序应仅使用REST开发。

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

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

我可以向您保证，实现这种低耦合水平并不容易。遵循REST的所有约束才能成功至关重要。维持纯粹的无状态连接是困难的。选择正确的媒体类型并将数据压缩为格式非常棘手。创建自己的媒体类型可能更加困难。

与相对简单的RPC方法相比，将丰富的服务器行为适配到统一的HTTP接口中可能会造成混乱，并且有时显得过于花哨。

尽管困难重重，但好处是您将拥有一个服务，由于HTTP协议的一致使用，客户端开发人员应该能够轻松理解该服务。由于超媒体，该服务应易于发现，并且客户端应对服务器上的更改具有极大的弹性。

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

更新资料

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

我认为REST已经变得流行，因为尝试进行SOA类型项目的人们发现使用SOAP堆栈并没有意识到所承诺的好处。人们继续转向网络，以简单的集成方法为例。不幸的是，我认为人们低估了创建Web所需的计划和远见，他们过分简化了要做的事情以允许发生在Web上的偶然重用。

您说您在实践中从未见过REST，但是如果您使用Web浏览器，那可能就不可能成立。Web浏览器是REST客户端。

• 当有人更改网站上的某些html时，为什么不需要更新浏览器？
• 为什么我可以在网站上添加一组完整的新页面，而“客户端”仍然可以访问这些新页面而无需更新？
• 为什么当我进入http://example.org/images/cat时，为什么不需要向Web浏览器提供“服务描述语言”来告诉它返回类型将是jpeg图像，以及何时访问到 http://example.org/description/cat 的返回类型将是text / html？
• 为什么使用Web浏览器访问发布浏览器时不存在的网站？客户如何知道这些网站？

这些听起来像是无聊的问题，但是如果您知道答案，那么您就可以开始了解REST的全部含义。查看StackOverflow了解REST的更多优势。当我看着一个问题时，我可以将该页面加为书签或将网址发送给朋友，他可以看到相同的信息。他无需浏览网站即可找到该问题。

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

这些是工作中的REST体系结构的示例。

现在，某些网站/应用程序确实违反了REST规则，因此浏览器无法正常工作。

• 臭名昭著的后退按钮问题 是由使用服务器端会话状态引起的。
• 当您具有服务器端会话状态时，负载平衡可能会变得很麻烦。
• Flash应用程序通常会阻止URL专门标识表示形式。
• 破坏Web浏览器的另一个问题是与媒体类型标准的一致性差。我们始终听到有关如何杀死IE6的信息。这里的问题是没有正确遵循标准，或者由于任何原因而忽略了标准。
• 登录会话的使用是许多安全漏洞的根源。

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

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

在论文的最上面是一个报价：

几乎每个人都与大自然融洽相处：在静静的湖边，在一片草地上，在被风吹拂的荒地上，听海浪拍打着岸边。有一天，当我们再次学习了永恒的方法时，我们将对我们的城镇有同样的感觉，就像今天在海边漫步，或者在长长的草丛中伸展一样，我们在城镇中也会感到和平。草地。

-克里斯托弗·亚历山大（Christopher Alexander），《永恒的建筑方式》（1979年）

确实可以总结出来。REST在许多方面都更加优雅。

SOAP是HTTP之上的协议，因此它绕过许多HTTP约定以在SOAP中建立新约定，并且在许多方面与HTTP无关。但是，HTTP足以通过HTTP检索，搜索，写入和删除信息，而REST就是很多。因为REST是使用HTTP而不是在HTTP之上构建的，所以这也意味着想要与之集成的软件（例如Web浏览器）不需要了解SOAP就能做到这一点，只需了解HTTP就可以了。目前已广泛使用并与之集成的协议。

从这里：

REST的优势：

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

还要检查这个出来：

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

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

只是为了吸引你

考虑一下什么是“传统的Web服务”。它是带有公开“方法”的接口。客户知道方法的名称，输入和输出，因此可以调用它们。

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

例如，考虑一下一个传统的Web服务，如果您提供城市信息，它可以提供当前的天气状况。它可能具有类似GetWeatherInfo（）的Web方法，该方法将城市作为输入并提供天气数据作为输出。到目前为止，您很容易了解客户端将如何使用此Web服务。

现在想象一下，代替上面的Web服务，有一个新的将城市作为对象公开。因此，当您将其视为客户端而不是GetWeatherInfo（）时，会看到纽约，达拉斯，洛杉矶，伦敦等。而且这些城市没有悬挂任何特定于应用程序的方法-它们显然像惰性气体-它们本身不会反应。

您必须在思考–好的，作为客户，这如何帮助您适应达拉斯的天气？稍后我们将解决这个问题。

如果从Web服务获得的只是“一组对象”，那么显然您需要一种“作用于它们”的方法。对象本身没有可供您调用的方法，因此您需要一组可应用于这些对象的操作。换句话说，您需要“将动词应用于名词”。如果您看到一个对象，例如一个苹果，它是一个“名词”，则可以对它应用“进食”等“动词”。但是，并非所有动词都可以应用于所有名词。例如，您可以驾驶汽车，但不能驾驶电视。

因此，如果Web服务仅公开对象，并且要求您-好，让我们现在设计一些标准的动作或动词，“所有客户端都可以将其应用于所看到的所有对象”，...

这里有一些想法：

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

最重要的是，REST从团队的工作流程中删除了许多最耗时且有争议的设计和实施决策。它将您的注意力从实施服务转移到设计服务。这样做无需将gobbledygook放到HTTP协议上。

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

我还必须承认，一些“优点”听起来似乎确实是对的，但我从未见过能说明其价值的例子。特别是，如果有人发表评论，其中包含指向REST Web服务示例的链接，我将不胜感激。这应该是使用多层资源（可能在层次结构中）并且正确使用媒体类型的资源。也许如果我看一个好的例子，我会理解的，在这种情况下，我会回到这里并承认这一点。

鉴于我们使用REST服务的原因，要对已经给出的答案稍加平淡无奇，我的意思是，如果您知道可以向业务合作伙伴提供URL，并且知道他们将收到一个布局良好的XML板，作为回报不管他们使用的是.Net xx，PHP，Python，Java，Ruby还是天知道的东西，它都能大大减轻您的头痛。

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

除了技术优势外，非技术人员也很容易解释，展示和自信，这是一件好事。SOAP，尽管对技术人员同样酷，但非技术人员却难以接近，因此“销售”并不容易。

我倾向于注意到，非技术人员可以解决的问题往往会坚持下去。因此，我怀疑REST作为一种技术是否容易像SOAP一样容易受到时尚的追捧。

但是，关于不将任何东西放到应该被锁定的REST服务中的所有事情都是对的，如果仅仅是因为该技术对于那些不那么精通技术的人来说很容易理解的话。

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＃等语言的标准库功能来“自己动手”。