WSDL与REST优点和缺点

Question

相关：

  

Why would one use REST instead of Web services?

在决定是否使用SOAP或REST（我以RESTful方式表示HTTP / XML）实现Web服务时，我应该注意什么以及我应该考虑什么？我认为这不是一刀切，所以如何选择使用哪一个。

Answer 1

这两种协议在现实世界中的用途非常不同。

SOAP（使用WSDL）是一种以文档传递为中心的重量级XML标准。这样做的好处是您的请求和响应可以非常好地结构化，甚至可以使用DTD。缺点是它是XML，并且非常冗长。但是，如果双方需要签订严格的合同（比如银行间通信），这就很好。 SOAP还允许您在文档上对WS-Security等内容进行分层。 SOAP通常与传输无关，这意味着您不一定需要使用HTTP。

REST非常轻量级，并且依赖于HTTP标准来完成它的工作。很高兴能够快速启动并运行有用的Web服务。如果你不需要严格的话 API定义，这是要走的路。大多数Web服务都属于这一类。您可以对API进行版本更新，以便API的更新不会破坏使用旧版本的人（只要他们指定版本）。 REST本质上需要HTTP，并且与格式无关（意味着您可以使用XML，JSON，HTML等）。

通常我使用REST，因为我不需要花哨的WS- *功能。如果您希望计算机使用WSDL了解您的Web服务，那么SOAP很好。 REST规范通常只是人类可读的。

Answer 2

以下链接提供了有关WSDL与REST的有用信息，包括优点和缺点

有几个关键点是

1）SOAP是为分布式计算环境而设计的，其中REST是为点对点环境设计的。

2）WADL可用于定义REST服务的接口。

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and-wadl

Answer 3

关于WSDL（意为“SOAP”）是“重量级”。重要的是怎么样？如果工具集为你做了所有“繁重的工作”，那为什么重要呢？

我从未需要使用复杂的REST API。当我这样做时，我希望我希望得到一个WSDL，我的工具很乐意转换成一组代理类，所以我可以调用看似方法的东西。相反，我怀疑为了使用一个非平凡的基于REST的API，有必要手动编写大量“轻量级”代码。

即使这一切都已完成，您仍然会将人类可读的文档翻译成代码，并伴随着人类错误阅读的伴随风险。由于WSDL是一种机器可读的服务描述，因此“读错了”要困难得多。

---

请注意：自从这篇文章以来，我有有机会使用中等复杂的REST服务。事实上，我确实希望获得WSDL或等价物，而且我确实必须手工编写大量代码。事实上，开发时间的很大一部分用于删除所有“手动”调用不同服务操作的代码的代码重复。

Answer 4

这可能真的属于以上几篇文章中的评论，但我还没有代表这样做，所以这里就是。

我认为有趣的是，SOAP和REST经常引用的许多优点和缺点（IMO）与这两种技术的实际值或限制几乎没有关系。可能被引用最多的REST专家认为它是“轻量级”或者往往更“人类可读”。在某种程度上，这确实是正确的，REST确实具有较低的进入门槛 - 所需的结构比SOAP要少（虽然我同意那些说好的工具在很大程度上是答案的人 - 太糟糕了，SOAP工具很多非常可怕）。

除了初始入门成本之外，我认为REST印象来自请求URL的形式和大多数REST服务交换的数据的复杂性。 REST倾向于鼓励更简单，更易读的请求URL，并且数据也更容易消化。但是，REST在多大程度上固有，以及它们在多大程度上仅仅是偶然的。更简单的URL结构是体系结构的直接结果 - 但它同样可以很好地应用于基于SOAP的服务。更难以消化的数据更可能是由于缺乏任何已定义的结构。这意味着您最好保持数据格式简单，或者您将要从事大量工作。因此，SOAP的附加结构应该是一个好处，实际上可以实现草率设计，然后将草率设计用作对技术的挖掘。

因此，为了在计算机系统之间交换结构化数据，我不确定REST本质上比SOAP更好（反之亦然），它们只是不同。我认为REST与SOAP之间的比较与动态与静态类型的比较是一个很好的。在动态语言倾向于遇到麻烦的地方是长期维护和维护系统（长期来说，我不是说一年或两年，我说的是5或10）。看看REST是否会遇到同样的挑战会很有趣。我倾向于认为如果我正在构建一个分布式的信息处理系统，我会倾向于将SOAP作为通信机制（也是因为它提供了传输和应用程序协议的分层和灵活性，如上所述）。 p>

在其他地方虽然REST似乎更合适。客户端与其服务器之间的AJAX（无论有效负载）是一个主要的例子。我不太关心这种连接的寿命，易用性和灵活性是最重要的。同样，如果我需要快速访问某些外部服务，我认为我不会关心交互的可维护性（再次我假设这是REST最终会花费我更多的钱，单向或者另一个），然后我可以选择REST，这样我就可以快速进出。

无论如何，它们都是可行的技术，并且取决于您希望为给定应用程序做出哪些权衡，它们可以为您提供良好（或很差）。

Answer 5

REST不是协议;这是一种建筑风格。或者如果你想要的范例。这意味着SOAP更加宽松。对于基本的CRUD，您可以依赖标准协议，例如Atompub，但对于大多数服务，您将拥有更多的命令而不仅仅是。

作为消费者，SOAP可能是一种祝福或诅咒，具体取决于语言支持。由于SOAP在严格类型的系统上进行了非常模型化，因此它最适用于静态类型语言。对于动态语言来说，它很容易变得苛刻和多余。此外，客户端库支持在Java和.NET世界之外并不是那么好用

Answer 6

对我来说，当我们使用Web服务这个词时我们应该小心。我们应该始终指明我们是在谈论SOAP Web服务，REST Web服务还是其他类型的Web服务，因为我们在这里谈论不同的事情，如果我们将所有这些服务命名为Web服务，人们就不会理解了。

基本上，SOAP Web服务已经很好地建立多年，它们遵循严格的规范，描述了如何基于SOAP规范与它们进行通信。 现在REST Web服务有点新，基本上看起来更简单，因为它们没有使用任何通信协议。基本上，当您使用REST Web服务时发送和接收的内容是纯XML。人们喜欢它，因为它们可以按照自己想要的方式解析xml，而无需处理像SOAP这样的更复杂的通信协议。

对我来说，REST服务几乎就像是要创建一个servlet而不是SOAP Web服务。 servlet获取数据并返回数据。数据格式基于xml。如果需要，我们还可以设想使用除xml之外的其他东西。例如，可以使用标签代替xml，而不是REST，而是其他东西（在重量方面可能更轻，因为xml本质上不轻）。我们会称这仍然是一项网络服务吗？是的，我们可以，但不会遵循任何现行标准，如果我们开始调用所有Web服务，这是主要问题，但我们可以按照我们想要的方式进行，然后我们就会失去互操作性方面的东西。这意味着与Web服务交换的数据格式不再标准化。那就要求服务器和客户端就数据的格式达成一致，而使用SOAP这已经预先定义了，服务器和客户端可以互操作而不需要彼此了解，因为它们遵循相同的标准。

人们不喜欢使用SOAP的是他们很难理解它并且无法手动生成查询。计算机可以很好地做到这一点，所以这是我们需要明确的地方：Web服务查询和响应应该由最终用户直接使用，或者我们是否同意Web服务位于由基于某些规范化的计算机系统调用的API下面标准是什么？

Answer 7

SOAP ：它也可以通过SMTP传输，意味着我们可以使用电子邮件简单文本格式调用服务

它需要额外的框架/引擎应该在Web服务消费者机器中将SOAP消息转换为各种语言的相应对象结构。

REST ：现在WSDL2.0也支持描述REST Web服务

我们可以在您希望将您的服务视为轻量级时使用，例如从手机，pda等移动设备拨打电话......

Answer 8

对于您的系统被限制在公司内的企业系统，使用soap更容易和正确，因为您几乎可以控制客户端。它更容易，因为有各种工具创建类（代理），看起来你正在做你的常规OOP，它匹配你的java或.net环境（大多数公司使用）。

我会将REST用于面向互联网的应用程序以暴露界面（如twitter api），因为客户端可以使用javascripts或html或其他不严格打字的人。 REST更自由更有意义。

对于面向互联网的客户端（万维网），它更容易解析来自休息界面的json或xml，而不是来自soap界面的纯xml。它很难在javascript上使用代理，javascript自然不支持对象。如果你使用REST和javascript，你通常会解析json字符串并且你已经关闭了。面向Internet的接口通常非常简单（因此大多数时候都是简单的解析）并且通常不需要一致性，这就是REST足够的原因。

对于企业应用程序，我不认为REST是足够的，因为事务，安全性，严格的类型，模式在企业应用程序开发中起着非常重要的作用，这就是为什么SOAP更适合它们。

我的结论是SOAP适用于企业系统，REST适用于Internet或WWW。 您可以互换使用它，但您可能会发现自己最终没有使用正确的工具来完成工作。

抱歉我的英语不好。

Answer 9

在为REST辩护时，它严格遵循HTTP和可寻址性原则，例如：读取操作使用GET，更新操作使用POST等。我发现这是一种更清晰的方法。 Oreilly的书RESTful Web Services解释得比我好得多，如果你读它我认为你更喜欢REST方法

Answer 10

客户端的工具集将是一个。并且熟悉SOAP服务另一方面。如今越来越多的服务正在使用RESTful路由，并且可以使用简单的cURL示例来测试这些服务。 尽管如此，实现这两种方法并不是那么困难，并且允许客户最广泛地使用它们。

如果您需要选择一个，我建议REST，它更容易。

Answer 11

之前的答案包含大量信息，但我认为尚未指出存在哲学上的差异。 SOAP是“我们如何创建一个现代的，面向对象的，平台和协议独立的RPC继承者？”的答案。 REST开发的问题是“我们如何利用这些见解使HTTP在网络上如此成功，并将它们用于分布式计算？”

SOAP是一个为您提供工具，使分布式编程看起来像...编程。 REST尝试强加一种样式来简化分布式接口，这样分布式资源就可以像分布式html页面一样互相引用。其中一种方法是尝试（主要）将操作限制为“CRUD”资源（创建，读取，更新，删除）。

REST仍然很年轻 - 虽然它面向“人类可读”的服务，但它并不排除内省服务等或自动创建代理。但是，这些还没有标准化（正如我所写）。 SOAP为您提供了这些东西，但是（恕我直言）为您提供“仅”这些东西，而REST强加的风格因其简单性已经鼓励了Web服务的传播。我本人鼓励新手服务提供商选择REST，除非他们需要使用特定的SOAP提供的功能。

在我看来，如果你正在实施一个“绿地”API，并且对可能的客户端知之甚少，我会选择REST作为它所鼓励的风格往往有助于使界面易于理解，并且易于开发至。如果您对客户端和服务器了解很多，并且有一些特定的SOAP工具可以让两者都轻松生活，那么我就不会对REST有所了解。

Answer 12

只需更改配置设置，即可轻松将WSDL-spewing WCF Web组件转换为其他用途。您可以跨HTTP，然后命名管道，TCP，自定义协议等，而无需更改您的代码。我相信WCF组件也可以更容易设置安全性，双向调用，事务，并发等等。

REST几乎限制了你对HTTP的限制（在许多情况下这很好）。

Answer 13

我知道这个讨论是旧的，但在阅读完所有答案并评论之后，我相信每个人都错过了关于两个系统之间差异的最重要的观点：SOAP使用复杂类型不仅为您提供数据，但要对其进行验证，并将其保留在为其定义的严格类型标识中。 WSDL告诉您数据格式是什么，数据类型是什么，允许您添加注册模式样式规则，并定义一个数据必须是多少次，并且可以在请求/响应中允许。 另一方面，没有这些机制。

SOAP复杂而繁重，因为它允许您发送复杂的重型分层数据。 REST是纯文本，原点和端点整理规则。

SOAP与业务无关，因为它具有嵌入在文档中的所有数据规则。

SOAP和REST之间的区别在于SOAP是一种独立的面向业务的架构。 REST是一个文本文档。