REST是进行Web服务的更好方法还是SOAP？还是针对不同问题的不同工具？还是这是一个细微的问题-也就是说，在某些领域中，一个领域比另一个领域要好一些吗？

我特别希望了解有关这些概念及其与PHP宇宙以及现代高端Web应用程序的关系的信息。

当我在惠普工作时，我根据最初的规范构建了第一批SOAP服务器，包括代码生成和WSDL生成。我不建议对任何东西使用SOAP。

首字母缩写词“ SOAP”是谎言。它不是简单的，不是面向对象的，它没有定义访问规则。可以说，它是一个协议。这是Don Box有史以来最糟糕的规格，这确实是一项壮举，因为他是实施“ COM”的人。

在SOAP中，没有什么可以用REST进行传输，JSON，XML甚至纯文本进行数据表示的方法有用。为了传输安全，可以使用https。对于身份验证，请使用基本身份验证。对于会话，有cookie。REST版本将更简单，更清晰，运行速度更快并且使用的带宽更少。

XML-RPC清楚地定义了请求，响应和错误协议，并且对于大多数语言都有不错的库。但是，XML比许多任务所需的重。

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的较轻协议也可以很好地工作。

REST是与SOAP根本不同的范例。可以在这里找到关于REST的不错的阅读：我如何向妻子解释REST。

如果您没有时间阅读它，那么这里是一个简短的版本：REST通过关注“名词”并限制可用于这些名词的“动词”的数量而在范式上有所转变。唯一允许使用的动词是“ get”，“ put”，“ post”和“ delete”。这不同于SOAP，后者可以将许多不同的动词应用于许多不同的名词（即，许多不同的功能）。

对于REST，这四个动词映射到相应的HTTP请求，而名词由URL标识。这使得状态管理要比SOAP中的透明得多，后者通常不清楚服务器上的状态是什么，客户端上的状态是什么。

在实践中，尽管其中的大多数都消失了，并且REST通常只引用以JSON返回结果的简单HTTP请求，而SOAP是通过传递XML进行通信的更为复杂的API。两者都有其优点和缺点，但是根据我的经验，REST通常是更好的选择，因为您很少需要SOAP的全部功能。

2012年快速下调的问题：

REST非常适合的领域是：

• 有限的带宽和资源。请记住，返回结构实际上是任何格式（开发人员定义）。另外，可以使用任何浏览器，因为REST方法使用标准的GET，PUT，POST和DELETE动词。同样，请记住，REST也可以使用当今大多数现代浏览器支持的XMLHttpRequest对象，这增加了AJAX的额外好处。

• 完全无状态的操作。 如果需要继续进行操作，那么REST并不是最好的方法，SOAP可能会更好。但是，如果您需要无状态CRUD（创建，读取，更新和删除）操作，那么REST就可以了。

• 缓存情况。 如果由于REST方法的完全无状态操作而可以缓存信息，那将是完美的。以上三个方面涵盖了许多解决方案。

那么，为什么还要考虑使用SOAP？同样，SOAP非常成熟且定义明确，并且确实带有完整的规范。REST方法就是这样，并且对开发开放，因此，如果您具有以下条件，那么SOAP是一个很好的解决方案：

• 异步处理和调用。 如果您的应用程序需要保证的可靠性和安全性，那么SOAP 1.2提供了其他标准来确保这种类型的操作。WSRM – WS-Reliable Messaging之类的东西。

• 正式合同。 如果双方（提供者和使用者）必须就交换格式达成共识，那么SOAP 1.2会为这种类型的交互提供严格的规范。

• 有状态的操作。如果应用程序需要上下文信息和会话状态管理，则SOAP 1.2在WS *结构中具有附加的规范以支持这些内容（安全性，事务，协调等）。相对而言，REST方法将使开发人员构建此自定义管道。

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

肥皂当前具有更好的工具的优势，它们将为服务层生成大量的样板代码，并从任何给定的WSDL生成客户端。

REST更简单，因此更易于维护，是Web体系结构的核心，可以实现更好的协议可见性，并且已经证明可以根据WWW本身的大小进行扩展。那里的一些框架可以帮助您构建REST服务，例如Ruby on Rails，甚至可以帮助您编写客户端，例如ADO.NET数据服务。但是在大多数情况下，缺少工具支持。

从工具的角度来看，SOAP很有用，因为WSDL很容易被工具使用。因此，您可以使用自己喜欢的语言为您生成Web Service客户端。

REST在AJAX的网页中表现良好。如果您使请求保持简单，则可以直接从JavaScript进行服务调用，这非常方便。尽量不要在响应XML中包含任何名称空间，我已经看到浏览器对此感到烦恼。因此，xsi：type可能对您不起作用，也没有过于复杂的XML模式。

REST也往往具有更好的性能。生成REST响应的代码对CPU的要求往往低于SOAP框架所显示的。而且，如果您在服务器端排列了XML生成鸭子，则可以有效地将XML流传输到客户端。因此，假设您正在读取数据库游标的行。读取行时，将其格式化为XML元素，然后将其直接写出给服务使用者。这样，您不必在开始编写XML输出之前就收集内存中的所有数据库行，您可以同时进行读取和写入。研究新颖的模板引擎或XSLT，以使流工作于REST。

另一方面，SOAP倾向于由工具生成的服务作为一个大对象来生成，然后才被编写。请注意，这不是一个绝对的事实，有很多方法可以从SOAP中获得流特征，例如使用附件。

我的决策过程如下：如果我希望消费者可以轻松地使用我的服务，并且我写的消息将是中小型的（10MB或更小），并且我不介意消耗一些额外的CPU在服务器上循环，我使用SOAP。如果我需要在Web浏览器上为AJAX服务，或者需要传输的内容，或者我的响应很大，我可以使用REST。

最后，围绕SOAP建立了许多很棒的标准，例如WS-Security和获得状态Web服务，如果使用正确的工具，则可以插入这些标准。这种东西确实有所作为，可以帮助您满足一些繁琐的要求。

我知道这是一个老问题，但是我必须发布答案-也许有人会觉得有用。我不敢相信有多少人推荐基于SOAP的REST。我只能假设这些人不是开发人员，或者从未实际实现任何合理规模的REST服务。实施REST服务要比实施SOAP服务花费很多时间。最后，它也变得更加混乱。这是我99％的时间选择SOAP的原因：

1）实现REST服务比实现SOAP服务花费的时间无限长。存在用于所有现代语言/框架/平台的工具，这些工具可以在WSDL中读取并输出代理类和客户端。REST服务的实现是手工完成的，并且可以通过阅读文档来实现。此外，在实现这两项服务时，您必须“猜测”由于没有真正的架构或参考文档，将在管道中返回什么。

2）为什么要编写仍返回XML的REST服务？唯一的区别是，使用REST时，您不知道每个元素/属性代表的类型-您可以自己实现它，并希望有一天不会在您认为永远是int的字段中遇到字符串。SOAP使用WSDL定义数据结构，因此这是理所当然的。

3）我听说过有人抱怨说，使用SOAP可能会导致SOAP信封的“开销”。在这个时代，我们真的需要担心几个字节吗？

4）我听说过这样的说法，使用REST，您可以将URL弹出浏览器并查看数据。当然，如果您的REST服务使用的是简单身份验证或不使用身份验证。例如，Netflix服务使用OAuth，它要求您对事物进行签名和编码，然后才能提交请求。

5）为什么每个资源都需要一个“可读” URL？如果我们使用工具来实现服务，那么我们真的关心实际的URL吗？

我需要继续吗？

我编写的大多数应用程序都是服务器端C＃或Java，或者是WinForms或WPF中的桌面应用程序。这些应用程序往往需要比REST可以提供的功能更丰富的服务API。另外，我不想花太多时间来创建我的Web服务客户端。WSDL处理客户端生成工具使我能够实现我的客户端并继续增加业务价值。

现在，如果我正在为某些javascript ajax调用显式编写Web服务，则它可能在REST中。只是为了了解客户端技术并利用JSON。在我看来，从javascript使用的Web服务API可能不会很复杂，因为这种复杂性似乎可以在服务器端更好地处理。

如此说来，有一些javascript的SOAP客户端；我知道jQuery有一个。因此，可以从javascript中利用SOAP 。只是不如返回JSON字符串的REST服务好。因此，如果我想拥有足够复杂的Web服务，使其对于任意数量的客户端技术和用途都具有灵活性，那么我将使用SOAP。

我建议您先使用REST-如果您使用Java，请查看JAX-RS和Jersey实现。REST非常简单，并且可以以多种语言互操作。

就像其他人在该线程中所说的那样，SOAP的问题是当其他WS- *规范出现时它的复杂性，如果您误入WSDL，XSD，SOAP，WS-Addressing等错误的部分，则会存在无数互操作问题。

判断REST v SOAP争论的最好方法是在Internet上看-几乎所有网络领域的大公司，如Google，Amazon，ebay，twitter等，都倾向于使用RESTful API而不是SOAP API。

使用REST的另一种不错的方法是，您可以在Web应用程序和REST前端之间重用大量代码和基础结构。例如，使用JAX-RS和隐式视图之类的框架，通常很容易呈现HTML，XML，JSON，而使用Web浏览器轻松处理RESTful资源

我确定Don Box是在开玩笑说创建SOAP的-'看起来可以在网上调用RPC方法”，如今当他意识到Web标准已成为肿的噩梦时吟：-)

REST很好，简单，可在任何地方快速实现（比标准更“标准”）。使用REST。

我认为两者都有自己的位置。在我看来：

SOAP：在WS- *有意义的基础层（安全性，策略等）上，是遗留/关键系统与Web / Web服务系统之间集成的更好选择。

RESTful：更好的选择，可以在网站的顶层TOP（视图，即javascript调用URI）上与公共API进行网站之间的集成。

尚未提及的一件事是，SOAP信封可以包含标头以及主体部分。这使您可以使用XML的完整表达能力来发送和接收带外信息。据我所知，REST将您限制为HTTP标头和结果代码。

（otoh，您可以将cookie与REST服务一起使用来发送“标头”类型的带外数据吗？）

不要忽视XML-RPC。如果您只是一个轻量级的解决方案的追随者，那么可以在几页文本中定义并且可以用最少的代码实现的协议就可以说很多了。XML-RPC已经存在了很多年，但已经过时了一段时间-但是极简主义的吸引力似乎正在使它复兴。

回答2012年更新的问题（第二个赏金），并查看今天的结果（其他答案）。

SOAP的优缺点

关于SOAP 1.2，与“ REST”进行比较时的优缺点...从2007年开始， 您可以使用WSDL和SOAP协议来描述REST Web服务 ...也就是说，如果您更加努力，则所有W3C标准Web服务协议栈可以是REST！

这是一个很好的起点，因为我们可以想象一个暂时避免所有哲学和方法论讨论的场景。我们可以从技术上比较类似服务中的“ SOAP-REST”和“ NON-SOAP-REST”，

• SOAP-REST（=“ REST-SOAP”）：如L.Mandel所示，WSDL2可以描述REST Web服务，并且，如果我们假设可以将示例XML封装在SOAP中，则所有实现都将是“ SOAP-REST” 。

• NON-SOAP-REST：不能是SOAP的任何REST Web服务...也就是说，众所周知的REST示例中的“ 90％”。一些不使用XML（例如，典型的AJAX REST使用JSON代替），一些不使用SOAP标头或规则而使用其他XML结构。PS：为避免非正式性，我们可以在比较中假设REST级别2。

当然，要在概念上进行比较，请将“ NON-REST-SOAP”与“ NON-SOAP-REST”进行比较，以作为不同的建模方法。因此，完成以下Web服务分类：

• NON-REST-SOAP：不能是REST的任何SOAP Web服务...也就是说，众所周知的SOAP示例中的“ 90％”。

• NON-REST-NEITHER-SOAP：是的，“ Web服务建模”的范围包括其他内容（例如XML-RPC）。

REST中的SOAP规范

比较可比的东西：SOAP-REST与NON-SOAP-REST。

优点

解释一些术语，

• 合同稳定性：适用于各种合同（如“书面协议”），

  • 通过使用标准设备：W3C堆栈的所有级别 都是相互兼容的。另一方面，REST不是W3C或ISO标准，并且没有有关服务外围设备的规范化细节。所以，就像我 @DaveWoldrich（20票），@ cynicalman（5），@ Exitos（0）之前所说，在需要标准的环境中，您需要SOAP。

  • 通过使用最佳实践：W3C堆栈实现的“详细方面” ，翻译相关的人类/法律/司法协议。

• 健壮性：SOAP结构和标头的安全性。使用metada通信（具有XML的完整表达能力）和验证，您将拥有针对任何更改或干扰的“保险政策”。
  SOAP具有“交易可靠性（...）处理通信故障。SOAP具有更多围绕重试逻辑的控制，因此可以提供更多的端到端可靠性和服务保证”，E。Terman。

按受欢迎程度对专业人士进行排序，

• 更好的工具（〜70票）：从2007年到2012年，SOAP当前具有更好的工具的优势，因为它是一个定义明确且被广泛接受的标准。参见@MarkCidade（27票），@ DaveWoldrich（20），@ JoshM（13），@ TravisHeseman（9）。

• 符合标准（25票）：正如我所说的@DaveWoldrich（20票），@ cynicalman（5），@ Exitos（0）之前所说，在需要标准的环境中，您需要SOAP。

• 健壮性：SOAP标头保险，@ JohnSaunders（8票）。

缺点

• SOAP结构更为复杂（超过300票）：此处的所有答案以及有关“ SOAP vs REST”的资料，都显示出对SOAP的冗余性和复杂性的某种程度的不满。这是对形式验证（见下文）和健壮性（见上文）的要求的自然结果。“ REST NON-SOAP”（以及SOAP的发起者 XML-RPC ）可以更加简单和非正式。

• 使用微型服务（约50票）时，“仅XML”限制是性能障碍：请参阅json.org/xml和此问题，或另一个。@toluju（41）等显示了这一点。
  PS：因为JSON不是IETF标准，但我们可以考虑将其作为Web软件社区的事实上的标准。

使用SOAP建模服务

现在，我们可以将SOAP-NON-REST与NON-SOAP-REST比较添加在一起，并说明何时使用SOAP更好：

• 需要标准和稳定的合同（请参阅“ PROS”部分）。PS：请参见@saille所描述的典型“ B2B标准需求”。

• 需要工具（请参阅“ PROS”部分）。PS：标准和形式验证的存在（请参见下文）是工具自动化的重要问题。

• 并行繁重的处理（请参见下面的“上下文/基础”部分）：对于更大和/或更慢的进程，无论SOAP的复杂性如何，可靠性和稳定性都是最佳的投资。

• 需要更高的安全性：当需要的不仅仅是HTTPS且您确实需要其他保护功能时，SOAP是一个更好的选择（请参阅@Bell，32票）。“沿着比请求/响应更复杂的路径或通过不涉及HTTP的传输来发送消息”，S。Seely。XML是一个核心问题，提供了XML加密，XML签名和XML Canonicalization的标准，只有使用SOAP，您才能通过公认的WS-Security标准将这些机制嵌入消息中。

• 需要更大的灵活性（更少的限制）：SOAP不需要与URI完全一致；不限于HTTP；不需要限制为4个动词。正如@TravisHeseman（9票）所说，如果您想要“对于任意数量的客户端技术和用途都可以灵活使用”的内容，请使用SOAP。
  PS：请记住，XML比JSON更通用/更具表现力（等）。

• 需要形式验证：了解W3C堆栈使用形式方法，而REST更非正式，这一点很重要。WSDL（一种正式语言）服务描述是 Web服务接口的正式规范，而SOAP是一种健壮的协议，可以接受所有可能的WSDL规定。

语境

历史的

评估趋势是必要的历史观点。对于这个主题，有10到15年的前景...

在W3C标准化之前，存在一些无政府状态。很难在不同的框架下实现可互操作的服务，而在公司之间实现可互操作的事物则更加困难，昂贵且耗时。在W3C栈标准已经一盏灯，为套复杂的Web服务互操作北部。

对于日常任务，例如实施AJAX，SOAP非常繁琐...因此，对简单方法的需求需要选择一种新的理论框架...以及像Google，Amazon这样的大型“网络软件厂商” Yahoo等人选择了最好的替代方法，即REST方法。在这种情况下，REST概念是作为“竞争框架”出现的，而今天（2012年），这种替代方法已成为事实上的标准。程序员的。

基础

在并行计算的上下文中，Web服务提供并行的子任务。SOAP之类的协议可确保良好的同步和通信。不是“任何任务”：Web服务可以归类为
粗粒度和令人尴尬的并行性。

随着任务的扩大，它变得不那么重要的“复杂性辩论”，而变得与沟通的健壮性和合同的牢固性息息相关。

很细微。

如果您需要让其他系统与您的服务接口，那么很多客户将对SOAP感到满意，这是由于合同，WSDL和SOAP标准具有“验证”层。

对于日常的系统调用，我认为当进行简单的HTML调用时，SOAP会产生很多不必要的开销。

我看起来是一样的，我认为 它们是解决不同问题的不同工具。

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

代表性状态转移（RESTful）Web服务。它们是第二代Web服务。RESTful Web服务比基于SOAP的服务通过HTTP进行通信，并且不需要XML消息或WSDL服务API定义。对于REST，不需要中间件，只需要HTTP支持.WADL标准，REST可以返回XML，纯文本，JSON，HTML等

对于许多类型的客户端而言，使用RESTful Web服务更加容易，同时使服务器端能够进行扩展和扩展。客户可以选择使用服务的某些或所有方面，并将其与其他基于Web的服务混搭。

1. REST使用标准HTTP，因此创建客户端，开发API更加简单
2. REST允许许多不同的数据格式，例如XML，纯文本，JSON，HTML，而SOAP仅允许XML。
3. REST具有更好的性能和可伸缩性。
4. 休息，可以缓存，SOAP无法
5. SOAP没有错误处理的内置错误处理
6. REST对PDA和其他移动设备特别有用。

REST是易于与现有网站集成的服务。

SOAP具有一组协议，这些协议除其他外提供了安全性和可靠性的标准，并且可以与其他符合WS的客户端和服务器进行互操作。SOAP Web服务（例如JAX-WS）在处理异步处理和调用中很有用。

对于复杂API，SOAP将更加有用。

REST是Roy Fielding发明的体系结构，并在其论文《体系结构样式和基于网络的软件体系结构设计》中进行了描述。Roy还是HTTP的主要作者是定义通过万维网进行文档传输的协议。HTTP是RESTful协议。当开发人员谈论“使用REST Web服务”时，说“使用HTTP”可能更准确。

SOAP是基于XML的协议，可在HTTP请求/响应内部进行隧道传输，因此，即使您使用SOAP，也将使用REST。关于SOAP是否在基本HTTP中添加任何重要功能存在一些争论。

在创作Web服务之前，建议您学习HTTP。奇怪的是，您的要求可以使用规范中已定义的功能来实现，因此不需要其他协议。

我在看同样的问题。在我看来，实际上REST快速简便，对于轻量级的调用和响应非常有用，并且对于调试非常有用（这比将URL注入浏览器并查看响应更好）。

但是，REST似乎失败的原因在于它不是一个标准（尽管它由标准组成）。大多数编程库都有一种检查WSDL的方法，以自动生成消耗基于SOAP的服务所需的客户端代码。因此，基于REST的Web服务耗时很长，似乎是编写接口以匹配可能的调用的一种更为特殊的方法。发出手动http请求，然后解析响应。这本身可能很危险。

SOAP的优点在于，一旦发布了WSDL，企业就可以构建其逻辑框架，该逻辑框架设置了合同，对接口的任何更改都会更改wsdl。没有空余的空间。您可以针对该WSDL验证所有请求。但是，由于WSDL不能正确描述REST服务，因此您没有定义用于在通信接口上达成一致的方法。

从业务角度看，这似乎确实使交流容易进行解释和更改，这似乎是一个坏主意。

该线程中最上面的“答案”似乎表明SOAP代表简单的面向对象的访问协议，但是从Wiki看，O表示对象不是面向对象的。他们是不同的东西。

我知道这篇文章很老，但是我应该以自己的发现回应。

这是一个很好的问题...我不想让您误入歧途，所以我和您一样愿意接受其他人的回答。对我来说，这实际上要归结为开销成本以及API的用途。在创建客户端软件时，我更喜欢使用Web服务，但是我不喜欢SOAP的重量。我相信REST的重量较轻，但是从客户的角度来看，我几乎不喜欢使用REST。

我对别人的想法很好奇。

收听此播客以查找答案。如果您想不听就知道答案，那么可以使用它的REST。但我确实建议您收听。

我的一般规则是，如果希望浏览器Web客户端直接连接到服务，则应该使用REST。如果要在后端服务之间传递结构化数据，请使用SOAP。

有时设置SOAP可能会造成很大的痛苦，并且对于简单的Web客户端和服务器数据交换而言通常过于矫kill过正。不幸的是，我所看到（并从中学习）的大多数简单编程示例都在某种程度上增强了这种认识。

就是说，当您开始将多个SOAP服务组合在一起时，作为一个由数据工作流驱动的较大过程的一部分（想像企业软件），SOAP确实会发光。这是许多SOAP编程示例无法传达的，因为执行简单的SOAP操作（例如获取股票价格）通常会因其本身的功能而过于复杂，除非在提供机器的上下文中进行了介绍。可读的API，其中详细说明了特定功能，并为输入和输出设置了数据格式，进而由较大的过程编写了脚本。

从某种程度上来说，这很可悲，因为它确实给SOAP不好的声誉，因为如果不完整地介绍最终产品的使用方式，就很难展示SOAP的优势。

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

从“ PHP-universe”的意义上讲，对任何高级SOAP的PHP支持都花费了大量时间。您最终将使用诸如http://wso2.com/products/web-services-framework/php/满足基本需求后，，甚至使WS-Security或WS-RM没有内置支持。

我感觉SOAP信封的创建在PHP中非常混乱，它创建命名空间的方式，xsd：nil，xsd：anytype和旧样式的soap服务在SOAP消息中使用SOAP编码（上帝知道有什么不同）。

坚持使用REST可以避免所有麻烦，自从WWW以来，我们就一直在使用REST。我们只有在http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm论文发表它显示了我们如何使用HTTP功能来实现RESTFul Services。HTTP本质上就是REST，这并不意味着仅使用HTTP就可以使您的服务成为RESTFul。

SOAP忽略了HTTP的核心功能，并且将HTTP视为一种传输协议，因此从理论上讲它是独立于传输协议的（实际上，您不是听说过SOAP Action标头的吗？

随着JSON适应性的增加以及HTML5和Javascript逐渐成熟，REST和JSON已成为处理服务的最常见方法。还定义了JSON模式，并在需要时可与WADL一起用于企业级解决方案（仍处于早期阶段）。

PHP对REST和JSON的支持绝对比其现有的内置SOAP支持要好。

在此处添加一些BUZZ词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规范，这是一个很好的规范，如果想对Enterprise JSON进行适应性思考的人确实需要提供一些类似JSON的功能，例如字段级加密等。

快速点-传输协议和编排；

出于速度，可靠性和安全性的原因，我使用SOAP over TCP，包括协调的机器到机器服务（ESB）和外部服务。更改服务定义，业务流程会因WSDL更改而引发错误，并且该错误立即显而易见，并且可以重新构建/部署。

不确定您是否可以使用REST进行相同操作-我正在等待纠正或课程！使用REST，更改服务定义-在返回400（或其他任何值）之前，对此一无所知。

如果您正在寻找不同系统和语言之间的互操作性，那么我一定会选择REST。例如，在使SOAP在.NET和Java之间工作时，我遇到了很多问题。

我创建了一个基准来查找其中哪个更快！我看到这个结果：

对于1000个请求：

• REST花费了3秒
• SOAP用了7秒

10,000个请求：

• REST花费了33秒
• SOAP花了69秒

1,000,000个请求：

• REST用了62秒
• SOAP花了114秒

一个古老的问题，但今天仍然有意义。...由于企业领域中如此众多的开发人员仍在使用它。

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

显然，REST现在已被广泛接受和使用，并且几乎是Web的事实上的标准，即使Microsoft在整个Azure中都包括REST支持。如果我需要依靠SOAP，那么我就无法做我需要做的事情，对于小型嵌入式设备而言，它太大，笨重且令人讨厌。

REST简单，干净，小巧。使其非常适合小型嵌入式设备。当我与向我发送WSDL的Web开发人员一起工作时，我总是大喊大叫。正如我将要开始的教育运动那样，这为什么行不通以及为什么他们必须学习REST。

1.根据我的经验。我想说REST让您可以选择访问已构建的URL。例如->在Google中搜索单词。该URL可用作REST的Web服务。在SOAP中，您可以创建自己的Web服务并通过SOAP客户端访问它。

2. REST支持文本，JSON，XML格式。因此，在两个应用程序之间进行通信具有更多的通用性。SOAP只支持XML格式的消息通信。