SOAP与REST（差异）

Question

我读过关于SOAP和作为web服务通信协议的REST之间的区别的文章，但我认为REST相对于SOAP的最大优势是：

>

REST更动态，不需要创建和更新UDDI（通用描述、发现和集成）。

REST不仅限于XML格式。RESTful web服务可以发送纯文本/JSON/XML。

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

那么，我这几点是对的吗？

Answer 1

SOAP（简单对象访问协议）和REST（表示状态传输）在它们的方式上都很漂亮。所以我不是在比较他们。取而代之的是，我试图描绘一幅图片，当我更喜欢使用REST时，当使用SOAP时。

什么是有效载荷？

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

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

那么告诉我在下面提到的这两条信息中，哪一条更便宜呢？

<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的东西，所以Rest并不是完全安全的，对吧？

但是SOAP与REST一样支持SSL，此外，它还支持WS-Security，这增加了一些企业安全特性。WS-Security提供了从消息的创建到消息的使用的保护。因此，对于传输级别的安全性，我们发现的任何漏洞都可以使用WS-Security来防止。

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

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

我不是在下任何结论，但我会更喜欢基于SOAP的web服务，而安全性、事务等是主要关注点。

这里是“Java EE6教程”，他们说当满足以下条件时，RESTful设计可能是合适的。看看吧。

希望你喜欢看我的答案。

Answer 2

REST和SOAP不是正确的问题。

与SOAP不同，REST不是协议。

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

REST概念称为资源。资源的表示形式必须是无状态的。它通过某种媒体类型来表示。媒体类型的一些示例包括XML、JSON和RDF。资源由组件操纵。组件通过标准的统一接口请求和操作资源。在HTTP的情况下，此接口由标准HTTP操作组成，例如get、put、post、delete。

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

客户端-服务器通信

客户机-服务器体系结构有一个非常明显的关注点分离。以RESTful风格构建的所有应用程序原则上也必须是客户机-服务器。

无状态

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

可缓存

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

均匀界面

所有组件都必须通过单一的统一接口进行交互。因为所有组件交互都是通过这个接口发生的，所以与不同服务的交互非常简单。界面是一样的！这也意味着可以孤立地进行实现更改。这样的更改不会影响基本的组件交互，因为统一接口始终保持不变。一个缺点是你被界面卡住了。如果可以通过更改接口来为特定的服务提供html" target="_blank">优化，那么您就倒霉了，因为REST禁止这样做。然而，从好的方面来看，REST是针对web进行优化的，因此REST在HTTP上非常受欢迎！

上面的概念代表了REST的定义特性，并将REST体系结构与其他体系结构（如web服务）区分开来。需要注意的是，REST服务是web服务，但web服务不一定是REST服务。

有关REST和上述项目符号的更多细节，请参阅这篇关于REST设计原则的博文。

编辑：根据注释更新内容

Answer 3

不幸的是，围绕REST存在大量的错误信息和错误观念。不仅您的问题和@cmd的答案反映了这些，而且大多数问题和答案都与堆栈溢出有关。

SOAP和REST不能直接比较，因为前者是一种协议（或者至少是一种尝试），而后者是一种架构风格。这可能是引起混乱的原因之一，因为人们倾向于将REST称为任何不是SOAP的HTTP API。

稍微推动一下事情并试图建立一个比较，SOAP和REST之间的主要区别是客户机和服务器实现之间的耦合程度。SOAP客户机的工作方式类似于自定义桌面应用程序，与服务器紧密耦合。客户机和服务器之间有一个严格的契约，如果任何一方改变了任何事情，那么所有的事情都将被打破。您需要在任何更改后不断更新，但更容易确定合同是否得到遵守。

REST客户端更像是一个浏览器。它是一个通用的客户机，它知道如何使用协议和标准化方法，而应用程序必须与之相适应。创建额外的方法不会违反协议标准，您可以利用标准方法并在您的媒体类型上使用它们创建操作。如果处理得当，耦合会更少，并且可以更优雅地处理更改。客户机进入REST服务时，除了入口点和媒体类型外，对API一无所知。在SOAP中，客户机需要事先了解它将要使用的所有内容，否则它甚至不会开始交互。此外，REST客户端可以通过服务器本身提供的按需代码进行扩展，典型的示例是用于驱动与客户端上的另一个服务交互的JavaScript代码。

我认为这些是理解REST是关于什么以及它与SOAP有何不同的关键点：

>

REST与协议无关。它没有耦合到HTTP。REST应用程序可以使用任何有标准化URI方案的协议，就像您可以在网站上跟踪ftp链接一样。

REST不是CRUD到HTTP方法的映射。请阅读下面的答案以获得对此的详细解释。

REST与您正在使用的部件一样标准化。HTTP中的安全性和身份验证是标准化的，所以在HTTP上执行REST时，您就会使用这种方法。

没有超媒体和Hateoas的REST就不是REST。这意味着客户机只知道入口点URI，资源应该返回客户机应该遵循的链接。那些为您在REST API中所能做的一切提供URI模式的高级文档生成器完全没有达到这个目的。他们不仅记录了一些应该遵循标准的东西，而且当您这样做时，您将客户端耦合到API演进的某个特定时刻，API上的任何更改都必须记录并应用，否则它就会崩溃。

REST是web本身的架构风格。当您输入Stack Overflow时，您知道一个用户、一个问题和一个答案是什么，您知道媒体类型，网站为您提供了指向它们的链接。REST API也必须这样做。如果我们按照人们认为的REST的方式设计web,而不是拥有一个带有问题和答案链接的主页,那么我们就会有一个静态文档,说明为了查看问题,您必须使用URIstackoverflow.com/Questions/ ,用question.id替换id并将其粘贴到浏览器上。那是胡说八道，但很多人认为休息就是这样。

最后这一点怎么强调都不为过。如果您的客户机从文档中的模板构建URI，而没有在资源表示中获取链接，那就不是REST了。REST的作者Roy Fielding在这篇博文上明确表示：REST API必须是超文本驱动的。

考虑到以上内容，您将意识到，虽然REST可能不限于XML，但要正确使用任何其他格式，您必须为链接设计并标准化某种格式。超链接在XML中是标准的，但在JSON中不是。有JSON的标准草案，比如HAL。

最后，REST并不适合所有人，大多数人错误地使用称为REST的HTTP API很好地解决了他们的问题，并且从不冒险超越这一点，就是一个证明。REST有时很难实现，特别是在刚开始的时候，但随着时间的推移，服务器端的演进变得更容易，客户机对变化的适应能力也更强。如果你需要快速、轻松地完成某件事，就不要为得到正确的休息而烦恼。可能不是你要找的。如果你需要的东西必须在网上呆上几年甚至几十年，那么休息就是为你准备的。