REST是一个体系结构，SOAP是一个协议。

这是第一个问题。

您可以在REST应用程序中发送SOAP信封。

SOAP本身实际上是相当基本和简单的，它之上的WSS-*标准使它非常复杂。

如果您的消费者是其他应用程序和其他服务器，那么目前对SOAP协议有很多支持，在现代ide中移动数据的基本操作基本上就是单击鼠标。

如果您的消费者更有可能是ria或Ajax客户端，那么您可能希望使用比SOAP更简单、更适合客户端的东西(特别是JSON)。

通过HTTP发送的JSON包不一定是REST体系结构，它只是发送到url的消息。所有这些都是完全可行的，但是REST习惯用法有一些关键组件。然而，这两者很容易混淆。但是，仅仅因为您谈论的是HTTP请求，并不一定意味着您拥有REST体系结构。您可以有一个完全没有HTTP的REST应用程序(注意，这种情况很少见)。

因此，如果您的服务器和消费者对SOAP“满意”，SOAP和WSS堆栈就可以很好地为您服务。如果你在做一些特别的事情，想要更好地与web浏览器交互，那么一些轻量级的HTTP协议也可以很好地工作。

一个老问题，但今天仍然有意义....因为许多企业领域的开发人员仍在使用它。

我的工作包括设计和开发IoT(物联网)解决方案。其中包括为与云通信的小型嵌入式设备开发代码。

很明显，REST现在已经被广泛接受和有用，而且几乎是web的事实上的标准，甚至微软在整个Azure中都包含了REST支持。如果我需要依赖SOAP，我就不能做我需要做的事情，因为对于小型嵌入式设备来说，它太大、太笨重、太烦人了。

REST简单、干净、小巧。使其成为小型嵌入式设备的理想选择。当我与一个web开发人员一起工作时，他给我发送wsdl时，我总是尖叫。因为我将不得不开始一场教育活动，告诉他们为什么这行不通，为什么他们必须学习REST。

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

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

请收听本期播客找出答案。如果你想在不听的情况下知道答案，那么好吧，这是REST。但我真的建议你听。

从“PHP-宇宙”的意义上讲，PHP对任何高级SOAP的支持都很糟糕。一旦您满足了基本需求，您最终将使用类似http://wso2.com/products/web-services-framework/php/的东西，甚至启用没有内置支持的WS-Security或WS-RM。

我觉得在PHP中创建SOAP信封是非常混乱的，它创建命名空间的方式，xsd:nil, xsd:anytype和老式的SOAP服务使用SOAP编码(上帝知道这有什么不同)与SOAP消息。

通过坚持REST来避免所有这些混乱，REST并不是什么大不了的东西，我们从WWW开始就在使用它。直到这篇http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm论文发表后，我们才意识到，它展示了如何使用HTTP功能来实现RESTFul服务。HTTP本质上是REST，这并不意味着仅仅使用HTTP就可以使您的服务RESTFul。

SOAP忽略了HTTP的核心功能，只将HTTP视为传输协议，因此理论上它是独立于传输协议的(实际上并非如此，您听说过SOAP Action报头吗?如果不是现在!)。

随着JSON适应的增加以及HTML5和javascript的成熟，REST和JSON已经成为处理服务的最常见方式。JSON Schema也被定义为可以在需要时与WADL一起用于企业级解决方案(仍处于早期阶段)。

PHP对REST和JSON的支持肯定比现有的内置SOAP支持更好。

在这里添加更多的术语SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

顺便说一下，我非常喜欢SOAP，特别是WS-Security规范，这是一个很好的规范，如果有人在考虑企业JSON适应肯定需要一些类似JSON的东西，比如字段级加密等。

快速了解一下2012年的问题:

REST在以下方面发挥了很好的作用:

Limited bandwidth and resources. Remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX. Totally stateless operations. If an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it. Caching situations. If the information can be cached because of the totally stateless operation of the REST approach, this is perfect.That covers a lot of solutions in the above three.

那么我为什么要考虑SOAP呢?同样，SOAP是相当成熟和定义良好的，并且带有完整的规范。REST方法就是这样一种方法，它对开发非常开放，所以如果你具备以下条件，那么SOAP就是一个很好的解决方案:

Asynchronous processing and invocation. If your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging. Formal contracts. If both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction. Stateful operations. If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.

http://www.infoq.com/articles/rest-soap-when-to-use-each