WSDL与REST的优点和缺点
有关：
为什么会使用REST而不是Web服务？
在决定是否使用SOAP或REST（我的意思是HTTP / XML以REST方式）实现一个Web服务时，我应该注意什么，我该怎么想？ 我认为这不是一个大小适合所有的事情，所以我该如何select使用。
这两个协议在现实世界中有着非常不同的用途。
SOAP（使用WSDL）是一个以文档传递为中心的重量级XML标准。 这样做的好处是您的请求和响应可以很好地结构化，甚至可以使用DTD。 缺点是它是XML，而且非常冗长。 但是，如果双方需要有一个严格的合同（比如说银行间通信），这是很好的。 SOAP还允许您在文档上对WS-Security进行分层。 SOAP通常是传输不可知的，这意味着你不一定需要使用HTTP。
REST非常轻便，依靠HTTP标准来完成它的工作。 获得一个有用的Web服务，并快速运行是非常好的。 如果你不需要严格的API定义，这是要走的路。 大多数Web服务都属于这个类别。 您可以对您的API进行版本化，以便对使用旧版本的用户（只要指定版本）的API进行更新即可。 REST本质上需要HTTP，并且是格式不可知的（意味着你可以使用XML，JSON，HTML等等）。
通常我使用REST，因为我不需要花哨的WS- *function。 如果您希望计算机使用WSDL来理解您的Web服务，那么SOAP是很好的。 REST规范通常只有人类可读的。
以下链接提供了有关WSDL和REST的有用信息，包括优点和缺点
一些关键点是
1）SOAP是为分布式计算环境而devise的，REST是针对点对点环境而devise的。
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）与这两种技术的实际价值或限制很less有关。 对于REST来说，引用最多的专家可能是“轻量级”，或者更倾向于“可读性”。 从某种意义上讲，REST的确有一个较低的进入门槛 – 与SOAP相比，所需的结构要less一些（尽pipe我同意那些认为好的工具在很大程度上是答案的人 – 很糟糕的是，大部分的SOAP工具是相当可怕）。
除了最初的入门成本之外，我认为REST印象来自请求URL的forms和大多数REST服务交换的数据的复杂性。 REST倾向于鼓励更简单，更人性化的请求URL，并且数据也趋于更易消化。 然而，这些REST固有的程度到底在多大程度上只是偶然的。 更简单的URL结构是架构的直接结果 – 但它也可以同样适用于基于SOAP的服务。 更可消化的数据更可能是由于缺乏任何确定的结构。 这意味着你最好保持你的数据格式简单，否则你将进行大量的工作。 所以在这里，SOAP的额外结构，应该是一个好处，实际上是使得草率的devise和马虎的devise，然后被用来挖掘技术。
因此，为了在计算机系统之间交换结构化数据，我不确定REST本质上比SOAP更好（反之亦然），它们只是不同而已。 我认为上面的REST与SOAP比较dynamic与静态types是一个很好的比较。 如果说dyanmic语言往往会遇到麻烦，那就是长期维护和维护一个系统（而且长期来说，我不是说一两年，我说的是5或10）。 看看REST是否会随着时间的推移而遇到相同的挑战将是有趣的。 我倾向于认为，如果我正在build立一个分布式的信息处理系统，我会倾向于使用SOAP作为通信机制（也是因为上面提到的传输和应用协议分层和灵活性）。
在其他地方，虽然REST似乎更合适。 客户端和服务器之间的AJAX（无论有效载荷）是一个主要的例子。 我不太在乎这种连接的长久性，易用性和灵活性处于最佳状态。 同样，如果我需要快速访问一些外部服务，我不认为我会在一段时间内关心交互的可维护性（再次，我认为这是REST最终会花费我更多，一种方式或另一个），那么我可能会selectREST，这样我就可以快速进出。
无论如何，他们都是可行的技术，并根据您想要为给定的应用程序做什么折衷，他们可以为您服务（或很差）。
REST不是协议; 这是一种build筑风格。 或者如果你想要的范例。 这意味着SOAP是一个很宽松的定义。 对于基本的CRUD，你可以依赖Atompub等标准协议，但是对于大多数服务，你将拥有比这更多的命令。
作为一个消费者，取决于语言的支持，SOAP可以是一个祝福或一个诅咒。 由于SOAP在严格types的系统上非常模仿，所以对于静态types的语言来说，效果最好。 对于一个dynamic的语言来说，它可能很容易变得笨重和多余。 另外，客户端库支持在Java和.NET之外并不是那么好
对我来说，当我们使用Web服务这个词的时候，我们应该小心。 我们应该一直指定我们是在说SOAP Web服务，REST Web服务还是其他types的Web服务，因为我们在这里讲的是不同的事情，如果我们把它们全部命名为Web服务，人们就不理解了。
基本上SOAP Web服务已经build立了很多年，它们遵循一个严格的规范，描述了如何基于SOAP规范与它们进行通信。 现在，REST Web服务更新一些，基本看起来更简单，因为它们没有使用任何通信协议。 基本上，当您使用REST Web服务时，您发送和接收的是纯XML。 人们喜欢它，因为他们可以按照自己想要的方式parsingxml，而无需处理更复杂的SOAP通信协议。
对我来说，REST服务几乎就像创build一个servlet而不是SOAP Web服务一样。 该servlet获取数据并将数据返回。 数据的格式是基于xml的。 如果我们想要，我们也可以想象使用别的不是xml的东西。 例如，标签可以用来代替xml，这不会是REST，而是其他的东西（可能会更轻，因为xml本质上不是轻量级的）。 我们会称这仍然是一个networking服务？ 是的，我们可以但不会遵循任何当前的标准，这是如果我们开始调用所有的Web服务，但我们可以按照我们想要的方式做到这一点，这是主要的问题，然后我们失去了互操作性的一面。 这意味着与Web服务交换的数据的格式不再标准化。 这就要求服务器和客户端对数据格式达成一致，而对于SOAP，这已经全部预先定义好了，服务器和客户端可以互相操作而不需要彼此了解，因为它们遵循相同的标准。
用SOAP不喜欢的是，他们很难理解它，而且他们不能手动生成查询。 计算机可以做得非常好，但是这是我们需要清楚的地方：Web服务查询和响应是否应该由最终用户直接使用，或者我们是否同意Web服务位于计算机系统调用的API的基础上标准是什么？
SOAP ：它也可以通过SMTP传输，也就是说我们可以使用Email简单的文本格式来调用服务
它需要额外的框架/引擎应该在Web服务消费者机器中将SOAP消息转换成各种语言的各个对象结构。
REST ：现在WSDL2.0也支持描述REST Web服务
我们可以使用，当你想使您的服务作为轻量级，例如手机，PDA等移动设备呼叫…
对于你的系统被限制在你的公司内的企业系统来说，使用肥皂更容易和适当，因为你几乎可以控制客户。 因为有各种各样的工具可以创build类（代理），并且看起来像是在执行与您的java或.net环境（大多数企业使用的）相匹配的常规OOP。
我会使用REST的互联网面临暴露接口的应用程序（如Twitter的API），因为客户端可以使用JavaScript或HTML或其他types的打字不严格。 REST更自由更有意义。
对于面向互联网的客户端（万维网）来说，它更容易parsing来自一个rest界面的json或xml，而不是来自一个soap界面的纯粹的xml。 在JavaScript上使用代理很困难，而且JavaScript自然不支持对象。 如果你正在使用JavaScript的REST，你通常只是parsingJSONstring，你就离开了。 面向互联网的界面通常非常简单（所以大部分时间都是简单的parsing），而且通常不需要一致性，这就是为什么REST足够了。
对于企业应用程序，我不认为REST是足够的，因为事务，安全性，严格打字，模式在企业应用程序开发中扮演着非常重要的angular色，这就是为什么SOAP更适合他们的原因。
我的结论是SOAP是用于Enterprise系统的，REST是用于Internet或WWW的。 你可以互换使用它，但是你可能会遇到困难，最终不能使用正确的工具。
对不起，我的英语不好。
为了保护REST，它严格遵循HTTP和可寻址性原则，例如，读取操作使用GET，更新操作使用POST等。我觉得这是一个更清洁的方法。 Oreilly的书RESTful Web Services解释了这一点，比我所能做的更好，如果你阅读它，我认为你更喜欢REST方法
客户端的工具集将是一个。 另外对SOAP服务的熟悉程度。 现在越来越多的服务正在使用RESTful路线，并且可以用简单的cURL实例来testing这些服务。 尽pipe实施这两种方法并不是那么困难，并且允许来自客户的最广泛的利用。
如果你需要select一个，我会build议REST，这很容易。
以前的答案包含了很多信息，但是我认为有一个没有被指出的哲学差异。 SOAP是“如何创build一个现代的，面向对象的，独立于平台和协议的RPC的后继者”的答案。 REST从这个问题发展而来，“我们如何利用使HTTP在networking上如此成功的见解，并将其用于分布式计算？
SOAP是一个向您提供的工具，使分布式编程看起来像…编程。 REST试图强加一种风格来简化分布式接口，使分布式资源可以像对方分布式的HTML页面一样互相引用。 其中一种方法是尝试（主要）将操作限制为资源上的“CRUD”（创build，读取，更新，删除）。
REST还很年轻 – 虽然面向“人类可读”的服务，但并不排除自省服务等，或者自动创build代理。 但是，这些还没有标准化（正如我写的）。 SOAP给了你这些东西，但是（恕我直言）给你“仅”这些东西，而REST强加的风格已经在鼓励Web服务的传播，因为它的简单性。 我自己鼓励新手服务提供者selectREST，除非他们需要使用特定的SOAP提供的function。
因此，在我看来，如果你正在实施一个“绿地”API，并且不太了解可能的客户端，我会selectREST，因为它的风格倾向于使界面易于理解，易于开发。 如果你对客户端和服务器有很多了解，并且有一些特定的SOAP工具可以使两者都变得简单，那么我不会对REST产生信心。
您只需通过更改configuration设置即可轻松将您的WSDL WCF Web组件转换为其他用途。 你可以通过HTTP，然后命名pipe道，tcp，自定义协议等，而不必改变你的代码。 我相信WCF组件也可能更容易设置安全性，双向调用，事务，并发等等。
REST几乎限制了你的HTTP（这在很多情况下是好的）。
我知道这个讨论是旧的，但是在阅读完所有的答案和评论之后，我相信每个人都错过了关于这两个系统之间差别的最重要的一点：SOAP使用复杂types不仅给你提供数据，而且validation并将其保存在它所定义的严格types名称中。 WSDL告诉你数据格式是什么，数据types是什么，允许你添加注册模式风格的规则，并且定义一个数据段必须是多less次，并且可以在请求/响应中被允许。 另一方面，没有这些机制。
SOAP是复杂而沉重的，因为它允许你发送复杂的分层数据。 REST是纯文本，原点和端点将整理出规则。
SOAP是独立于业务的，因为它具有embedded到文档中的所有数据规则。
SOAP和REST的区别在于，SOAP是一个独立的面向业务的模式。 REST是一个文本文件。
