SOAP – 有什么意义？
我的意思是，真的，SOAP有什么意义？
Web服务已经存在了一段时间，一段时间以来，“SOAP”和“Web服务”这两个术语在很大程度上是可以互换的。 然而，SOAP总是显得笨重，并且大大地过于复杂。
然后REST就出现了，Web服务突然变得有意义了。
正如Joel Spolsky所说的，给程序员一个REST的URL，他们就可以马上开始使用这个服务，搞清楚了。
SOAP在WSDL和大量详细的XML背后被模糊处理，尽pipe是基于Web的，但是不能做任何事情就像使用Web浏览器访问SOAP服务一样简单。
所以我的问题的本质是：
- 有没有什么好的理由selectSOAP而不是REST？
- 你现在在用SOAP吗？ 如果界面是REST，会更好吗？
- 我错了吗？
正如Joel Spolsky所说的，给程序员一个REST的URL，他们就可以马上开始使用这个服务，搞清楚了。
而如果服务有一个明确的，机器可读的合同，那么程序员就不用浪费时间去搞清楚了。
（不是说WSDL / SOAP必然是良好实现明确合同的例子，但这就是WSDL的重点）
最初，SOAP是一个简单的协议，它允许您为消息添加一个头，并将对象实例标准化映射到XML结构。 将消息中的处理元数据简化为客户端代码，意味着您可以非常简单地持久保留消息队列。
当我在2001年构buildSOAP服务时，我从来不需要头处理细节。这是WSDL之前的版本，使用GET获取信息和查询是正常的（对大多数声称是REST的应用程序没有任何不同; REST更多在使用超链接进行服务发现方面）以及使用SOAP有效负载执行POST操作。 那些创build资源的操作会将创build的资源的URL返回给客户端，然后客户端可以获取资源。 我认为这是事实，WSDL很容易就只考虑RPC而不是创build使SOAP丢失情节的资源的行为。
我看到的方式是，SOAP可能更“灵活”，但结果太复杂了（您提到了WSDL，这对我来说总是一个绊脚石）。
我得到 REST。 很简单 我可能会看到的唯一缺点是，您将自己限制在针对单个资源的这4个基本操作上，这可能不完全符合您查看数据的方式。
“ 为什么肥皂被认为是厚实的”这个话题已经有了很好的讨论。
虽然做了一些研究，以了解这里的一些答案（特别是约翰·桑德斯），我发现这个posthttp://harmful.cat-v.org/software/xml/soap/simple SOAP比我想象的更疯狂…
WSDL的重点是自动发现。 这个想法是，你不必编写客户端代码，它会自动生成。
BTW。 语义Web服务是WSDL之外的下一步。
如果您不需要WS- *系列协议的function， 如果你不需要自我描述服务; 如果你的服务不能被完全描述为资源，按HTTP协议定义; 如果你不喜欢为与服务的每一次交互都编写XML，然后parsing它; 那么你需要SOAP。
否则，当然，使用REST。
关于自我描述服务的价值有一些问题。 当想象如何有人不明白这一点时，我的想象力使我失望。 这是对我的。 不过，我必须认为，任何曾经使用比“Hello，world”复杂得多的服务的人都会知道为什么有人写代码接受参数，创buildXML发送给服务，发送它接收到响应，然后将其转换回对象。
现在，我想这在使用RESTful服务时可能没有必要; 至less不会使用不处理复杂对象的RESTful服务。 即使像http://www.earthtools.org/webservices.htm （我曾用它作为调用RESTful服务的示例）这样的相对简单的服务，也可以从理解返回数据的结构中受益。 即使上面的服务提供了一个XML模式 – 不幸的是并没有描述整个响应。 鉴于模式仍然需要手动处理XML，或者使用工具从模式生成可序列化的类。
当在WSDL中描述服务时，所有这一切都发生在您身上，并且您使用Visual Studio中的“Add Service Reference”或svcutil.exe程序或I-forget-what-the-command-is-在月食。
如果您需要示例， 请先从EarthTools服务开始，然后继续使用更复杂的消息传递的其他服务。
顺便说一句，需要自我描述的另一件事是描述服务支持的消息模式和协议。 当唯一的select是通过HTTP或HTTPS的HTTP动词时，也许这不是必需的。 如果你使用WS-Security和朋友，生活会变得更加复杂。
我发现，当企业现成（COTS）软件很可能会使用服务时，SOAP最适合。 由于SOAP / WSDL使用了明确的合同，所以大多数COTS包都内置了消费这些服务的function。 这可以使BPM /工作stream工具等简单地使用定义的服务而不需要定制。 除了那个服务用例REST往往是我的应用程序的goto web服务实现。
那么现在看来， WSI同意SOAP不再有意义了 ，因为它们宣布它们将不再作为一个独立的实体存在。
有趣的文章关于公告和一些评论在这里： http : //blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-web-services/index.htm
对约翰·桑德斯（John Saunders）的回应是完全准确的。
我认为SOAP吸引了那些对旧的CORBA和COM更加熟悉的Java和.net人群，而对互联网技术则不太熟悉。
REST还有一个主要缺点：关于如何实际实现这样的系统几乎没有指导。 您将会发现已经devise了多less公共RESTful API的重大变化。 事实上，许多违反REST的关键方面（例如使用GET进行操作或POST进行检索），并且在基本用法（POST / GET与POST / GET / PUT / DELETE）方面存在分歧。
我错了吗？
“你没有错，沃尔特，你只是… :)”
有没有什么好的理由selectSOAP而不是REST？
SOAP，根据我的理解遵守合同，因此可以进行types检查。
SOAP是一个轻量级的基于XML的结构化协议规范，用于实现服务。 它用于在分散的分布式环境中交换结构化信息。 SOAP使用XML技术通过任何传输层协议交换信息。 它独立于任何特定的编程模型和其他实现特定的语义。 了解有关XML SOAP消息传递框架的更多信息
基于XML的消息传递框架1）可扩展性：简单性仍然是SOAP的主要devise目标之一。 SOAP定义了一个通信框架，允许将诸如安全性，路由和可靠性等function稍后添加为分层扩展
2）互操作性：SOAP可以用于任何传输协议，如TCP，HTTP，SMTP。 SOAP为HTTP提供了一个明确的绑定。
3）独立性：SOAP允许任何编程模型，并且不与远程过程调用（RPC）绑定。 SOAP定义了处理单个单向消息的模型。 SOAP还允许任何数量的消息交换模式（MEP）。了解关于SOAP的更多信息
