我已经阅读了有关 SOAP 和 REST 作为 Web 服务通信协议之间的区别的文章,但是我认为 REST 相对于 SOAP 的最大优势在于:
REST 更动态,无需创建和更新 UDDI(通用描述,发现和集成)。
REST 不仅限于 XML 格式。 RESTful Web 服务可以发送纯文本 / JSON / XML。
但是 SOAP 更加标准化(例如:安全性)。
那么,我在这些方面是否正确?
不幸的是,关于 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 与您使用的部件一样标准化。 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 替换为 Question.id 并将其粘贴到浏览器中。那是胡扯,但这就是许多人认为 REST 的含义。
最后一点不能足够强调。如果您的客户是从文档中的模板构建 URI,而未在资源表示中获得链接,则不是 REST。 REST 的作者 Roy Fielding 在此博客文章中明确指出: REST API 必须是超文本驱动的 。
考虑到以上几点,您将认识到,尽管 REST 可能不限于 XML,但要正确地使用其他任何格式,则必须为链接设计和标准化某种格式。超链接是 XML 的标准配置,但不是 JSON 的标准配置。有 JSON 的标准草案,例如HAL 。
最后,REST 并不适合所有人,这证明了大多数人如何使用错误地称为 REST 的 HTTP API 很好地解决他们的问题,并且永不冒险。 REST 有时很难做到,尤其是在开始时,但是随着时间的流逝,它会在服务器端更轻松地演进以及客户对变更的适应力中付出代价。如果您需要快速,轻松地完成某件事,请不要担心正确使用 REST。可能不是您要找的东西。如果您需要某些东西必须保持在线状态长达数年甚至数十年,那么 REST 适合您。
REST
vs SOAP
不是正确的问题。
REST
与SOAP
不同,它不是协议。
REST
是一种架构风格和基于网络的软件架构设计 。
REST
概念称为资源。资源的表示形式必须是无状态的。它通过某种媒体类型表示。媒体类型的一些示例包括XML
, JSON
和RDF
。资源由组件操纵。组件通过标准的统一接口请求和操纵资源。对于 HTTP,此接口由标准 HTTP 操作组成,例如GET
, PUT
, POST
, DELETE
。
@Abdulaziz 的问题确实说明了REST
和HTTP
经常串联使用的事实。这主要是由于 HTTP 的简单性及其对 RESTful 原理的非常自然的映射。
客户端 - 服务器通信
客户端 - 服务器体系结构的关注点非常不同。原则上,以 RESTful 样式构建的所有应用程序也必须是客户端服务器。
无状态
每个对服务器的客户端请求都要求完全表示其状态。服务器必须能够完全理解客户端请求,而无需使用任何服务器上下文或服务器会话状态。因此,所有状态都必须保留在客户端上。
可缓存
可以使用缓存约束,从而使响应数据可以标记为可缓存或不可缓存。任何标记为可缓存的数据都可以重用作为对相同后续请求的响应。
统一接口
所有组件都必须通过一个统一的界面进行交互。因为所有组件交互都是通过此接口发生的,所以与不同服务的交互非常简单。界面是一样的!这也意味着可以单独进行实现更改。这样的更改不会影响基本组件的交互,因为统一接口始终不变。一个缺点是您被接口卡住了。如果可以通过更改接口来为特定服务提供优化,则您很不走运,因为 REST 禁止这样做。从好的方面来说,REST 是针对 Web 优化的,因此 REST 在 HTTP 上的普及程度令人难以置信!
以上概念代表了 REST 的定义特征,并将 REST 体系结构与其他体系结构(如 Web 服务)区分开来。值得注意的是,REST 服务是 Web 服务,但是 Web 服务不一定是 REST 服务。
有关REST和上述项目符号的更多详细信息,请参见有关REST 设计原则的博客文章 。
编辑: 根据评论更新内容
SOAP( 简单对象访问协议 )和 REST( 表示状态传输 )两者的方式都很漂亮。所以我没有比较它们。相反,当我更喜欢使用 REST 和 SOAP 时,我试图描绘出这张图。
什么是有效载荷?
当数据通过 Internet 发送时,每个发送的单元都包括标头信息和实际发送的数据。标头标识数据包的源和目的地, 而实际数据称为有效负载 。通常,有效负载是代表应用程序承载的数据和目标系统接收的数据。
例如,现在我必须发送电报 ,我们都知道电报的费用将取决于某些单词。
因此,请在下面提到的这两个消息中告诉我,哪个消息发送起来更便宜?
<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 不同的东西。 因此,休息并不完全安全,对吗?
但是 SOAP 像 REST 一样支持 SSL ,它还支持 WS-Security ,它增加了一些企业安全性功能。 WS-Security 提供了从创建消息到使用消息的保护。因此,对于传输级安全性,我们发现可以使用 WS-Security 避免的任何漏洞。
除此之外,由于REST 受 HTTP 协议的限制,因此它的事务支持既不符合 ACID,也不能提供跨分布式跨国资源的两阶段提交。
但是 SOAP 全面支持短期交易的基于 ACID 的交易管理和长期交易的基于补偿的交易管理。它还支持跨分布式资源的两阶段提交 。
我没有得出任何结论,但是我将更喜欢基于 SOAP 的 Web 服务,而安全,事务等是主要关注点。
在这里的 “Java EE 6 教程” 中, 当满足以下条件时 ,他们说RESTful 设计可能是合适的 。看一看。
希望您喜欢阅读我的回答。
REST(RE表象的小号泰特贸易交接)
RE表象S上的对象为T ransferred 是 REST,即我们不会发送对象,我们发送对象的状态泰特。 REST 是一种建筑风格。它没有定义很多标准,例如 SOAP。 REST 用于通过 Internet 公开公共 API(即 Facebook API,Google Maps API)以处理数据的 CRUD 操作。 REST 专注于通过单个一致的接口访问命名资源。
SOAP(šimpleöbject 甲 CCESS P rotocol)
SOAP 带来了自己的协议,并着重于将应用程序逻辑部分(而非数据)公开为服务。 SOAP 公开操作。 SOAP 专注于访问命名操作,每个操作实现一些业务逻辑。尽管 SOAP 通常被称为Web 服务,但这是错误的称呼。 SOAP 与 Web 几乎没有关系。 REST 提供基于 URI 和 HTTP 的真正的Web 服务 。
为什么要 REST?
application/xml
或application/json
为 POST 和/user/1234.json
或 GET /user/1234.xml
为 GET。 为什么要使用 SOAP?
休息和肥皂之间的区别
肥皂
休息
有关更多详细信息,请参见此处
恕我直言,您无法比较 SOAP 和 REST,因为两者是两个不同的地方。
SOAP是一种协议, REST是一种软件体系结构模式。互联网上对于SOAP 与 REST有很多误解。
SOAP定义了基于 XML 的消息格式,支持 Web 服务的应用程序使用该消息格式通过 Internet 相互通信。为了做到这一点,应用程序需要消息合约,数据类型等方面的先验知识。
REST通过 URL 表示服务器的状态(作为资源),它是无状态的,并且客户端不应该具有对超媒体的了解,与服务器进行交互的先验知识。
首先:正式地,正确的问题是
web services + WSDL + SOAP
与REST
。因为尽管松散地使用了Web 服务 ,但是当使用 HTTP 协议而不是网页传输数据时 , 正式地说,这是该思想的一种非常具体的形式。根据定义,REST 不是 “Web 服务”。
但是实际上,每个人都忽略了这一点,所以我们也忽略它
已经有了技术上的答案,因此我将尝试提供一些直觉。
假设您要在远程计算机上调用以其他编程语言实现的函数(通常称为远程过程调用 / RPC )。假定可以在编写者提供的特定 URL 上找到该函数。您必须(以某种方式)向其发送消息,并获得一些响应。因此,有两个主要问题需要考虑。
对于第一个问题,正式定义是WSDL 。这是一个 XML 文件,以详细且严格的格式描述参数是什么,参数的类型,名称,默认值,要调用的函数的名称等。此处的WSDL 示例显示该文件是人的可读(但不容易)。
对于第二个问题,有各种各样的答案。但是,实践中唯一使用的是SOAP 。它的主要思想是:将先前的 XML(实际消息)包装到另一个 XML(包含编码信息和其他有用的东西)中,然后通过 HTTP 发送。 HTTP 的 POST 方法用于发送消息,因为始终有一个 body 。
整个方法的主要思想是将URL 映射到一个函数 ,即一个 action 。因此,如果您在某个服务器上有一个客户列表,并且想要查看 / 更新 / 删除一个客户,则必须有 3 个 URL:
myapp/read-customer
并在邮件正文中传递要读取的客户的 ID。 myapp/update-customer
并在正文中传递客户的 ID 以及新数据myapp/delete-customer
和主体中的 ID REST 方法对事物的看法不同。 URL 不应代表动作,而应代表事物 (在 REST 术语中称为资源 )。由于 HTTP 协议(我们已经在使用)支持动词,因此请使用这些动词来指定对事物执行什么动作 。
因此,使用 REST 方法,可以在 URL myapp/customers/12
上找到 12 号myapp/customers/12
。要查看客户数据,请使用 GET 请求命中 URL。要删除它,请使用带有 DELETE 动词的相同 URL。要再次更新它,请使用带有 POST 动词的相同 URL,并在请求正文中添加新内容。
有关必须满足的服务才能被视为真正的 RESTful 的更多详细信息,请参阅Richardson 成熟度模型 。本文提供了示例,并且更重要的是,解释了为什么(所谓的)SOAP 服务是 0 级 REST 服务(尽管 0 级意味着对该模型的合规性较低,这不是令人反感的,并且仍然有用)在许多情况下)。
除了:
++ 接近 REST 时常犯的一个错误是将其视为 “带有 URL 的 Web 服务”- 将 REST 视为另一种远程过程调用(RPC)机制,例如 SOAP,但通过普通 HTTP URL 调用而没有 SOAP 的麻烦 XML 名称空间。
++ 相反,REST 与 RPC 无关。 RPC 是面向服务的,并且侧重于动作和动词,而 REST 是面向资源的,强调了组成应用程序的事物和名词。
这些答案中有很多都完全忘记了提及 REST 根本所需的超媒体控件(HATEOAS)。其他一些人对此有感触,但并没有很好地解释它。
本文应该解释这些概念之间的区别,而不必深入了解特定的 SOAP 功能。