很多答案完全忘记了超媒体控件(HATEOAS)，这是REST的基础。其他一些人也提到了这个问题，但并没有很好地解释它。

本文将解释这两个概念之间的区别，而不涉及具体SOAP特性的细节。

首先:正式来说，正确的问题应该是web服务+ WSDL + SOAP vs REST。 因为，虽然web服务在松散的意义上使用，当使用HTTP协议来传输数据而不是web页面时，它是这个想法的一种非常具体的形式。根据定义，REST不是“web服务”。 但实际上，每个人都忽略了这一点，所以我们也忽略它吧

已经有了一些技术上的答案，所以我将尝试提供一些直观的答案。

假设您想在远程计算机中调用一个函数，该函数是用其他编程语言实现的(这通常称为远程过程调用/RPC)。假设可以在编写函数的人提供的特定URL中找到该函数。你必须(以某种方式)向它发送一条消息，并得到一些响应。因此，有两个主要问题需要考虑。

你应该发送什么格式的信息 信息应该如何来回传递

对于第一个问题，官方定义是WSDL。这是一个XML文件，以详细和严格的格式描述了参数是什么，参数的类型是什么，名称，默认值，要调用的函数的名称，等等。这里的WSDL示例表明该文件是人类可读的(但并不容易)。

关于第二个问题，有各种各样的答案。然而，在实践中唯一使用的是SOAP。它的主要思想是:将之前的XML(实际消息)包装成另一个XML(包含编码信息和其他有用的内容)，并通过HTTP发送它。HTTP的POST方法用于发送消息，因为总是有消息体。

整个方法的主要思想是将URL映射到函数，即映射到操作。所以，如果你在某个服务器上有一个客户列表，你想查看/更新/删除一个，你必须有3个url:

Myapp /read-customer和在消息体中传递要读取的客户的id。 Myapp /update-customer和在body中传递客户的id以及新数据 Myapp /delete-customer和body中的id

REST方法有不同的看法。URL不应该代表一个动作，而是一个东西(在REST行话中称为资源)。因为HTTP协议(我们已经在使用)支持动词，所以使用这些动词来指定对该对象执行什么操作。

因此，使用REST方法，客户号12将在URL myapp/customers/12上找到。要查看客户数据，请使用GET请求点击URL。要删除它，使用相同的URL，使用delete动词。要更新它，再次使用带有POST谓词的相同URL和请求主体中的新内容。

有关服务必须满足才能被认为是真正RESTful的需求的更多细节，请参阅Richardson成熟度模型。本文给出了一些示例，更重要的是，解释了为什么(所谓的)SOAP服务是0级REST服务(尽管0级意味着对该模型的低遵从性，但它并不令人反感，并且在许多情况下仍然有用)。

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是为web优化的，因此REST在HTTP上非常流行!

上述概念代表了REST的定义特征，并将REST体系结构与其他体系结构(如web服务)区分开来。值得注意的是，REST服务是web服务，但web服务不一定是REST服务。

请参阅REST设计原则的博客文章，了解更多关于REST和上述要点的详细信息。

编辑:根据评论更新内容

什么是REST

REST代表具象状态传输，它实际上是一种创建Web API的架构风格，它将一切(数据或功能)视为资源。 预计;通过URI公开资源，以多种格式进行响应，并以无状态方式对资源的状态进行代表性传输。这里我要讲两件事:

无状态方式:由HTTP提供。 状态的代表性转移:例如，如果我们要增加一名员工。 进入我们的系统，它在HTTP的POST状态，之后它将在HTTP的GET状态，PUT和DELETE同样。

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

没有HATEOAS，休息就不是休息。这意味着客户端只知道入口点URI，资源应该返回客户端应该遵循的链接。那些花哨的文档生成器为您在REST API中可以做的所有事情提供URI模式，它们完全忽略了这一点。他们不仅记录应该遵循标准的东西，而且当你这样做的时候，你把客户端耦合到API发展的一个特定时刻，API上的任何更改都必须被记录和应用，否则它就会崩溃。

HATEOAS是Hypermedia As The Engine Of Application State的缩写，是REST应用程序体系结构的一个约束，它区别于大多数其他网络应用程序体系结构。其原理是客户端完全通过应用服务器动态提供的超媒体与网络应用程序进行交互。REST客户端不需要预先了解如何与任何特定的应用程序或服务器交互，只需要对超媒体有一般的理解。相反，在一些面向服务的体系结构(SOA)中，客户机和服务器通过文档或接口描述语言(IDL)共享的固定接口进行交互。

参考1 参考2

不幸的是，关于REST有很多错误的信息和误解。不仅你的问题和@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应该做的方式来设计网页，而不是有一个带有问答链接的主页，我们将有一个静态文档来解释为了查看一个问题，你必须使用URI stackoverflow.com/questions/<id>，将id替换为问题。Id并粘贴到浏览器上。这是无稽之谈，但这就是许多人认为的REST。

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

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

最后，REST并不适合所有人，最能证明这一点的就是大多数人是如何用他们错误地称为REST的HTTP api很好地解决他们的问题的，而且从来没有冒险超越它。REST有时很难做到，尤其是在开始的时候，但是随着时间的推移，它会带来更容易的服务器端的发展，以及客户端对变化的弹性。如果你需要快速轻松地完成某件事，就不要为正确使用REST而烦恼了。这可能不是你要找的。如果您需要一些必须在网上保持数年甚至数十年的东西，那么REST就是为您准备的。

SOAP(简单对象访问协议)和REST(表示状态传输)都有自己的美丽之处。所以我没有比较它们。相反，我试图描述我喜欢使用REST和SOAP的情况。

什么是有效载荷?

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

现在，举个例子，我要发一封电报，我们都知道电报的费用取决于某些词语。

那么告诉我下面提到的这两条信息，哪一条发的更便宜?

<name>Arin</name>

or

"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教程”，他们说，当满足以下条件时，RESTful设计可能是合适的。看一看。

希望你喜欢我的回答。