我的意思是，真的，SOAP有什么意义？
Web服务已经出现了一段时间，有一段时间似乎“SOAP”和“Web服务”这两个术语在很大程度上是可以互换的。然而，SOAP总是显得笨拙而且对我来说过于复杂。
然后REST出现了，突然间Web服务变得有意义了。
正如Joel Spolsky所说，给程序员一个REST URL，他们可以立即开始使用该服务，并将其搞清楚。
SOAP在WSDL和大量冗长的XML背后进行了混淆，尽管是基于Web的，但您不能做任何像使用Web浏览器访问SOAP服务那样简单的事情。
所以问题的实质是：
答案 0 :(得分：12)
正如Joel Spolsky所说，给程序员一个REST URL，他们可以立即开始使用该服务，并将其搞清楚。
如果该服务具有明确的机器可读合同，那么程序员就不必浪费任何时间来计算它。
（并不是说WSDL / SOAP必然是良好实现良好指定合同的一个例子，但这是WSDL的重点）
最初，SOAP是一个简单的协议，它允许您向消息添加标头，并具有对象实例到XML结构的标准化映射。将处理元数据放在消息中简化了客户端代码，这意味着您可以非常简单地持久化并对消息进行排队。
我在2001年构建SOAP服务时从未需要头处理细节。这是在WSDL之前，然后使用GET获取信息和查询是正常的（与大多数声称是REST的应用程序没什么不同; REST在使用服务发现的超链接方面拥有更多优势，而POST则使用SOAP有效负载来执行操作。创建资源的那些操作会将创建的资源的URL返回给客户端，然后客户端可以获取资源。我认为事实上，WSDL只能在RPC方面进行思考，而不是创建使SOAP失去情节的资源的行为。
答案 1 :(得分：6)
在Why is soap considered to be thick中讨论了这个话题。
答案 2 :(得分：6)
我看到它的方式，SOAP可能更“灵活”，但结果却太复杂了（你提到了WSDL，这对我个人来说总是一个绊脚石）。
我获得 REST。这是简单。我可能会看到的唯一缺点是，您正在限制自己针对单个资源的4个基本操作，这可能不完全符合您查看数据的方式。
答案 3 :(得分：6)
在做一些研究以了解这里的一些答案（尤其是John Saunders'）时，我发现了这篇文章http://harmful.cat-v.org/software/xml/soap/simple SOAP比我想象的更疯狂......
答案 4 :(得分：4)
WSDL的重点是自动发现。这个想法是你不必编写客户端代码，它会自动生成。
顺便说一句。 WSDL之后的下一步是Semantic Web Services。
答案 5 :(得分：3)
如果您不需要WS- *系列协议的功能;如果你不需要自我描述的服务;如果您的服务无法完全描述为HTTP协议定义的资源;如果你不喜欢为每次与服务的交互编写XML，并在之后解析它;那么你需要SOAP。
否则，请务必使用REST。
关于自描述服务的价值存在一些问题。在想象任何人无法理解这一点时，我的想象力让我失望。那是在我身上。尽管如此，我还是认为曾经使用过比“Hello，world”复杂得多的服务的人都知道为什么让其他人编写接受参数的代码，创建XML以发送给服务，发送它，接收响应，然后将其转回对象。
现在，我想在使用RESTful服务时可能不需要这样做;至少不使用不处理复杂对象的RESTful服务。即使使用像http://www.earthtools.org/webservices.htm这样的相对简单的服务（我将其用作调用RESTful服务的示例），也可以从理解返回数据的结构中获益。即使上面的服务提供了XML Schema - 遗憾的是它没有描述整个响应。鉴于模式仍需要手动处理XML，或者使用工具从模式生成可序列化的类。
当在WSDL中描述服务时，所有这些都发生在您身上，并且您在Visual Studio中使用“添加服务引用”之类的工具，或者使用svcutil.exe程序，或者我忘记了什么命令-is合的Eclipse。
如果您需要示例，请从EarthTools服务开始，然后使用更复杂的消息传递继续使用其他任何服务。
BTW，需要自我描述的另一件事是描述服务支持的消息传递模式和协议。当唯一的选择是通过HTTP或HTTPS的HTTP谓词时，可能不需要这样做。如果您使用WS-Security和朋友，生活会变得更加复杂。答案 6 :(得分：2)
我发现，当企业现货（COTS）软件很有可能使用服务时，SOAP最适合。由于SOAP / WSDL采用了明确的合同，因此大多数COTS包都内置了消费此类服务的功能。这可以使BPM /工作流工具等简单地使用定义的服务而无需定制。除了该服务用例，REST往往是我的应用程序的goto Web服务实现。
答案 7 :(得分：2)
现在似乎WSI同意SOAP不再有意义，因为他们宣布他们将不再作为独立实体存在。
有关该公告的有趣文章及其中的一些评论：http://blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-web-services/index.htm
编辑完全准确回应John Saunders。
答案 8 :(得分：1)
我认为SOAP吸引了Java和.net人群，他们可能更熟悉旧的CORBA和COM，而不太熟悉互联网技术。
REST还有一个主要缺点：关于如何实际实现这样一个系统的指导很少。您会发现有多少公共RESTful API被设计出来的重大变化。事实上，许多违反了REST的关键方面（例如使用GET进行操作或POST进行检索），并且在基本用法方面存在分歧（POST / GET与POST / GET / PUT / DELETE）。
答案 9 :(得分：0)
我错了吗？
“你没错，沃尔特，你只是...... :)”
有没有什么好的理由选择SOAP over REST？
SOAP，根据我的理解遵守合同，因此可以进行类型检查。
答案 10 :(得分：0)
SOAP是一种基于XML的轻量级结构化协议规范，用于实现服务。它用于交换 分散的分布式环境中的结构化信息。 SOAP使用XML技术通过任何传输层协议交换信息。 它独立于任何特定的编程模型和其他特定于实现的语义。了解有关XML的更多信息 SOAP消息传递框架
基于XML的消息传递框架 1）可扩展：简单性仍然是SOAP的主要设计目标之一。 SOAP定义了一个允许安全性，路由和等功能的通信框架 以后作为分层扩展添加的可靠性
2）可互操作：SOAP可以在任何传输协议上使用，例如TCP，HTTP，SMTP。 SOAP今天为HTTP提供了一个显式绑定。
3）独立：SOAP允许任何编程模型，并且不依赖于远程过程调用（RPC）。 SOAP定义了一个用于处理单个单向消息的模型。 SOAP还允许任意数量的消息交换模式（MEP）。了解有关SOAP
的更多信息