我读过关于SOAP和REST作为web服务通信协议的区别的文章,但是我认为REST相对于SOAP的最大优势是:
REST更加动态,不需要创建和更新UDDI(通用描述、发现和集成)。 REST不仅限于XML格式。RESTful web服务可以发送纯文本/JSON/XML。
但是SOAP更加标准化(例如:安全性)。
那么,这些点我说对了吗?
我读过关于SOAP和REST作为web服务通信协议的区别的文章,但是我认为REST相对于SOAP的最大优势是:
REST更加动态,不需要创建和更新UDDI(通用描述、发现和集成)。 REST不仅限于XML格式。RESTful web服务可以发送纯文本/JSON/XML。
但是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级意味着对该模型的低遵从性,但它并不令人反感,并且在许多情况下仍然有用)。
其他回答
在众多答案中已经涉及的许多问题中,我将强调SOAP允许定义契约、WSDL(定义所支持的操作)、复杂类型等。 SOAP面向操作,而REST面向资源。 就我个人而言,对于企业内部应用程序之间的复杂接口,我会选择SOAP,而对于与外部世界的公共的、更简单的、无状态的接口,我会选择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,即我们不发送对象,我们发送对象的状态。 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
很多答案完全忘记了超媒体控件(HATEOAS),这是REST的基础。其他一些人也提到了这个问题,但并没有很好地解释它。
本文将解释这两个概念之间的区别,而不涉及具体SOAP特性的细节。
火休息
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在历史上一直受到银行业和其他大型实体青睐的另一个原因。