Question

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

REST更具动态性，无需创建和更新UDDI（通用描述，发现和集成）。
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是网络本身的架构风格。当您输入Stack Overflow时，您知道用户，问题和答案是什么，您知道媒体类型，并且网站为您提供了指向它们的链接。 REST API必须执行相同的操作。如果我们按照人们认为应该完成REST的方式设计网络，而不是让主页上有问题和答案的链接，我们会有一个静态文档解释为了查看问题，你必须采用URI { {1}}，用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 vs SOAP是不要问的正确问题。

与REST不同，

SOAP是协议。

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

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

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

基本REST原则

客户端 - 服务器通信

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

<强>无国籍

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

<强>可缓存

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

统一界面

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

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

有关 REST 以及上述项目符号的更多详细信息，请参阅 REST设计原则上的此博客post。

编辑： 根据评论更新内容

Answer 3

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的安全措施都是继承的，这称为传输级别安全性，它仅在它在线路内时保护消息< / strong>但是一旦你在另一方交付它，你就不知道在到达处理数据的真实点之前需要经过多少个阶段。当然，所有这些阶段都可以使用与HTTP不同的东西。所以Rest完全不安全，对吧？

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

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

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

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

这是＆＃34; Java EE 6教程＆＃34;他们在哪里说A RESTful design may be appropriate when the following conditions are met。看看。

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

Answer 4

REST （ RE 表示 S tate T 转移）
对象的 RE 表示 S tate是 T 被传输的是REST，即我们不发送Object，我们发送Object的状态。 REST是一种架构风格。它没有定义像SOAP这么多的标准。 REST用于通过Internet公开公共API（即Facebook API，Google Maps API）以处理数据的CRUD操作。 REST专注于通过单个一致的接口访问命名资源。

SOAP （ S 实施 O bject A ccess P rotocol）<登记/> 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，具体取决于请求标头参数“接受”为application/xml或application/json用于POST和/user/1234.json或GET /user/1234.xml GET。
REST服务旨在由客户端应用程序调用，而不是直接由最终用户调用。
ST 来自 S tate T 转移。您转移状态而不是让服务器存储它，这使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 5

休息和肥皂的区别

<强> SOAP

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

<强> REST

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

有关详细信息，请参阅here

Answer 6

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

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

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

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

Answer 7

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

Answer 8

首先：正式而言，正确的问题是web services + WSDL + SOAP与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并在正文中传递客户ID和新数据
myapp/delete-customer和正文中的ID

REST方法对事物的看法不同。 URL不应该表示动作，而应该表示事物（strong）（在REST术语中称为 resource ）。由于HTTP协议（我们已经在使用）支持动词，因此使用这些动词来指定对事物执行的动作。

因此，使用REST方法，将在URL myapp/customers/12上找到12号客户。要查看客户数据，请使用GET请求命中URL。要删除它，请使用带有删除动词的相同 URL。要对其进行更新，请再次相同的 URL（带有POST动词），并在请求正文中添加新内容。

有关必须满足的服务才能被视为真正的RESTful的更多详细信息，请参见Richardson maturity model。本文提供了示例，并且更重要的是，解释了为什么（所谓的）SOAP服务是0级REST服务（尽管0级意味着对该模型的合规性较低，这不是令人反感的，并且仍然有用）在很多情况下）。

Answer 9

增加：

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

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

Answer 10

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

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

Answer 11

SOAP与REST之间的区别

Answer 12

什么是REST

REST代表代表性的状态转移，它实际上是一种用于创建Web API的体系结构样式，该API将一切（数据或功能）都视为资源。它期望；通过URI公开资源并以多种格式进行响应，并以无状态方式对资源状态进行表示性传递。我在这里谈论两件事：

无状态方式：由HTTP提供。
状态的代表性转移：例如，如果我们要添加一名员工。。进入我们的系统，它处于HTTP的POST状态，此后同样会处于HTTP，PUT和DELETE的GET状态。

REST可以使用SOAP Web服务，因为它是一个概念，可以使用HTTP，SOAP等任何协议。SOAP使用服务接口公开业务逻辑。 REST使用URI公开业务逻辑。

没有HATEOAS的REST不是REST。这意味着客户端仅知道入口点URI，并且资源应返回客户端应遵循的链接。那些为您在REST API中可以执行的所有操作提供URI模式的花哨文档生成器完全忽略了这一点。他们不仅在记录本应遵循该标准的内容，而且在执行此操作时，您将客户端与API演进中的特定时刻联系在一起，并且必须记录和应用API的任何更改，否则会破裂。

HATEOAS是“超媒体作为应用程序状态引擎”的缩写，是REST应用程序体系结构的约束条件，可将其与大多数其他网络应用程序体系结构区分开。原理是，客户端完全通过应用程序服务器动态提供的超媒体与网络应用程序进行交互。除了对超媒体有一般的了解之外，REST客户端不需要有关如何与任何特定应用程序或服务器进行交互的先验知识。相比之下，在某些面向服务的体系结构（SOA）中，客户端和服务器通过通过文档或接口描述语言（IDL）共享的固定接口进行交互。

Reference 1 Reference 2

Answer 13

尽管SOAP和REST在HTTP协议上具有相似之处，但是SOAP是一组比REST更严格的消息传递模式。 SOAP中的规则是相关的，因为没有它们，我们将无法实现任何程度的标准化。 REST不需要作为架构样式进行处理，并且本质上更具通用性。本着信息交换的精神，SOAP和REST都依赖于每个人都决定遵守的公认法律。 SOAP与REST的选择取决于您使用的编程语言和所使用的环境以及规范。

SOAP与REST（差异）

13 个答案:

基本REST原则