SOAP 与 REST（差异）
我已经阅读了有关 SOAP 和 REST 作为 Web 服务通信协议的区别的文章，但我认为 REST 优于 SOAP 的最大优势是：
REST 更加动态，无需创建和更新 UDDI（通用描述、发现和集成）。 REST 不仅限于 XML 格式。 RESTful Web 服务可以发送纯文本/JSON/XML。
但是 SOAP 更加标准化（例如：安全性）。
那么，我在这些方面是否正确？
不幸的是，围绕 REST 存在很多错误信息和误解。不仅您的问题和 answer by @cmd 反映了这些问题，而且还反映了 Stack Overflow 上与该主题相关的大多数问题和答案。
SOAP 和 REST 不能直接比较，因为前者是一种协议（或至少试图如此），而后者是一种架构风格。这可能是造成混淆的原因之一，因为人们倾向于将 REST 称为任何不是 SOAP 的 HTTP API。
稍微推动一下并试图建立一个比较，SOAP 和 REST 之间的主要区别在于客户端和服务器实现之间的耦合程度。 SOAP 客户端的工作方式类似于自定义桌面应用程序，与服务器紧密耦合。客户端和服务器之间有一个严格的合同，如果任何一方改变任何东西，一切都会被打破。您需要在任何更改后不断更新，但更容易确定是否遵守了合同。
REST 客户端更像是浏览器。它是一个知道如何使用协议和标准化方法的通用客户端，应用程序必须适应其中。您不会通过创建额外的方法来违反协议标准，您可以利用标准方法并在您的媒体类型上使用它们创建操作。如果做得好，耦合就会减少，并且可以更优雅地处理更改。除了入口点和媒体类型外，客户端应该在对 API 零知识的情况下进入 REST 服务。在 SOAP 中，客户端需要事先了解它将使用的所有内容，否则它甚至不会开始交互。此外，可以通过服务器本身提供的按需代码来扩展 REST 客户端，经典示例是用于驱动与客户端另一服务交互的 JavaScript 代码。
我认为这些是理解 REST 是什么以及它与 SOAP 有何不同的关键点：
REST 独立于协议。它不与 HTTP 耦合。就像您可以跟踪网站上的 ftp 链接一样，REST 应用程序可以使用任何具有标准化 URI 方案的协议。
REST 不是 CRUD 到 HTTP 方法的映射。阅读此答案以获取详细说明。
REST 与您使用的部件一样标准化。 HTTP 中的安全性和身份验证是标准化的，因此这就是您在通过 HTTP 执行 REST 时使用的内容。
没有超媒体和 HATEOAS 的 REST 不是 REST。这意味着客户端只知道入口点 URI，并且资源应该返回客户端应该遵循的链接。那些为您可以在 REST API 中执行的所有操作提供 URI 模式的精美文档生成器完全没有抓住重点。他们不仅记录了应该遵循标准的东西，而且当你这样做时，你将客户端耦合到 API 演变中的一个特定时刻，并且必须记录和应用对 API 的任何更改，否则它会破裂。
REST 是 Web 本身的架构风格。当您进入 Stack Overflow 时，您就会知道用户、问题和答案是什么，您知道媒体类型，并且网站会为您提供指向它们的链接。 REST API 也必须这样做。如果我们按照人们认为 REST 应该完成的方式设计 Web，而不是有一个带有问题和答案链接的主页，我们会有一个静态文档说明为了查看问题，您必须使用 URI stackoverflow .com/questions/
最后一点怎么强调都不过分。如果您的客户正在从文档中的模板构建 URI，而不是在资源表示中获取链接，那不是 REST。 REST 的作者 Roy Fielding 在这篇博文中明确表示：REST APIs must be hypertext-driven。
考虑到上述内容，您将意识到虽然 REST 可能不限于 XML，但要正确使用任何其他格式，您必须为链接设计和标准化某种格式。超链接在 XML 中是标准的，但在 JSON 中不是。 JSON 有一些标准草案，例如 HAL。
最后，REST 并不适合所有人，这就是大多数人如何使用他们错误地称为 REST 并且从未冒险超越的 HTTP API 很好地解决他们的问题的一个证明。 REST 有时很难做到，尤其是在刚开始的时候，但随着时间的推移，它会随着服务器端更容易的演变以及客户端对变化的弹性而付出代价。如果您需要快速轻松地完成某些事情，请不要为正确使用 REST 而烦恼。这可能不是你要找的。如果您需要一些必须保持在线数年甚至数十年的东西，那么 REST 适合您。
REST 与 SOAP 是不是要问的正确问题。
REST 与 SOAP 不同的是不是协议。
REST 是一种架构风格，也是一种设计，适用于基于网络的软件架构。
REST 概念称为资源。资源的表示必须是无状态的。它通过某种媒体类型表示。媒体类型的一些示例包括 XML、JSON 和 RDF。资源由组件操作。组件通过标准的统一接口请求和操作资源。对于 HTTP，此接口由标准 HTTP 操作组成，例如 GET、PUT、POST、DELETE。
@Abdulaziz 的问题确实说明了 REST 和 HTTP 经常串联使用的事实。这主要是由于 HTTP 的简单性及其与 RESTful 原则的非常自然的映射。
基本 REST 原则
客户端-服务器通信
客户端-服务器架构具有非常明显的关注点分离。所有以 RESTful 风格构建的应用程序原则上也必须是客户端-服务器。
无状态
每个客户端对服务器的请求都要求其状态被完全表示。服务器必须能够在不使用任何服务器上下文或服务器会话状态的情况下完全理解客户端请求。因此，所有状态都必须保存在客户端上。
可缓存
可以使用缓存约束，从而使响应数据能够被标记为可缓存或不可缓存。任何标记为可缓存的数据都可以重新用作对相同后续请求的响应。
统一接口
所有组件都必须通过一个统一的接口进行交互。因为所有的组件交互都是通过这个接口进行的，所以与不同服务的交互非常简单。界面是一样的！这也意味着可以单独进行实施更改。此类更改不会影响基本组件交互，因为统一接口始终保持不变。一个缺点是你被界面卡住了。如果可以通过更改接口为特定服务提供优化，那么您就不走运了，因为 REST 禁止这样做。然而，好的一面是，REST 针对 Web 进行了优化，因此 REST over HTTP 非常受欢迎！
上述概念代表了 REST 的定义特征，并将 REST 架构与其他架构（如 Web 服务）区分开来。请注意，REST 服务是一种 Web 服务，但 Web 服务不一定是 REST 服务。
有关 REST 和上述项目符号的更多详细信息，请参阅有关 REST 设计原则 的博客post。
编辑：根据评论更新内容
SOAP（简单对象访问协议）和 REST（表示状态传输）在它们的方式上都很漂亮。所以我不是在比较它们。相反，我试图描绘图片，当我更喜欢使用 REST 和 SOAP 时。
什么是有效载荷？
当通过 Internet 发送数据时，传输的每个单元都包括标题信息和发送的实际数据。标头标识数据包的源和目的地，而实际数据称为有效负载。通常，有效负载是代表应用程序携带的数据和目标系统接收的数据。
现在，例如，我必须发送电报，我们都知道电报的成本将取决于某些单词。
那么请告诉我，在下面提到的这两条消息中，哪一条更便宜？
<name>Arin</name>
或者
"name": "Arin"
我知道您的答案将是第二个，尽管两者都代表相同的消息，第二个在成本方面更便宜。
所以我想说的是，在网络上以 JSON 格式发送数据比在负载方面以 XML 格式发送数据要便宜。
这是 REST 优于 SOAP 的第一个好处或优势。 SOAP 只支持 XML，但 REST 支持不同的格式，如文本、JSON、XML 等。而且我们已经知道，如果我们使用 Json，那么在有效负载方面肯定会处于更好的位置。
现在，SOAP 只支持 XML，但它也有它的优点。
真的！如何？
SOAP 以三种方式依赖 XML 信封——它定义了消息中的内容以及如何处理它。
一组数据类型的编码规则，最后是收集的过程调用和响应的布局。
此信封通过传输 (HTTP/HTTPS) 发送，并执行 RPC（远程过程调用），并以 XML 格式文档的形式返回信封和信息。
重要的一点是 SOAP 的优点之一是使用“通用”传输，而 REST 使用 HTTP/HTTPS。 SOAP 几乎可以使用任何传输方式来发送请求，但 REST 不能。所以在这里我们得到了使用 SOAP 的优势。
正如我在上一段“REST 使用 HTTP/HTTPS”中已经提到的，所以对这些词再深入一点。
当我们谈论基于 HTTP 的 REST 时，所有应用 HTTP 的安全措施都会被继承，这就是所谓的传输级安全性，它仅在消息位于网络内部时保护消息，但一旦你在另一端传递它，你就不知道了在到达处理数据的实际点之前必须经过多少个阶段。当然，所有这些阶段都可以使用不同于 HTTP 的东西。所以 Rest 并不完全安全，对吧？
但是 SOAP 像 REST 一样支持 SSL，另外它还支持 WS-Security，它增加了一些企业安全特性。 WS-Security 提供从消息创建到消息使用的保护。因此，对于传输级别的安全性，我们发现的任何漏洞都可以使用 WS-Security 来防止。
除此之外，由于 REST 受到其 HTTP 协议的限制，因此它的事务支持既不符合 ACID，也不能提供跨分布式跨国资源的两阶段提交。
但是 SOAP 全面支持基于 ACID 的短期事务管理和基于补偿的长期事务管理。它还支持跨分布式资源的两阶段提交。
我没有得出任何结论，但我更喜欢基于 SOAP 的 Web 服务，而安全、事务等是主要关注点。
这是他们所说的“Java EE 6 教程”A RESTful design may be appropriate when the following conditions are met。看一看。
希望你喜欢阅读我的回答。
REST(REpresentational State Transfer) 对象的REpresentational State Transferred是REST，即我们不发送对象，我们发送对象的状态。 REST 是一种架构风格。它没有像 SOAP 那样定义那么多标准。 REST 用于通过 Internet 公开公共 API（即 Facebook API、Google Maps API）以处理数据的 CRUD 操作。 REST 专注于通过单一一致的接口访问命名资源。
SOAP（简单对象访问协议） SOAP 带来了自己的协议，并专注于将应用程序逻辑（而不是数据）作为服务公开。 SOAP 公开操作。 SOAP 专注于访问命名操作，每个操作都实现一些业务逻辑。尽管 SOAP 通常被称为 Web 服务，但这是用词不当。 SOAP 与 Web 几乎没有任何关系。 REST 提供基于 URI 和 HTTP 的真正 Web 服务。
为什么是 REST？
由于 REST 使用标准 HTTP，它几乎以任何方式都简单得多。
REST 更容易实现，需要更少的带宽和资源。
REST 允许许多不同的数据格式，而 SOAP 只允许 XML。
由于对 JSON 的支持，REST 可以更好地支持浏览器客户端。
REST 具有更好的性能和可扩展性。 REST 读取可以缓存，基于 SOAP 的读取不能缓存。
如果安全不是主要问题并且我们的资源有限。或者我们想创建一个其他开发人员可以轻松公开使用的 API，那么我们应该使用 REST。
如果我们需要无状态 CRUD 操作，请使用 REST。
REST 常用于社交媒体、网络聊天、移动服务和 Google 地图等公共 API。
RESTful 服务会为同一资源返回各种 MediaType，具体取决于请求标头参数“Accept”为 application/xml 或 application/json 用于 POST 和 /user/1234.json 或 GET /user/1234.xml 用于 GET。
REST 服务旨在由客户端应用程序调用，而不是由最终用户直接调用。
REST 中的 ST 来自于 State Transfer。您转移状态而不是让服务器存储它，这使得 REST 服务具有可扩展性。
为什么是肥皂？
SOAP 不是很容易实现，需要更多的带宽和资源。
与 REST 相比，SOAP 消息请求的处理速度较慢，并且不使用 Web 缓存机制。
WS-Security：虽然 SOAP 支持 SSL（就像 REST 一样），但它也支持 WS-Security，它增加了一些企业安全特性。
WS-AtomicTransaction：需要服务上的 ACID 事务，您将需要 SOAP。
WS-ReliableMessaging：如果您的应用程序需要异步处理以及保证级别的可靠性和安全性。 Rest 没有标准的消息传递系统，它希望客户端通过重试来处理通信失败。
如果安全是一个主要问题并且资源不受限制，那么我们应该使用 SOAP Web 服务。就像我们正在为支付网关、金融和电信相关工作创建 Web 服务一样，那么我们应该使用 SOAP，因为这里需要高安全性。
https://i.stack.imgur.com/WQsEJ.jpg
恕我直言，您无法比较 SOAP 和 REST，因为它们是两种不同的东西。
SOAP 是一种协议，而 REST 是一种软件架构模式。互联网上有很多关于 SOAP 与 REST 的误解。
SOAP 定义了基于 XML 的消息格式，支持 Web 服务的应用程序使用该格式在 Internet 上相互通信。为了做到这一点，应用程序需要事先了解消息契约、数据类型等。
REST 表示来自 URL 的服务器的状态（作为资源）。它是无状态的，客户端不应该有与服务器交互的先验知识，超出对超媒体的理解。
首先：正式地，正确的问题是 Web 服务 + WSDL + SOAP 与 REST。因为，虽然是web service，是在松散意义上使用的，但是当使用HTTP协议而不是web页面来传输数据时，官方上是这种思想的一种非常具体的形式。根据定义，REST 不是“Web 服务”。然而在实践中，每个人都忽略了这一点，所以我们也忽略它
已经有技术答案，所以我会尝试提供一些直觉。
假设您想调用远程计算机中的一个函数，该函数以其他编程语言实现（这通常称为远程过程调用/RPC）。假设可以在编写它的人提供的特定 URL 上找到该函数。您必须（以某种方式）向它发送一条消息，并得到一些响应。因此，有两个主要问题需要考虑。
您应该发送的消息格式是什么
消息应该如何来回传递
对于第一个问题，官方定义是WSDL。这是一个 XML 文件，详细而严格的格式描述了参数是什么，它们的类型是什么，名称，默认值，要调用的函数的名称等。这里的 An example WSDL 表明该文件是人的- 可读（但不容易）。
对于第二个问题，有多种答案。但是，实际使用的唯一一个是 SOAP。它的主要思想是：将先前的 XML（实际消息）包装成另一个 XML（包含编码信息和其他有用的东西），并通过 HTTP 发送。 HTTP 的 POST 方法用于发送消息，因为总是有一个正文。
整个方法的主要思想是将 URL 映射到函数，即操作。因此，如果您在某个服务器中有一个客户列表，并且您想查看/更新/删除一个，您必须有 3 个 URL：
myapp/read-customer 并在消息正文中传递要读取的客户的 ID。
myapp/update-customer 并在正文中，传递客户的 id 以及新数据
myapp/delete-customer 和正文中的 id
REST 方法以不同的方式看待事物。 URL 不应该代表一个动作，而是一个事物（在 REST 术语中称为资源）。由于 HTTP 协议（我们已经在使用）支持动词，因此使用这些动词来指定要对事物执行的操作。
因此，使用 REST 方法，可以在 URL myapp/customers/12 上找到 12 号客户。要查看客户数据，请使用 GET 请求点击 URL。要删除它，相同的 URL，带有DELETE 动词。要更新它，再次使用带有 POST 动词的相同 URL，以及请求正文中的新内容。
有关服务必须满足才能被视为真正 RESTful 的要求的更多详细信息，请参阅Richardson maturity model。文章给出了示例，更重要的是，解释了为什么（所谓的）SOAP 服务是 0 级 REST 服务（虽然，0 级意味着对这个模型的低遵从性，它并不令人反感，它仍然有用在许多情况下）。
REST不是网络服务？那么 JAX-RS 是什么？
在许多答案中已经涵盖的许多其他内容中，我要强调的是 SOAP 能够定义合同、WSDL，它定义了支持的操作、复杂类型等。SOAP 面向操作，但 REST 面向资源。就我个人而言，我会选择 SOAP 作为内部企业应用程序之间的复杂接口，而选择 REST 作为与外部世界的公共、更简单、无状态的接口。
https://i.stack.imgur.com/nJ6X2.jpg
补充：
++ 使用 REST 时经常犯的一个错误是将其视为“带有 URL 的 Web 服务”——将 REST 视为另一种远程过程调用 (RPC) 机制，如 SOAP，但通过纯 HTTP URL 调用，没有 SOAP 的强大功能XML 命名空间。
++ 相反，REST 与 RPC 关系不大。 RPC 是面向服务的，专注于动作和动词，而 REST 是面向资源的，强调构成应用程序的事物和名词。
很多这些答案完全忘记提及对 REST 来说完全是基础的超媒体控件 (HATEOAS)。其他一些人谈到了它，但并没有真正解释得那么好。
This article 应该解释这些概念之间的区别，而不是深入讨论特定的 SOAP 功能。
什么是 REST
REST 代表具象状态转移，它实际上是一种用于创建 Web API 的架构风格，它将一切（数据或功能）视为资源。它期望；通过URI暴露资源并以多种格式响应并以无状态方式表示资源状态的传输。这里我说两件事：
无状态方式：由 HTTP 提供。状态的代表性转移：例如，如果我们要添加员工。 .进入我们的系统，它处于HTTP的POST状态，之后它将处于HTTP的GET状态，同样的PUT和DELETE。
REST 可以使用 SOAP Web 服务，因为它是一个概念，可以使用任何协议，例如 HTTP，SOAP.SOAP 使用服务接口来公开业务逻辑。 REST 使用 URI 来公开业务逻辑。
没有 HATEOAS 的 REST 不是 REST。这意味着客户端只知道入口点 URI，并且资源应该返回客户端应该遵循的链接。那些为您可以在 REST API 中执行的所有操作提供 URI 模式的精美文档生成器完全没有抓住重点。他们不仅记录了应该遵循标准的东西，而且当你这样做时，你将客户端耦合到 API 演变中的一个特定时刻，并且必须记录和应用对 API 的任何更改，否则它会破裂。
HATEOAS 是 Hypermedia As The Engine Of Application State 的缩写，是 REST 应用程序架构的一个约束，将其与大多数其他网络应用程序架构区别开来。其原理是客户端完全通过应用服务器动态提供的超媒体与网络应用进行交互。除了对超媒体的一般理解之外，REST 客户端不需要有关如何与任何特定应用程序或服务器交互的先验知识。相比之下，在一些面向服务的体系结构 (SOA) 中，客户端和服务器通过文档或接口描述语言 (IDL) 共享的固定接口进行交互。
尽管 SOAP 和 REST 在 HTTP 协议上有相似之处，但 SOAP 是一组比 REST 更严格的消息传递模式。 SOAP 中的规则是相关的，因为没有它们我们就无法实现任何程度的标准化。 REST 作为一种架构风格不需要处理，并且本质上更加通用。本着信息交换的精神，SOAP 和 REST 都依赖于每个人都决定遵守的完善的法律。 SOAP 与 REST 的选择取决于您所使用的编程语言、您所使用的环境和规范。
要回答这个问题，了解分布式应用程序架构从简单的分层架构到基于对象和服务、再到基于资源的演变是很有用的，现在我们甚至有了基于事件的架构。大多数大型系统都使用样式组合。
第一个分布式应用程序具有分层架构。我假设这里的每个人都知道什么是层。这些结构组织整齐，可以是堆栈或循环结构。努力保持单向数据流。
基于对象的架构是从分层架构演变而来的，并遵循更松散的模型。在这里，每个组件都是一个对象（通常称为分布式对象）。对象使用类似于远程过程调用的机制相互交互——当客户端绑定到分布式对象时，它会将对象接口的实现加载到其地址空间中。 RPC 存根可以编组请求并接收响应。同样，服务器上的对象接口是一个 RPC 样式的存根。这些基于对象的系统的结构没有那么整齐，它看起来更像一个对象图。
分布式对象的接口隐藏了它的实现。与分层组件一样，如果明确定义了接口，则可以更改内部实现——甚至完全替换。基于对象的体系结构为封装服务提供了基础。服务由一个独立的实体提供，尽管它在内部可以使用其他服务。基于对象的体系结构逐渐演变为面向服务的体系结构 (SOA)。
使用 SOA，分布式应用程序由服务组成。这些服务可以跨管理域提供——它们可以通过网络获得（即由云提供商提供的存储服务）。
随着 Web 服务变得流行，越来越多的应用程序开始使用它们，服务组合（组合服务以形成新的服务）变得更加重要。 SOA 的问题之一是集成不同的服务可能变得极其复杂。
虽然 SOAP 是一种协议，但它的使用意味着面向服务的体系结构。 SOAP 试图为服务提供一个标准，使它们可以组合并易于集成。
基于资源的架构是解决 SOA 集成问题的不同方法。这个想法是将分布式系统视为由组件单独管理的巨大资源集合。这导致了 RESTful 架构的发展。 RESTful 服务的特征之一是无状态执行。这与服务器维护状态的 SOA 不同。
那么……与基于资源的架构（如 REST）相比，面向服务的架构（包括使用 SOAP 的架构）提供的特定于服务的接口如何？
虽然 REST 很简单，但它并没有为复杂的通信方案提供简单的接口。例如，如果您需要使用事务 REST 不合适，最好将复杂的状态封装在服务器上，而不是让客户端管理事务。但是在许多场景中，RESTful 架构中资源的正交使用极大地简化了服务的集成，否则这意味着服务接口的爆炸式增长。另一个权衡是基于资源的架构增加了客户端的复杂性并增加了网络流量，而基于服务的架构增加了服务器的复杂性并对其内存和 CPU 资源征税。
也有人提到了常见的 HTTP 服务或其他不满足 RESTful 架构或 SOAP 要求的服务。这些也可以分为基于服务的或基于资源的。这些具有更易于实现的优点。如果您知道您的服务永远不需要跨管理域集成，您只会使用这种方法，因为这不会尝试解决出现的集成问题。
这些基于 HTTP 的服务，尤其是伪 RESTful 服务仍然是最常见的类型。实现 SOAP 很复杂，只有在您真正需要时才应该使用它 - 即您需要一个可以轻松跨域集成的服务，并且您希望它有一个服务接口。仍然存在需要这样做的情况。真正的 RESTful 服务也很难实现，尽管不如 SOAP 难。
REST API
RESTful API 是最著名的 API 类型。 REST 代表代表性状态转移。
REST API 是遵循标准化原则、属性和约束的 API。
您可以使用 HTTP 动词访问 REST API 中的资源。
REST API 在简单的请求/响应系统上运行。您可以使用以下 HTTP 方法发送请求：
得到
邮政
放
修补
删除
痕迹
选项
连接
头
以下是最常见的 HTTP 动词
GET（读取现有数据）
POST（创建新的响应或数据）
PATCH（更新数据）
DELETE（删除数据）
客户端可以使用 HTTP 动词后跟端点发出请求。
端点（或路由）是您请求的 URL。路径决定了您请求的资源。
当您向端点发送请求时，它会使用相关数据进行响应，通常格式为 JSON、XML、纯文本、图像、HTML 等。
REST API 也可以设计为具有许多返回不同类型数据的不同端点。使用 REST API 访问多个端点需要各种 API 调用。
实际的 RESTful API 遵循以下五个约束：
客户端-服务器架构客户端从服务器请求数据，没有第三方解释。无状态 无状态意味着每个 HTTP 请求都是在完全隔离的情况下发生的。每个请求都包含服务请求所需的信息。服务器从不依赖来自先前请求的信息。没有状态。可缓存性响应可以显式或隐式定义为可缓存或不可缓存，以提高可伸缩性和性能。例如，开启 GET 请求的缓存可以提高资源数据请求的响应时间。分层 API 架构的不同层应该协同工作，创建一个易于更新或调整的可扩展系统。客户端和服务器之间的统一接口通信必须使用独立于两者的标准化语言来完成。这提高了可扩展性和灵活性。
REST API 非常适合需要
灵活的
可扩展
快速地
SOAP API
SOAP 是一种必要的协议，有助于引入 API 的广泛使用。
SOAP 是简单对象访问协议的首字母缩写。
SOAP 是一种标准化协议，它依赖于 XML 来发出请求和接收响应。
尽管 SOAP 基于 XML，但 SOAP 协议仍在广泛使用。
SOAP API 将数据作为服务提供，通常在执行涉及多个 API 调用的事务或以安全为主要考虑因素的应用程序时使用。
SOAP 最初于 1998 年为 Microsoft 开发，旨在提供一种标准机制，用于在 Internet 上集成服务，而不管操作系统、对象模型或编程语言如何。
SOAP 中的“S”代表 Simple，这是有充分理由的 - SOAP 可以以较低的复杂性使用，因为它在应用程序层中对事务、安全性和其他功能的编码需要较少。
SOAP 具有三个主要特征：
SOAP API 的可扩展性 SOAP 允许扩展引入更强大的功能，例如 Windows Server 安全性、寻址等。 SOAP API 的中立性 SOAP 能够在广泛的协议上运行，例如 UDP、JMS、SMTP、TCP 和 HTTP。可以运行。 SOAP API 的独立性 SOAP API 响应完全基于 XML。因此 SOAP API 是独立于平台和语言的。
开发人员继续争论使用 SOAP 和 REST 的利弊。最适合您的项目的将是符合您需求的项目。
尽管 REST 在很大程度上主导了 Web 应用程序，但 SOAP API 仍然是优先考虑安全性的企业实体和政府组织的首选。
SOAP 比 REST 更安全，因为它使用 WS-Security 和安全套接字层进行传输
SOAP 还具有更出色的事务可靠性，这也是 SOAP 历来受到银行业和其他大型实体青睐的另一个原因。
