WSDL vs REST的优缺点

有关：

为什么要使用REST而不是Web服务？

在决定是否使用SOAP或REST（我指的是RESTful方式的HTTP / XML）实现Web服务时，我应该注意什么，应该考虑什么？我认为这不是一个万能的东西，所以我该如何选择使用哪种呢？

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

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了解SOAP，则SOAP很好。REST规范通常仅是人类可读的。

以下链接提供了有关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

关于WSDL（含义为“ SOAP”）为“重量级”。重物怎么办？如果工具集正在为您完成所有“繁重的工作”，那为什么重要呢？

我从未需要使用复杂的REST API。当我这样做时，我希望我希望有一个WSDL，我的工具将很高兴将其转换为一组代理类，因此我可以仅调用看似方法的对象。相反，我怀疑为了使用一个非平凡的基于REST的API，将有必要手工编写大量的“轻量级”代码。

即使完成了所有工作，您仍然会将人类可读的文档翻译成代码，随之而来的是人类会错误地阅读文档。由于WSDL是服务的机器可读描述，因此“错误地理解”要困难得多。

请注意：自从这篇文章以来，我有机会使用中等复杂的REST服务。确实，我确实希望获得WSDL或类似的东西，并且确实确实需要手工编写很多代码。实际上，开发时间的大部分时间都花在了删除所有“手工”调用不同服务操作的代码的重复代码上。

在上面的几篇文章中，这可能确实是评论的内容，但是我还没有代表来做，所以这里。

我认为有趣的是，在SOAP和REST中经常提到的许多利弊与（IMO）与这两种技术的实际价值或局限性几乎没有关系。REST最常被引用的优点可能是“轻量级”或趋于“更易读”。从某种程度上讲，这确实是正确的，REST确实具有较低的进入门槛-所需的结构比SOAP少（尽管我同意那些说好的工具在很大程度上是答案的人-太糟糕了，SOAP工具非常可怕）。

但是，除了最初的入门费用外，我认为REST印象来自请求URL的形式和大多数REST服务交换的数据的复杂性的结合。REST倾向于鼓励使用更简单，更易读的请求URL，并且数据也倾向于更易于消化。但是，REST固有的程度是什么，它们在何种程度上仅仅是偶然的。更简单的URL结构是该体系结构的直接结果-但它同样可以很好地应用于基于SOAP的服务。更易消化的数据更有可能是由于缺少任何定义的结构而导致的。这意味着您最好使数据格式保持简单，否则您将需要进行大量工作。所以这里是SOAP的附加结构，

因此，在用于计算机系统之间的结构化数据交换时，我不确定REST本质上优于SOAP（反之亦然），它们只是有所不同。我认为以上将REST，SOAP与动态和静态类型进行比较是一个不错的选择。动态语言往往会遇到麻烦的地方是系统的长期维护和保养（从长期来看，我不是在说一年或第二年，而是在说5或10）。有趣的是，随着时间的推移，REST是否会遇到同样的挑战。我倾向于认为，如果我要构建一个分布式的信息处理系统，那么我会倾向于使用SOAP作为通信机制（也是因为如上所述，它具有传输和应用程序协议的分层性和灵活性）。

尽管在其他地方，REST似乎更合适。客户端与其服务器之间的AJAX（无论有效负载如何）都是一个主要示例。我对这种连接的长寿性不太在意，并且易用性和灵活性是最大的。同样，如果我需要快速访问某些外部服务，并且我不认为我会在意交互的可维护性（再次，我认为这是REST最终将花费我更多钱的一种方式）或其他），那么我可能只是选择REST，这样我才能快速进入和退出。

无论如何，它们都是可行的技术，并且取决于您要对给定应用程序进行哪些折衷，它们可以为您提供良好（或较差）的服务。

REST不是协议。这是一种建筑风格。或如果您想要的范式。这意味着对SOAP的定义要宽松得多。对于基本的CRUD，您可以依靠Atompub等标准协议，但是对于大多数服务，您将拥有更多的命令。

作为消费者，取决于语言支持，SOAP可能是福还是祸。由于SOAP很大程度上是在严格类型化的系统上建模的，因此它最适合静态类型的语言。对于动态语言，它很容易变得多余和多余。另外，在Java和.NET之外，客户端库支持也不是很好。

对我来说，当我们使用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，而不再使用REST（因为xml本质上不是轻量，所以重量更轻）。我们将其称为Web服务吗？是的，我们可以，但是不会遵循任何当前的标准，这是这里的主要问题，如果我们开始调用所有Web服务，但是我们可以按照自己想要的方式进行操作，那么我们就失去了事物的互操作性。这意味着与Web服务交换的数据格式不再标准化。

人们不喜欢SOAP的原因是他们很难理解它，并且无法手动生成查询。但是计算机可以很好地做到这一点，因此我们需要弄清楚这一点：Web服务查询和响应是否应该由最终用户直接使用，还是我们同意Web服务位于计算机系统基于某种规范化调用的API之下？标准？

肥皂：它也可以通过SMTP传输，这意味着我们也可以使用Email简单文本格式调用服务

它需要在Web服务使用者机器中使用其他框架/引擎才能将SOAP消息转换为各种语言的相应对象结构。

休息：现在WSDL2.0还支持描述REST Web服务

当您想使服务轻巧时，例如从手机，pda等移动设备拨打电话时，我们可以使用...

对于将您的系统限制在公司内部的企业系统，由于您几乎可以控制客户，因此使用肥皂更容易且正确。这很容易，因为有各种各样的工具可以创建类（代理），并且看起来像您在执行与Java或.net环境（大多数公司使用的环境）相匹配的常规OOP。

由于客户端可以使用javascripts或html或其他输入类型不严格的应用程序，因此我会将REST用于面向Internet的应用程序以公开界面（例如twitter api）。REST更自由更有意义。

同样对于面向Internet的客户端（万维网），它更容易解析来自rest接口的json或xml，而不是来自soap接口的纯xml。很难在javascript上使用代理，而javascript自然不支持对象。如果您将REST与javascript结合使用，通常只需解析json字符串即可。面向Internet的接口通常非常简单（因此大部分时间都是其简单解析），并且通常不要求一致性，这就是REST足够足够的原因。

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

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

对不起，我的英语不好。

为了保护REST，它严格遵循HTTP和可寻址性的原则，例如，读取操作使用GET，更新操作使用POST等。我发现这是一种更为简洁的方法。Oreilly的RESTful Web Services一书比我能更好地解释了这一点，如果您阅读它，我认为您更喜欢REST方法

客户端上的工具集将是一个。以及对SOAP服务的熟悉程度。如今，越来越多的服务采用RESTful路线，并且可以使用简单的cURL示例来完成对此类服务的测试。虽然，实现这两种方法并允许客户最大程度地利用它并不是那么困难。

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

先前的答案包含很多信息，但是我认为尚没有指出哲学上的差异。SOAP是“如何创建RPC的现代，面向对象，平台和协议独立的后继者”的答案。REST是从以下问题发展而来的：“我们如何获得使HTTP在网络上如此成功的见解，并将其用于分布式计算？”

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

REST还很年轻-尽管它面向“人类可读”服务，但它并不排除自省服务等或自动创建代理的可能性。但是，这些尚未标准化（如我所写）。SOAP给您这些东西，但是（IMHO）给您“仅”这些东西，而REST所强加的样式由于其简单性已经在鼓励Web服务的普及。我自己会鼓励新手服务提供商选择REST，除非他们需要使用SOAP提供的特定功能。

以我的观点，那么，如果您正在实现“未开发的” API，并且对可能的客户端不甚了解，我会选择REST，因为它鼓励使用的样式倾向于使接口易于理解并且易于开发。如果您对客户端和服务器了解很多，并且有一些特定的SOAP工具可以使两者的工作变得轻松，那么我对REST不会一无所知。

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

REST几乎将您限制为HTTP（在许多情况下还可以）。

我知道这个讨论是一个古老的讨论，但是在阅读了所有答案并发表评论后，我相信每个人都错过了有关这两个系统之间最重要的一点：SOAP使用复杂类型不仅向您提供数据，还可以验证并将其保留在为其定义的严格类型名称中。WSDL告诉您数据格式是什么，数据类型是什么，允许您添加reg-ex模式样式规则，并定义请求/响应中必须允许（或可能允许）一条数据多少次。 。另一方面，这些机制都没有。

SOAP既复杂又繁重，因为它使您可以发送复杂的繁重的分层数据。REST是纯文本，由源和端点对规则进行排序。

SOAP是业务独立的，因为它具有嵌入在文档中的所有数据规则。

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