SOAP与REST（差异）

Question

我读过有关SOAP和REST作为Web服务通信协议之间差异的文章，但我认为REST优于SOAP的最大优势是：

1. REST更具动态性，无需创建和更新UDDI（通用描述，发现和集成）。
2. REST不仅限于XML格式。 RESTful Web服务可以发送纯文本/ JSON / XML。

但SOAP更标准化（例如：安全性）。

那么，我在这些方面是否正确？

Answer 1

不幸的是，围绕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方法的映射。阅读this答案，了解详细解释。
• REST与您正在使用的部分一样标准化。 HTTP中的安全性和身份验证是标准化的，因此这是您在通过HTTP进行REST时使用的内容。
• 没有hypermedia和HATEOAS，REST不是REST。这意味着客户端只知道入口点URI，并且资源应该返回客户端应该遵循的链接。那些为REST API中可以执行的操作提供URI模式的精美文档生成器完全忽略了这一点。它们不仅记录了应该遵循标准的内容，而且当您这样做时，您将客户端耦合到API发展过程中的某个特定时刻，并且必须记录和应用API的任何更改，或者它会破裂。
• REST是Web本身的架构风格。当您输入Stack Overflow时，您知道用户，问题和答案是什么，您知道媒体类型，并且网站为您提供了指向它们的链接。 REST API必须执行相同的操作。如果我们按照人们认为应该完成REST的方式设计网络，而不是让主页上有问题和答案的链接，我们会有一个静态文档解释为了查看问题，你必须使用URI stackoverflow.com/questions/<id> ，用Question.id替换id并将其粘贴到浏览器上。这是无稽之谈，但这就是许多人认为REST的含义。

最后一点不够强调。如果您的客户正在从文档中的模板构建URI而不是在资源表示中获取链接，那么这不是REST。 REST的作者Roy Fielding在这篇博客文章中明确表示：REST APIs must be hypertext-driven。

考虑到上述情况，您将意识到虽然REST可能不仅限于XML，但要使用任何其他格式正确执行，您必须设计并标准化链接的某些格式。超链接是XML中的标准，但不是JSON中的标准。有JSON的草案标准，如HAL。

最后，REST并不适合所有人，并且证明这一点就是大多数人使用他们错误地称为REST的HTTP API很好地解决他们的问题，并且从不冒险。 REST有时很难做到，特别是在开始阶段，但随着时间的推移，它可以在服务器端更容易进化，并且客户端可以适应变化。如果您需要快速轻松地完成某项工作，请不要担心REST是否正确。这可能不是你想要的。如果您需要一些必须在线保持数年甚至数十年的东西，那么REST就适合您。

Answer 2

很多这些答案完全忘记提及完全基本的REST超媒体控件（HATEOAS）。其他一些人接触了它，但并没有真正解释它。

This article应该解释这些概念之间的区别，而不是涉及特定SOAP功能的杂草。

Answer 3

REST vs SOAP不是一个正确的问题。

与REST不同，SOAP不是协议。

REST是一种架构风格和基于网络的软件架构设计。

REST概念被称为资源。资源的表示必须是无状态的。它通过某种媒体类型表示。媒体类型的一些示例包括XML，JSON和RDF。资源由组件操纵。组件通过标准统一接口请求和操作资源。在HTTP的情况下，该接口由标准HTTP操作组成，例如GET，PUT，POST，DELETE。

@ Abdulaziz的问题确实说明了REST和HTTP经常串联使用的事实。这主要是由于HTTP的简单性以及它与RESTful原则的非常自然的映射。

Fundamental REST Principles

客户端 - 服务器通信

客户端 - 服务器架构具有非常明显的关注点分离。所有以RESTful样式构建的应用程序原则上也必须是客户端 - 服务器。

无状态

每个客户端对服务器的请求都要求完全表示其状态。服务器必须能够完全理解客户端请求，而无需使用任何服务器上下文或服务器会话状态。因此，所有州必须保留在客户端上。

可缓存

可以使用高速缓存约束，从而使响应数据能够被标记为可高速缓存或不可高速缓存。标记为可缓存的任何数据都可以重用作对同一后续请求的响应。

统一界面

所有组件必须通过单一的统一接口进行交互。由于所有组件交互都通过此接口进行，因此与不同服务的交互非常简单。界面是一样的！这也意味着可以单独进行实现更改。这种变化不会影响基本的组件交互，因为统一的接口总是不变的。一个缺点是您遇到了界面。如果可以通过更改界面为特定服务提供优化，那么由于REST禁止此操作，您将失去运气。然而，从好的方面来看，REST针对Web进行了优化，因此REST在HTTP上非常受欢迎！

上述概念表示REST的定义特征，并将REST架构与Web服务等其他架构区分开来。值得注意的是，REST服务是一种Web服务，但Web服务不一定是REST服务。

有关REST和上述子弹的更多详细信息，请参阅此博客post有关REST设计原则的信息。

编辑：根据评论更新内容

Answer 4

SOAP（简单对象访问协议）和REST（表示状态转移）都很漂亮。所以我不是在比较它们。相反，当我更喜欢使用REST和SOAP时，我试图描绘图片。

什么是有效载荷？

当通过因特网发送数据时，发送的每个单元包括头信息和发送的实际数据。标头标识数据包的源和目标，而实际数据称为有效负载。通常，有效载荷是代表应用程序携带的数据和目标系统接收的数据。

现在，例如，我必须发送一份电报，我们都知道电报的费用取决于某些字。

那么请告诉我下面提到的这两条消息，哪一条发送更便宜？

<name>Arin</name>

要么

"name": "Arin"

我知道你的答案将是第二个，尽管两个代表同一个消息，第二个代价相对于成本更便宜。

所以我想说，通过网络以JSON格式发送数据比以XML格式发送有关负载更便宜。

这是REST over SOAP的第一个好处或优点。 SOAP仅支持XML，但REST支持不同的格式，如文本，JSON，XML等。我们已经知道，如果我们使用Json，那么我们肯定会在有效载荷方面做得更好。

现在，SOAP支持唯一的XML，但它也有其优点。

真！怎么样？

SOAP以三种方式依赖于XML Envelope - 定义消息中的内容以及如何处理它。

一组数据类型的编码规则，最后是过程调用和响应的布局。

此信封通过传输（HTTP / HTTPS）发送，并执行RPC（远程过程调用），并返回包含XML格式文档中信息的信封。

重要的一点是，SOAP的一个优点是使用“通用”传输，但REST使用HTTP / HTTPS。 SOAP几乎可以使用任何传输来发送请求，但REST不能。所以在这里我们获得了使用SOAP的优势。

正如我在上面的段落“REST使用HTTP / HTTPS”中已经提到的那样，所以对这些词进行更深入的研究。

当我们讨论基于HTTP的REST时，所有应用HTTP的安全措施都是继承的，这称为传输级安全性，它只在邮件内部保护邮件但是一旦你在另一端发送它就不知道在到达处理数据的真实点之前需要经过多少个阶段。当然，所有这些阶段都可以使用与HTTP不同的东西。所以Rest完全不安全，对吧？

但SOAP支持SSL就像REST一样，它还支持WS-Security，它增加了一些企业安全功能。 WS-Security可以防止消息的创建。因此，对于传输级安全性，我们发现可以使用WS-Security阻止任何漏洞。

除此之外，由于REST受到HTTP协议的限制，因此它的事务支持既不符合ACID，也不能跨分布式跨国资源提供两阶段提交。

但SOAP全面支持基于ACID的短期事务事务管理和基于长期事务管理的基于补偿的事务管理。它还支持跨分布式资源的两阶段提交。

我没有得出任何结论，但我更喜欢基于SOAP的Web服务，而安全性，事务等是主要关注点。

这是他们说过A RESTful design may be appropriate when the following conditions are met的“Java EE 6教程”。看一看。

希望你喜欢阅读我的答案。

Answer 5

REST（代表国家转移） 对象的REpresentational State is Transferred是REST，即我们不发送Object，我们发送Object的状态。 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 Maps等公共API。
• RESTful服务返回相同资源的各种MediaType，具体取决于请求标头参数“Accept”为application/xml或application/json用于POST和/user/1234.json或GET /user/1234.xml用于GET。
• REST服务旨在由客户端应用程序调用，而不是直接由最终用户调用。
• REST中的ST来自State Transfer。您转移状态而不是让服务器存储它，这使REST服务可以扩展。

为何选择SOAP？

• SOAP实现起来不是很容易，需要更多的带宽和资源。
• 与REST相比，SOAP消息请求的处理速度较慢，并且它不使用Web缓存机制。
• WS-Security：虽然SOAP支持SSL（就像REST一样），但它也支持WS-Security，它增加了一些企业安全功能。
• WS-AtomicTransaction：需要通过服务进行ACID事务，您将需要SOAP。
• WS-ReliableMessaging：如果您的应用程序需要异步处理并保证可靠性和安全性。 Rest没有标准的消息传递系统，并希望客户端通过重试来处理通信故障。
• 如果安全性是一个主要问题，并且资源不受限制，那么我们应该使用SOAP Web服务。就像我们正在为支付网关，金融和电信相关工作创建Web服务一样，我们应该使用SOAP，因为这里需要高安全性。

source1 source2

Answer 6

休息和肥皂之间的区别

肥皂

1. SOAP是一种协议。
2. SOAP代表简单对象访问协议。
3. SOAP不能使用REST，因为它是一种协议。
4. SOAP使用服务接口来公开业务逻辑。
5. SOAP定义了严格遵循的标准。
6. SOAP需要比REST更多的带宽和资源。
7. SOAP定义了自己的安全性。
8. SOAP仅允许XML数据格式。
9. SOAP不如REST优先。

休息

1. REST是一种架构风格。
2. REST代表Representational State Transfer。
3. REST可以使用SOAP Web服务，因为它是一个概念，可以使用任何协议，如HTTP，SOAP。
4. REST使用URI来公开业务逻辑。
5. REST没有定义太多像SOAP这样的标准。
6. REST比SOAP需要更少的带宽和资源。
7. RESTful Web服务从底层传输继承安全措施。
8. REST允许不同的数据格式，如纯文本，HTML，XML，JSON等。
9. REST比SOAP更受欢迎。

有关详细信息，请参阅here

Answer 7

恕我直言，你无法比较SOAP和REST，它们是两个不同的东西。

SOAP是一种协议，REST是一种软件架构模式。互联网上存在很多关于SOAP与REST的误解。

SOAP定义了基于XML的消息格式，启用Web服务的应用程序通过Internet相互通信。为了做到这一点，应用程序需要事先了解消息契约，数据类型等。

REST表示来自URL的服务器的状态（作为资源）。它是无状态的，除了对超媒体的理解之外，客户端不应该具有与服务器交互的先验知识。

Answer 8

首先：正式，正确的问题是web services + WSDL + SOAP vs REST。

因为，虽然Web服务是在松散的意义上使用，当使用HTTP协议来传输数据而不是网页时，officially它是一种非常具体的形式。根据定义，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和身体，传递客户的身份，以及新的数据
• myapp/delete-customer和体内的身份

REST方法以不同的方式看待事物。 URL不应该代表一个动作，而应该代表一个东西（在REST术语中称为资源）。由于HTTP协议（我们已经在使用）支持动词，因此使用这些动词来指定要对动作执行的操作。

因此，使用REST方法，客户编号12将在URL myapp/customers/12上找到。要查看客户数据，请使用GET请求点击URL。要删除它，使用DELETE谓词的相同URL。要再次更新它，使用POST动词的相同URL以及请求正文中的新内​​容。

有关服务必须满足的要求的更多详细信息，请参阅Richardson maturity model。本文给出了一些示例，更重要的是，解释了为什么（所谓的）SOAP服务是一个0级REST服务（尽管，0级意味着对该模型的符合性低，它不具有攻击性，并且它仍然有用在许多情况下）。

Answer 9

在众多答案中已经涵盖的许多其他内容中，我要强调SOAP能够定义一个合同，WSDL，它定义了支持的操作，复杂的类型等.SOAP面向操作，但REST面向资源。就个人而言，我会为内部企业应用程序之间的复杂接口选择SOAP，而为外部世界的公共，简单，无状态接口选择REST。

Answer 10

增加：

++在接近REST时经常犯的错误是将其视为“带URL的Web服务” - 将REST视为另一种远程过程调用（RPC）机制，如SOAP，但是通过普通的HTTP URL调用而没有SOAP的大量XML命名空间。

++相反，REST与RPC几乎没有关系。虽然RPC是面向服务的，并且专注于动作和动词，但REST是面向资源的，强调构成应用程序的事物和名词。