首先：在宽松的意义上，Web服务意味着使用HTTP协议来传输数据而不是网页 . 但是，从严格意义上讲，Web服务as defined by W3C是这种想法的一种非常具体的形式 . 因此，当人们谈论SOAP与REST时，他们实际上是指Web服务与REST（其中"web services"指的是官方定义，因为在实践中，REST服务也被所有人称为Web服务） .
有关服务必须满足的要求的更多详细信息，请参阅Richardson maturity model . 本文给出了一些示例，更重要的是，解释了为什么（所谓的）SOAP服务是一个0级REST服务（尽管，0级意味着对该模型的符合性低，它并不令人反感，它仍然有用在许多情况下） .
97
REST （ RE presentational S tate T ransfer） REST是一种架构风格 . 它没有定义像SOAP这么多的标准 . REST用于通过Internet公开公共API（即Facebook API，Google Maps API）以处理数据的CRUD操作 . REST专注于通过单个一致的接口访问命名资源 .
SOAP （ S imple O bject A ccess P rotocol） SOAP带来了自己的协议，并专注于将应用程序逻辑（而非数据）作为服务公开 . SOAP公开了操作 . SOAP专注于访问命名操作，每个操作都实现一些业务逻辑 . 虽然SOAP通常被称为 web services ，但这是用词不当 . SOAP与Web有很小的关系 . REST基于URI和HTTP提供真正的 Web services .
当我们讨论基于HTTP的REST时，所有应用HTTP的安全措施都被继承，这被称为 transport level security 并且它仅在 it is inside the wire 时保护消息，但是一旦你在另一侧发送它，你就不知道它会有多少个阶段在到达处理数据的真实点之前经过 . 当然，所有这些阶段都可以使用与HTTP不同的东西 . So Rest is not safer completely, right?
但SOAP supports SSL 就像REST另外 it also supports WS-Security ，它增加了一些企业安全功能 . WS-Security提供了对 creation of the message to it’s consumption 的保护 . 因此，对于传输级安全性，我们发现可以使用WS-Security阻止任何漏洞 .
除此之外，作为 REST is limited by it's HTTP protocol 所以它的事务支持既不符合ACID也不能跨分布式跨国资源提供两阶段提交 .
但是，对于长期交易和基于补偿的长期交易管理，SOAP全面支持 ACID based transaction management . 它还支持 two-phase commit across distributed resources .
最后一点可以't be emphasized enough. If your clients are building URIs from templates in documentation and not getting links in the resource representations, that'不是REST . REST的作者Roy Fielding在这篇博客文章中明确表示：REST APIs must be hypertext-driven .
12 回答
首先：在宽松的意义上，Web服务意味着使用HTTP协议来传输数据而不是网页 . 但是，从严格意义上讲，Web服务as defined by W3C是这种想法的一种非常具体的形式 . 因此，当人们谈论SOAP与REST时，他们实际上是指Web服务与REST（其中"web services"指的是官方定义，因为在实践中，REST服务也被所有人称为Web服务） .
所以，假设你想在远程计算机中调用一个函数，用其他编程语言（远程过程调用/ RPC）实现 . 你必须（以某种方式）向它发送消息，并得到一些回应 . 首先，该功能可以在其创建者提供的特定URL处找到 . 然后，有两个主要问题需要考虑 .
您应该发送的邮件格式是什么
如何来回传递信息
根据官方定义，第一个问题的答案是WSDL，一个XML，它以详细和严格的格式描述了什么是参数，它们的类型，名称，默认值，要调用的函数的名称对于第二个问题，有各种答案 . 最受欢迎（到目前为止）是SOAP . 它的主要思想是：将之前的XML（实际消息）包装到另一个XML中，然后通过HTTP发送它（尽管理论上它可以与其他协议一起使用，但没有人会这样做） . HTTP的POST方法用于发送消息，因为总有一个正文 .
因此，通过称为SOAP的方法（广泛但错误地），您将URL映射到函数，即一个操作 . RESTful方法是：代替表示操作的URL，它应该代表一个东西（在RESTful术语中称为资源） . 由于HTTP协议（我们已经在使用）支持动词，因此请使用这些动词来指定要对动作执行的操作 .
因此，使用SOAP（再次，错误的术语）方法，如果您有一个客户列表，并且您想要查看/更新/删除一个，您将有3个URL：
myapp/read-customer并在邮件正文中传递要阅读的客户的ID .myapp/update-customer并在正文中传递客户的ID，以及新的数据myapp/delete-customer和身体中的身份证明虽然使用REST方法，您只能拥有
myapp/customers/3（其中3是特定客户的ID） . 要查看客户数据，请使用GET请求点击URL . 要删除它，使用DELETE动词删除相同的URL . 要再次更新它，使用POST动词的相同URL以及请求正文中的新内容 .有关服务必须满足的要求的更多详细信息，请参阅Richardson maturity model . 本文给出了一些示例，更重要的是，解释了为什么（所谓的）SOAP服务是一个0级REST服务（尽管，0级意味着对该模型的符合性低，它并不令人反感，它仍然有用在许多情况下） .
REST （ RE presentational S tate T ransfer）
REST是一种架构风格 . 它没有定义像SOAP这么多的标准 . REST用于通过Internet公开公共API（即Facebook API，Google Maps API）以处理数据的CRUD操作 . REST专注于通过单个一致的接口访问命名资源 .
SOAP （ S imple O bject A ccess P rotocol）
SOAP带来了自己的协议，并专注于将应用程序逻辑（而非数据）作为服务公开 . SOAP公开了操作 . SOAP专注于访问命名操作，每个操作都实现一些业务逻辑 . 虽然SOAP通常被称为 web services ，但这是用词不当 . SOAP与Web有很小的关系 . REST基于URI和HTTP提供真正的 Web services .
Why REST?
由于REST使用标准HTTP，因此它在任何方面都要简单得多 .
REST更容易实现，需要更少的带宽和资源 .
REST允许许多不同的数据格式，而SOAP只允许XML .
REST由于支持JSON，因此可以更好地支持浏览器客户端 .
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 来自 S tate T ransfer . 您转移状态而不是让服务器存储它，这使REST服务可以扩展 .
Why 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
增加：
接近REST时经常犯的错误是将其视为“带URL的Web服务” - 将REST视为另一种远程过程调用（RPC）机制，如SOAP，但是通过纯HTTP URL调用，而没有SOAP的大量XML命名空间 .
相反，REST与RPC几乎没有关系 . 虽然RPC是面向服务的，并且专注于动作和动词，但REST是面向资源的，强调构成应用程序的事物和名词 .
在许多其他人中已经在许多答案中已经介绍过，我要强调SOAP能够定义一个 Contract ，WSDL，它定义了支持的操作，复杂的类型等.SOAP面向操作，但REST面向资源 . 就个人而言，我会为内部企业应用程序之间的复杂接口选择SOAP，并为外部世界的公共，简单，无状态接口选择REST .
恕我直言，你无法比较SOAP和REST，它们是两个不同的东西 .
SOAP 是一种协议， REST 是一种软件架构模式 . 对于 SOAP vs REST ，互联网存在很多误解 .
SOAP 定义了基于XML的消息格式，启用Web服务的应用程序通过Internet相互通信 . 为了做到这一点，应用程序需要事先了解消息 Contract ，数据类型等 .
REST 表示来自URL的服务器的状态（作为资源） . 它是无状态的，除了对超媒体的理解之外，客户端不应该具有与服务器交互的先验知识 .
两者之间的决定将是您设计Web服务的首选，因此了解两者的优缺点非常重要 . 在两种哲学之间有时激烈的争论中，将现实与修辞分开也很重要 .
REST fundamentals
REST中的所有内容都被视为资源 .
每个资源都由URI标识 .
使用统一接口 . 使用POST，GET，PUT，DELETE操作处理资源，这些操作类似于创建，读取，更新和删除（CRUD）操作 .
无国籍 . 每个请求都是一个独立的请求 . 从客户端到服务器的每个请求都必须包含理解请求所需的所有信息 .
通过表示进行通信 . 例如，XML，JSON RESTful Web服务 . RESTful Web服务基于HTTP方法和REST的概念 . RESTful Web服务通常定义服务的基URI;支持的MIME类型（XML，文本，JSON，用户定义，...）和支持的操作集（POST，GET，PUT，DELETE） .
SOAP fundamentals
WSDL定义了客户端和服务之间的 Contract ，并且本质上是静态的 .
SOAP在HTTP或有时TCP / IP之上构建基于XML的协议 .
SOAP描述了数据的功能和类型 .
SOAP是XML-RPC的后继者，非常相似，但描述了一种标准的通信方式 .
有几种编程语言对SOAP有本机支持，您通常会将其作为Web服务URL提供，您可以在不需要特定代码的情况下调用其Web服务功能 .
必须首先将发送的二进制数据编码为base64编码格式 .
有几个与之相关的协议和技术：WSDL，XSD，SOAP，WS-Addressing .
SOAP vs REST?
SOAP的一个主要优点是您拥有WSDL服务描述 . 您几乎可以自动发现服务并从该服务描述生成可用的客户端代理（生成服务调用，方法所需的数据类型等） . 请注意，对于版本2.0，WSDL支持所有HTTP谓词，并且也可以用于记录RESTful服务，但是为此目的，在WADL（Web应用程序描述语言）中有一个不太详细的替代方案 .
使用RESTful服务，消息安全性由传输协议（HTTPS）提供，并且仅是点对点的 . 它没有标准的消息传递系统，并希望客户端通过重试来处理通信故障 . SOAP内置了成功/重试逻辑，即使通过SOAP中介提供端到端的可靠性 .
RESTful API的一个主要优点是它可以灵活地进行数据表示，例如，您可以使用XML或JSON格式序列化数据 . RESTful API更清晰或更容易理解，因为它们添加了使用标准化URI的元素，并重视所使用的HTTP动词（即GET，POST，PUT和DELETE） .
RESTful服务也是轻量级的，即它们没有很多额外的XML标记 . 要调用RESTful API，您只需要一个浏览器或HTTP堆栈，并且几乎所有连接到网络的设备或机器都具有此功能 .
Advantages of REST
由于REST使用标准HTTP，因此几乎在所有方面都更简单 . 创建客户端，开发API，文档更容易理解，并且REST没有比SOAP更容易/更好的事情 .
REST允许许多不同的数据格式，而SOAP只允许XML . 虽然这看起来似乎增加了REST的复杂性，因为你需要处理多种格式，根据我的经验，这是非常有益的 . JSON通常更适合数据和解析更快 . 由于支持JSON，REST允许更好地支持浏览器客户端 .
REST具有更好的性能和可伸缩性 . REST读取可以缓存;无法缓存基于SOAP的读取 .
没有昂贵的工具需要与Web服务进行交互
较小的学习曲线
高效（SOAP对所有消息使用XML，REST可以使用较小的消息格式）
快速（无需大量处理）
更接近设计哲学中的其他Web技术
Advantages of SOAP
WS-Security: 虽然SOAP支持SSL（就像REST一样），但它也支持WS-Security，它增加了一些企业安全功能 . 通过中介支持身份，而不仅仅是点对点（SSL） . 它还提供数据完整性和数据的标准实现隐私 . 将其称为“企业”并不是说它更安全，它只是支持典型的互联网服务不需要的一些安全工具，事实上，它们仅在少数“企业”场景中需要 .
WS-AtomicTransaction: 需要通过服务进行ACID事务，您将需要SOAP . 虽然REST支持事务，但它并不全面且不符合ACID . 幸运的是，ACID交易几乎从未在互联网上有意义 . REST受HTTP本身的限制，它不能跨分布式事务资源提供两阶段提交，但SOAP可以 . 互联网应用程序不需要这种级别的事务可靠性，企业应用程序有时会这样做 .
WS-ReliableMessaging: Rest没有标准的消息传递系统，并希望客户端通过重试来处理通信故障 . SOAP内置了成功/重试逻辑，即使通过SOAP中介提供端到端的可靠性 .
语言，平台和传输独立（REST需要使用HTTP）
在分布式企业环境中运行良好（REST假定直接点对点通信）
标准化
以WS标准的形式提供重要的预构建可扩展性
内置错误处理
与某些语言产品一起使用时的自动化
Where to use REST
REST运行良好的领域是：
Limited bandwidth and resources: 记住返回结构实际上是任何格式（开发人员定义） . 此外，可以使用任何浏览器，因为REST方法使用标准的GET，PUT，POST和DELETE动词 . 同样，请记住，REST也可以使用大多数现代浏览器目前支持的XMLHttpRequest对象，这增加了AJAX的优势 .
stateless operations: 如果需要继续操作，那么REST不是最好的方法，SOAP可能更适合它 . 但是，如果您需要无状态CRUD（创建，读取，更新和删除）操作，那么REST就是它 .
Caching situations: 如果由于REST方法的无状态操作而可以缓存信息，这是完美的 .
Where to use SOAP
SOAP作为一个很好的解决方案的领域：
Asynchronous processing and invocation: 如果您的应用程序需要有保证的可靠性和安全性，那么SOAP 1.2提供了额外的标准来确保这种类型的操作 . 像WSRM - WS-Reliable Messaging之类的东西 .
Formal contracts: 如果双方（提供者和消费者）必须就交换格式达成一致，那么SOAP 1.2为这种类型的交互提供了严格的规范 .
Stateful operations: 如果应用程序需要上下文信息和会话状态管理，则SOAP 1.2在WS结构中具有附加规范以支持这些内容（安全性，事务，协调等） . 相比之下，REST方法将使开发人员构建这种自定义管道 .
休息和肥皂之间的区别
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
RESTvsSOAP是 not 正确的问题 .REST，与SOAP不同，是 not 协议 .REST是一种架构风格和基于网络的软件架构设计 .REST概念被称为资源 . 资源的表示必须是无状态的 . 它通过某种媒体类型表示 . 媒体类型的一些示例包括XML，JSON和RDF. 资源由组件操纵 . 组件通过标准统一接口请求和操作资源 . 在HTTP的情况下，该接口由标准HTTP操作组成，例如GET，PUT，POST，DELETE.@ Abdulaziz的问题确实说明了
REST和HTTP经常串联使用的事实 . 这主要是由于HTTP的简单性以及它与RESTful原则的非常自然的映射 .基本REST原则
Client-Server Communication
客户端 - 服务器架构具有非常明显的关注点分离 . 所有以RESTful样式构建的应用程序原则上也必须是客户端 - 服务器 .
Stateless
每个客户端对服务器的请求都要求其状态完全表示 . 服务器必须能够完全理解客户端请求，而无需使用任何服务器上下文或服务器会话状态 . 因此，所有州必须保留在客户端上 .
Cacheable
可以使用高速缓存约束，从而使响应数据能够被标记为可高速缓存或不可高速缓存 . 标记为可缓存的任何数据都可以重用作对同一后续请求的响应 .
Uniform Interface
所有组件必须通过单一的统一接口进行交互 . 由于所有组件交互都通过此接口进行，因此与不同服务的交互非常简单 . 界面是一样的！这也意味着可以单独进行实现更改 . 这种变化不会影响基本的组件交互，因为统一的接口总是不变的 . 一个缺点是您遇到了界面 . 如果可以通过更改界面为特定服务提供优化，那么由于REST禁止此操作，您将失去运气 . 然而，从好的方面来看，REST针对Web进行了优化，因此REST在HTTP上非常受欢迎！
上述概念表示REST的定义特征，并将REST架构与Web服务等其他架构区分开来 . 值得注意的是，REST服务是一种Web服务，但Web服务不一定是REST服务 .
有关 REST 和上述子弹的详细信息，请参阅 REST Design Principles 上的此博客post .
EDIT: 根据评论更新内容
SOAP是一种协议，而REST是架构 .
SOAP公开表示逻辑的行为，而REST公开表示数据的资源 .
就消费而言，REST服务比SOAP简单得多 . 使用REST处理XML封装的开销被消除，这使得它与SOAP相比更快 .
与REST相比，
SOAP提供了良好的安全选项 .
对于机器到机器的交互和企业解决方案，SOAP更受欢迎，但对于面向公众的API，REST是最佳选择，几乎70％的公共API都是REST .
REST轻量级，可维护和可扩展 .
REST与设备无关，即客户端使用REST API可以是移动设备，笔记本电脑，电视等 .
随着 Cloud 的出现 . 申请很慢迁移到基于 Cloud 的系统，如Azure，Amazon AWS . 这些系统是构建和暴露REST API的 . 因此，在REST API的顶部构建应用程序是一个很好的举措 .
REST Vs SOAP
SOAP（ Simple Object Access Protocol ）和REST（ Representation State Transfer ）都很漂亮 . 所以我不是在比较它们 . 相反，当我更喜欢使用REST和SOAP时，我试图描绘图片 .
What is payload?
现在，例如，我必须发送 Telegram ，我们都知道电报的费用取决于某些字 .
那么请告诉我下面提到的这两条消息，哪一条发送更便宜？
要么
我知道你的答案将是第二个，虽然两个代表相同的消息，第二个是成本更便宜 .
所以我想说， sending data over the network in JSON format is cheaper than sending it in XML format regarding payload .
Here is the first benefit or advantages of REST over SOAP . SOAP只支持XML，但REST支持不同的格式，如文本，JSON，XML等 . 我们已经知道，如果我们使用Json，那么我们肯定会在有效载荷方面做得更好 .
现在，SOAP支持唯一的XML， but it also has its advantages.
Really! How?
SOAP以三种方式依赖于XML Envelope - 定义消息中的内容以及如何处理它 .
一组数据类型的编码规则，最后是过程调用和响应的布局 .
此信封通过传输（HTTP / HTTPS）发送，并执行RPC（远程过程调用），并返回包含XML格式文档中信息的信封 .
重要的一点是 one of the advantages of SOAP 是 “generic” transport 的使用，但 REST uses HTTP/HTTPS . SOAP几乎可以使用任何传输来发送请求，但REST不能 . 所以在这里我们获得了使用SOAP的优势 .
正如我在上面的段落 “REST uses HTTP/HTTPS” 中已经提到的那样，所以对这些词进行更深入的研究 .
当我们讨论基于HTTP的REST时，所有应用HTTP的安全措施都被继承，这被称为 transport level security 并且它仅在 it is inside the wire 时保护消息，但是一旦你在另一侧发送它，你就不知道它会有多少个阶段在到达处理数据的真实点之前经过 . 当然，所有这些阶段都可以使用与HTTP不同的东西 . So Rest is not safer completely, right?
但SOAP supports SSL 就像REST另外 it also supports WS-Security ，它增加了一些企业安全功能 . WS-Security提供了对 creation of the message to it’s consumption 的保护 . 因此，对于传输级安全性，我们发现可以使用WS-Security阻止任何漏洞 .
除此之外，作为 REST is limited by it's HTTP protocol 所以它的事务支持既不符合ACID也不能跨分布式跨国资源提供两阶段提交 .
但是，对于长期交易和基于补偿的长期交易管理，SOAP全面支持 ACID based transaction management . 它还支持 two-phase commit across distributed resources .
我没有得出任何结论，但我更喜欢基于SOAP的Web服务，而安全性，事务等是主要关注点 .
这是"The Java EE 6 Tutorial"，他们说A RESTful design may be appropriate when the following conditions are met . 看一看 .
希望你喜欢阅读我的答案 .
不幸的是，围绕REST存在很多错误信息和误解 . 不仅您的问题和answer by @cmd反映了这些问题，而且大多数问题和答案都与Stack Overflow上的主题相关 .
SOAP和REST无法直接比较，因为第一个是协议（或至少是尝试），第二个是架构风格 . 这可能是其中混淆的原因之一，因为人们倾向于将REST称为非SOAP的任何HTTP API .
推动一些事情并尝试 Build 比较，SOAP和REST之间的主要区别在于客户端和服务器实现之间的耦合程度 . SOAP客户端的工作方式类似于自定义桌面应用程序，与服务器紧密耦合 . 客户端和服务器之间存在严格的 Contract ，如果任何一方发生任何变化，预计一切都会中断 . 您需要在任何更改后不断更新，但更容易确定是否遵循 Contract .
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就是这样的 .最后一点可以't be emphasized enough. If your clients are building URIs from templates in documentation and not getting links in the resource representations, that'不是REST . REST的作者Roy Fielding在这篇博客文章中明确表示：REST APIs must be hypertext-driven .
考虑到上述情况，您必须为链接设计和标准化某些格式 . 超链接是XML的标准配置，但不是JSON中的标准配置 . 有JSON的草案标准，如HAL .
最后，REST并不适合所有人，并且证明这一点就是大多数人使用他们错误地称为REST的HTTP API很好地解决他们的问题并且从不冒险 . REST有时很难做到，特别是在开始阶段，但随着时间的推移，它可以在服务器端更容易进化，并且客户端能够适应变化 . 如果您需要快速轻松地完成某项工作，请不要为正确的REST而烦恼 . 这可能不是你想要的 . 如果您需要一些必须在线保持数年甚至数十年的东西，那么REST就适合您 .
很多这些答案完全忘记提及完全基本的REST超媒体控件（HATEOAS） . 其他一些人接触过它，但并没有真正解释它 .
This article应该解释这些概念之间的区别，而不是涉及特定SOAP功能的杂草 .