我也在关注同样的问题。在我看来，REST实际上是快速和简单的，适用于轻量级调用和响应，并且非常适合调试(还有什么比将URL注入浏览器并查看响应更好的呢)。

然而，REST的不足之处在于它不是一个标准(尽管它由标准组成)。大多数编程库都有一种检查WSDL以自动生成消费基于SOAP的服务所需的客户端代码的方法。到目前为止，使用基于REST的web服务似乎是一种更特别的方法，即编写接口来匹配可能的调用。手动发起http请求，然后解析响应。这本身就是危险的。

SOAP的美妙之处在于，一旦WSDL被发布，那么业务就可以构造它们的逻辑主干，从而设置契约，对接口的任何更改都会改变WSDL。没有任何回旋的余地。您可以根据该WSDL验证所有请求。然而，由于WSDL没有正确地描述REST服务，因此您没有定义的方式来就通信的接口达成一致。

从商业的角度来看，这似乎让沟通变得容易解释和改变，这似乎是个坏主意。

这个线程中最上面的“答案”似乎说SOAP代表简单面向对象访问协议，然而在wiki中，O意味着对象不是面向对象的。它们是不同的东西。

我知道这篇文章很老了，但我认为我应该用我自己的发现来回应。

SOAP体现了Web服务的面向服务的方法——在这种方法中，方法(或动词)是与服务交互的主要方式。REST采用面向资源的方法，其中对象(或名词)占据中心位置。

这是微妙的。

如果您需要让其他系统与您的服务进行接口，那么由于您使用契约、WSDL和SOAP标准所拥有的“验证”层，许多客户端将更乐于使用SOAP。

对于日常系统对系统的调用，我认为SOAP是很多不必要的开销，而简单的HTML调用就可以了。

我写的大多数应用程序都是服务器端c#或Java，或者WinForms或WPF中的桌面应用程序。这些应用程序往往需要比REST所能提供的更丰富的服务API。另外，我不想在创建web服务客户机上花费超过几分钟的时间。WSDL处理客户端生成工具允许我实现我的客户端并继续添加业务价值。

现在，如果我为一些javascript ajax调用显式地编写web服务，它可能是在REST中;只是为了了解客户端技术和利用JSON。在我看来，从javascript中使用的web服务api可能不应该非常复杂，因为这种类型的复杂性似乎可以更好地处理服务器端。

也就是说，javascript有一些SOAP客户端;我知道jQuery有一个。因此，SOAP可以从javascript中利用;只是不像REST服务返回JSON字符串那样好。因此，如果我有一个web服务，我希望它足够复杂，能够灵活地适应任意数量的客户端技术和用途，那么我会选择SOAP。

这是个好问题……我不想让你误入歧途，所以我和你一样愿意接受别人的答案。对我来说，这实际上归结于开销成本和API的使用。在创建客户端软件时，我更喜欢使用web服务，但是我不喜欢SOAP的重量。我相信REST的重量更轻，但我不太喜欢从客户的角度使用它。

我很好奇别人是怎么想的。

我也看到了，我想， 它们是针对不同问题的不同工具。

简单对象访问协议(SOAP)标准，一种定义消息体系结构和消息格式的XML语言，被Web服务使用，它包含对操作的描述。WSDL是一种基于xml的语言，用于描述Web服务以及如何访问它们。将运行在SMTP,HTTP,FTP等。需要中间件支持，定义良好的机制来定义服务，如WSDL+XSD, WS-Policy SOAP将返回基于XML的数据，SOAP为安全性和可靠性提供标准

具象状态传输(RESTful) web服务。它们是第二代Web服务。基于rest的web服务通过HTTP而不是基于soap的服务进行通信，并且不需要XML消息或WSDL服务api定义。对于REST，不需要中间件，只需要HTTP支持。WADL标准，REST可以返回XML，纯文本，JSON, HTML等

对于许多类型的客户端来说，使用基于rest的web服务更容易，同时使服务器端能够演进和扩展。客户端可以选择使用服务的部分或全部方面，并将其与其他基于web的服务混合。

REST使用标准HTTP，因此创建客户端和开发api更简单 REST允许许多不同的数据格式，如XML、纯文本、JSON、HTML，而SOAP只允许XML。 REST具有更好的性能和可伸缩性。 休息并且可以缓存，而SOAP不能 内置错误处理，SOAP没有错误处理 REST在PDA和其他移动设备上特别有用。

REST是一种容易与现有网站集成的服务。

SOAP有一组协议，其中提供了安全性和可靠性标准，并与其他符合WS的客户机和服务器进行互操作。 SOAP Web服务(如JAX-WS)在处理异步处理和调用方面很有用。

对于复杂的API, SOAP会更有用。