我读过关于SOAP和REST作为web服务通信协议的区别的文章,但是我认为REST相对于SOAP的最大优势是:

REST更加动态,不需要创建和更新UDDI(通用描述、发现和集成)。 REST不仅限于XML格式。RESTful web服务可以发送纯文本/JSON/XML。

但是SOAP更加标准化(例如:安全性)。

那么,这些点我说对了吗?


当前回答

很多答案完全忘记了超媒体控件(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,即我们不发送对象,我们发送对象的状态。 REST是一种架构风格。它没有像SOAP那样定义那么多标准。REST用于公开公共api(例如:Facebook API,谷歌Maps API)通过互联网处理数据的CRUD操作。REST的重点是通过单一一致的接口访问命名资源。

简单对象访问协议 SOAP带来了自己的协议,并专注于将应用程序逻辑(而不是数据)片段作为服务公开。SOAP公开操作。SOAP关注于访问命名操作,每个操作实现一些业务逻辑。虽然SOAP通常被称为web服务,但这是用词不当。SOAP与Web几乎没有任何关系。REST提供了基于uri和HTTP的真正Web服务。

为什么休息?

由于REST使用标准的HTTP,它在任何方面都要简单得多。 REST更容易实现,需要的带宽和资源更少。 REST允许许多不同的数据格式,而SOAP只允许XML。 REST由于对JSON的支持,可以更好地支持浏览器客户端。 REST具有更好的性能和可伸缩性。REST读取可以被缓存,基于SOAP的读取不能被缓存。 如果安全不是主要问题,而我们的资源有限。或者我们想要创建一个其他开发人员可以轻易公开使用的API,那么我们应该选择REST。 如果我们需要无状态的CRUD操作,那么就使用REST。 REST通常用于社交媒体、网络聊天、移动服务和谷歌地图等公共api。 RESTful服务为相同的资源返回各种MediaTypes,这取决于请求头参数“Accept”,如application/xml或application/json for POST和/user/1234。json或GET /user/1234.xml。 REST服务应该由客户端应用程序调用,而不是由最终用户直接调用。 REST中的ST来自于状态传输。您可以四处传输状态,而不是让服务器存储它,这使得REST服务具有可伸缩性。

为什么肥皂?

SOAP不是很容易实现,需要更多的带宽和资源。 与REST相比,SOAP消息请求处理速度较慢,并且不使用web缓存机制。 WS-Security:虽然SOAP支持SSL(就像REST一样),但它也支持添加了一些企业安全特性的WS-Security。 WS-AtomicTransaction:需要服务上的ACID事务,您将需要SOAP。 WS-ReliableMessaging:如果您的应用程序需要异步处理和有保证的可靠性和安全性级别。Rest没有标准的消息传递系统,并期望客户端通过重试来处理通信失败。 如果安全性是一个主要问题,并且资源不受限制,那么我们应该使用SOAP web服务。例如,如果我们正在为支付网关、金融和电信相关的工作创建web服务,那么我们应该使用SOAP,因为这里需要高安全性。

source1 source2

要回答这个问题,了解分布式应用程序的架构从简单的分层架构到基于对象和服务的架构,再到基于资源的架构,现在我们甚至有了基于事件的架构,这是很有用的。大多数大型系统使用风格的组合。

第一个分布式应用程序具有分层的体系结构。我想这里的每个人都知道什么是层。这些结构被整齐地组织起来,并且可以是堆栈或循环结构。努力维护单向数据流。

基于对象的体系结构从分层体系结构发展而来,遵循一个更宽松的模型。在这里,每个组件都是一个对象(通常称为分布式对象)。对象之间使用类似于远程过程调用的机制进行交互——当客户端绑定到分布式对象时,它将对象接口的实现加载到其地址空间中。RPC存根可以封送请求并接收响应。同样,服务器上的对象接口是一个RPC样式的存根。这些基于对象的系统的结构组织得不是很整齐,它看起来更像一个对象图。

分布式对象的接口隐藏了它的实现。与分层组件一样,如果接口定义得很清楚,内部实现就可以改变——甚至完全替换。
基于对象的体系结构为封装服务提供了基础。服务是由自包含的实体提供的,尽管在内部它可以使用其他服务。逐渐地,基于对象的体系结构演变为面向服务的体系结构。

使用SOA,分布式应用程序由服务组成。这些服务可以跨管理域提供——它们可以在web上可用(即由云提供商提供的存储服务)。

随着web服务的流行,越来越多的应用程序开始使用它们,服务组合(将服务组合成新的服务)变得更加重要。SOA的一个问题是,集成不同的服务可能会变得极其复杂。


虽然SOAP是一种协议,但它的使用意味着面向服务的体系结构。SOAP试图为服务提供一种标准,通过这种标准,服务可以组合并易于集成。

基于资源的体系结构是解决SOA集成问题的不同方法。其思想是将分布式系统视为由组件单独管理的巨大资源集合。 这导致了RESTful体系结构的开发。RESTful服务的一个特征是无状态执行。这与由服务器维护状态的SOA不同。

那么……由面向服务的体系结构(包括使用SOAP的体系结构)提供的特定于服务的接口与基于资源的体系结构(如REST)相比如何?



虽然REST很简单,但它并没有为复杂的通信方案提供简单的接口。例如,如果要求使用事务REST是不合适的,那么最好将复杂状态封装在服务器上,而不是让客户端管理事务。但是在许多场景中,RESTful体系结构中资源的正交使用极大地简化了服务的集成,否则就意味着服务接口的激增。另一个权衡是基于资源的架构给客户端增加了更多的复杂性,并增加了网络上的流量,而基于服务的架构增加了服务器的复杂性,并占用了它的内存和CPU资源。

有些人还提到了常见的HTTP服务或其他不满足RESTful体系结构或SOAP需求的服务。这些也可以分为基于服务的或基于资源的。它们的优点是实现起来更简单。只有当您知道您的服务永远不需要跨管理域集成时,才会使用这种方法,因为这种方法不会试图修复出现的集成问题。

这些类型的基于http的服务,特别是伪rest式服务仍然是最常见的类型。实现SOAP是复杂的,只有当你真的需要它时才应该使用它——例如,你需要一个跨域容易集成的服务,并且你希望它有一个服务接口。在某些情况下仍然需要这样做。真正的rest式服务也很难实现,尽管没有SOAP那么难。

恕我直言,你不能比较SOAP和REST,因为它们是两种不同的东西。

SOAP是一种协议,REST是一种软件体系结构模式。在互联网上有很多关于SOAP和REST的误解。

SOAP定义了基于XML的消息格式,支持web服务的应用程序使用该格式在internet上相互通信。为了做到这一点,应用程序需要事先了解消息契约、数据类型等。

REST表示来自URL的服务器的状态(作为资源)。它是无状态的,客户端不应该有超出超媒体理解范围的与服务器交互的先验知识。

火休息

RESTful API是最著名的API类型。REST代表具象状态传输。

REST api是遵循标准化原则、属性和约束的api。

您可以使用HTTP谓词访问REST API中的资源。

REST api运行在一个简单的请求/响应系统上。您可以使用以下HTTP方法发送请求:

得到 帖子 把 补丁 删除 跟踪 选项 连接 头

下面是最常见的HTTP动词

GET(读取现有数据) POST(创建一个新的响应或数据) PATCH(更新数据) DELETE(删除数据)

客户机可以使用后跟端点的HTTP谓词发出请求。

端点(或路由)是您请求的URL。路径决定了您请求的资源。

当您向端点发送请求时,它将响应相关数据,这些数据通常格式化为JSON、XML、纯文本、图像、HTML等。

REST api还可以设计为许多返回不同类型数据的不同端点。使用REST API访问多个端点需要各种API调用。

一个实际的RESTful API遵循以下五个约束:

客户机-服务器体系结构 客户端向服务器请求数据,不需要第三方解释。 无国籍 无状态意味着每个HTTP请求都在完全隔离的情况下发生。每个请求都包含服务该请求所需的信息。服务器从不依赖以前请求的信息。没有国家。 缓存能力 响应可以显式或隐式地定义为可缓存或不可缓存,以提高可伸缩性和性能。例如,启用GET请求的缓存可以改善资源数据请求的响应时间。 分层 API体系结构的不同层应该协同工作,创建易于更新或调整的可伸缩系统。 统一的接口 客户端和服务器之间的通信必须使用独立于两者的标准化语言进行。这提高了可伸缩性和灵活性。

REST api非常适合需要它的项目

灵活的 可伸缩的 快

SOAP火

SOAP是一种必要的协议,它帮助引入api的广泛使用。

SOAP是简单对象访问协议的首字母缩写。

SOAP是一种标准化协议,它依赖于XML来发出请求和接收响应。

尽管SOAP是基于XML的,SOAP协议仍然被广泛使用。

SOAP API将数据作为服务提供,通常在执行涉及多个API调用或应用程序的事务时使用,其中安全性是主要考虑因素。

SOAP最初是在1998年为Microsoft开发的,它提供了一种标准机制,用于集成internet上的服务,而不考虑操作系统、对象模型或编程语言。

SOAP中的“S”代表Simple(简单),这是有原因的——SOAP可以以更低的复杂性使用,因为它在应用程序层对事务、安全性和其他功能的编码要求更少。

SOAP有三个主要特征:

SOAP API的可扩展性 SOAP允许扩展引入更健壮的特性,如Windows服务器安全性、寻址等等。 SOAP API的中立性 SOAP能够在广泛的协议上操作,如UDP、JMS、SMTP、TCP和HTTP。可以操作。 SOAP API的独立性 SOAP API响应完全基于XML。因此SOAP api是独立于平台和语言的。

开发人员继续争论使用SOAP和REST的利弊。最适合你的项目的是符合你的需求的。

SOAP api仍然是优先考虑安全性的公司实体和政府组织的首选,尽管REST在很大程度上主导了web应用程序。 SOAP比REST更安全,因为它使用WS-Security与安全套接字层一起进行传输 SOAP还具有更出色的事务可靠性,这是SOAP在历史上一直受到银行业和其他大型实体青睐的另一个原因。