SOAP vs REST（差异）
我已经阅读了有关SOAP和REST作为Web服务通信协议之间差异的文章，但我认为REST over SOAP的最大优势是：
REST更加动态，不需要创建和更新UDDI。
REST不限于XML格式。 REST Web服务可以发送纯文本，JSON和XML。
但是SOAP更加标准化（例如安全性）。
那么，我在这些方面是否正确？
不幸的是，REST有很多错误信息和误解。 不仅你的问题和@cmd的答案反映了这些，而且大部分问题和答案都与Stack Overflow的主题相关。
SOAP和REST不能直接比较，因为第一个是协议（或者至少试图成为），第二个是架构风格。 这可能是其中一个混乱的原因之一，因为人们倾向于将任何非SOAP的HTTP API称为REST。
推进一点并试图建立比较，SOAP和REST之间的主要区别在于客户端和服务器实现之间的耦合程度。 一个SOAP客户端就像一个自定义的桌面应用程序，与服务器紧密耦合。 客户端和服务器之间存在一个严格的合同，如果任何一方都改变了任何东西，那么一切都将被打破。 您需要在更改后不断更新，但更容易确定合同是否得到遵守。
REST客户端更像浏览器。 它是一个通用的客户端，知道如何使用协议和标准化方法，并且应用程序必须适合这一点。 您不会通过创建额外的方法来违反协议标准，您可以利用标准方法并在媒体类型上使用它们创建操作。 如果完成得当，耦合就会减少，并且可以更加优雅地处理更改。 除了入口点和媒体类型之外，客户端应输入一个REST服务，对API没有任何了解。 在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本身的架构风格。 当您输入堆栈溢出时，您知道用户，问题和答案是什么，您知道媒体类型，并且网站为您提供指向它们的链接。 REST API也必须这样做。 如果我们按照人们认为应该完成REST的方式设计网页，而不是让主页有问答链接，那么我们会有一个静态文档解释为了查看问题，您必须采用URI stackoverflow.com/questions/<id> ，将id替换为Question.id并将其粘贴到浏览器中。 这是无稽之谈，但这就是许多人认为REST的原因。
这最后一点不能被强调。 如果您的客户正在使用文档中的模板构建URI并且没有获取资源表示中的链接，那不是REST。 REST的作者Roy Fielding在这篇博文中明确表示：REST API必须是超文本驱动的。
考虑到上述情况，您会意识到虽然REST可能不限于XML，但要使用任何其他格式正确执行此操作，您必须为链接设计和标准化某些格式。 超链接在XML中是标准的，但不在JSON中。 有JSON标准草案，如HAL。
最后，REST并不适合每个人，并且一个证明就是大多数人用HTTP API错误地解决他们的问题，他们错误地称之为REST，从来没有冒险超越这个。 REST有时候很难做到，特别是在开始阶段，但随着时间的推移，服务器端的更容易的演变以及客户端对变化的恢复能力都会得到支持。 如果您需要快速轻松地完成某些操作，请不要为获取正确的REST而烦恼。 这可能不是你想要的。 如果您需要一些必须在线保持数年甚至数十年的内容，那么REST就是为您服务的。
REST vs SOAP 不是正确的问题。
与SOAP不同， REST 不是协议。
REST是基于网络的软件体系结构的架构风格和设计。
REST概念被称为资源。 资源的表示必须是无状态的。 它通过一些媒体类型来表示。 媒体类型的一些示例包括XML ， JSON和RDF 。 资源由组件操纵。 组件通过标准的统一接口请求和操作资源。 在HTTP的情况下，这个接口由标准的HTTP操作组成，例如GET ， PUT ， POST ， DELETE 。
@ Abdulaziz的问题确实证明了REST和HTTP经常被并行使用的事实。 这主要是由于HTTP的简单性及其对RESTful原则的非常自然的映射。
基本REST原则
客户端 - 服务器通信
客户端 - 服务器体系结构具有非常明显的关注点。 原则上，所有以REST风格构建的应用程序也必须是客户端服务器。
无状态
每个客户端对服务器的请求都要求其状态得到充分的表示。 服务器必须能够完全理解客户端请求，而无需使用任何服务器上下文或服务器会话状态。 因此，所有国家都必须留在客户身上。
可缓存
可以使用缓存约束，从而使响应数据被标记为可缓存或不可缓存。 标记为可缓存的任何数据可以被重用作对相同的后续请求的响应。
统一的界面
所有组件必须通过一个统一的界面进行交互。 因为所有组件交互都是通过这个接口进行的，所以与不同服务的交互非常简单 界面是一样的！ 这也意味着实施变更可以单独进行。 这种变化不会影响基本组件交互，因为统一接口总是不变。 一个缺点是你被困在界面中。 如果可以通过更改界面来为特定服务提供优化，那么REST禁止这样做是不可能的。 然而，光明的一面是，REST针对网络进行了优化，因此REST over HTTP非常受欢迎！
上述概念代表了REST的特性定义，并将REST架构与其他架构（如Web服务）区分开来。 请注意，REST服务是一项Web服务，但Web服务不一定是REST服务。
有关REST和上述项目符号的更多详细信息，请参阅REST设计原则的博客文章。
编辑：根据评论更新内容
SOAP（ 简单对象访问协议 ）和REST（ 表示状态传输 ）都很美观。 所以我没有比较它们。 相反，我试图描绘图片，当我更喜欢使用REST和SOAP时。
什么是有效载荷？
当通过因特网发送数据时，每个传送的单元包括标题信息和正在发送的实际数据。 标题标识数据包的来源和目的地， 而实际数据被称为有效负载 。 通常，有效载荷是代表应用程序携带的数据以及目标系统接收的数据。
现在，例如，我必须发送一封电报 ，我们都知道电报的费用将取决于某些字。
那么请告诉我下面提到的这两条消息，哪一条更便宜？
<name>Arin</name>
要么
"name": "Arin"
我知道你的答案将是第二个，尽管代表同样的消息第二个是成本更便宜。
所以我想说的是， 以JSON格式通过网络发送数据比以XML格式发送有关有效负载的数据便宜 。
这是REST优于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”中已经提到的那样，对这些单词进行更深入的研究。
当我们谈论REST over HTTP时，应用HTTP的所有安全措施都是继承的，这就是所谓的传输级别安全性 ，它只在内部线路中保护消息，但一旦你在另一方传递它，但你不知道在达到数据处理的真实点之前，需要经历多少阶段。 当然，所有这些阶段都可以使用与HTTP不同的内容。 所以休息并不完全安全，对吧？
但是SOAP像REST一样支持SSL ，另外它还支持增加一些企业安全功能的WS-Security 。 WS-Security为消息的创建提供了保护。 因此，对于传输级安全性，无论我们发现什么漏洞都可以使用WS-Security来阻止。
除此之外，由于REST受其HTTP协议限制，因此事务支持既不符合ACID标准，也不能跨分布式跨国资源提供两阶段提交。
但SOAP对短期交易的基于ACID的交易管理和长期交易的基于薪酬的交易管理提供全面的支持。 它还支持跨分布式资源的两阶段提交 。
我没有得出任何结论，但我更喜欢基于SOAP的Web服务，而安全性，交易等是主要关注点。
以下是他们所说的“Java EE 6教程”，当符合以下条件时，REST风格的设计可能是合适的。 看一看。
希望你喜欢阅读我的答案。
链接地址: http://www.djcxy.com/p/1933.html