我读过关于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更加标准化(例如:安全性)。
那么,这些点我说对了吗?
当前回答
在众多答案中已经涉及的许多问题中,我将强调SOAP允许定义契约、WSDL(定义所支持的操作)、复杂类型等。 SOAP面向操作,而REST面向资源。 就我个人而言,对于企业内部应用程序之间的复杂接口,我会选择SOAP,而对于与外部世界的公共的、更简单的、无状态的接口,我会选择REST。
其他回答
很多答案完全忘记了超媒体控件(HATEOAS),这是REST的基础。其他一些人也提到了这个问题,但并没有很好地解释它。
本文将解释这两个概念之间的区别,而不涉及具体SOAP特性的细节。
什么是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时经常犯的一个错误是把它看作是“带有url的web服务”——把REST看作是另一种远程过程调用(RPC)机制,就像SOAP一样,但是通过纯HTTP url调用,没有SOAP庞大的XML名称空间。
相反,REST与RPC没有什么关系。RPC是面向服务的,关注动作和动词,而REST是面向资源的,强调组成应用程序的事物和名词。
REST vs SOAP不是要问的正确问题。
REST与SOAP不同,它不是一个协议。
REST是一种架构风格,是一种针对基于网络的软件架构的设计。
REST概念被称为资源。资源的表示必须是无状态的。它通过某种媒体类型来表示。媒体类型的一些例子包括XML、JSON和RDF。资源由组件操作。组件通过标准的统一接口请求和操作资源。在HTTP的情况下,这个接口由标准的HTTP操作组成,例如GET, PUT, POST, DELETE。
@Abdulaziz的问题确实说明了REST和HTTP经常同时使用的事实。这主要是由于HTTP的简单性及其与RESTful原则的非常自然的映射。
REST基本原则
客户端和服务器之间的通信
客户机-服务器体系结构具有非常明显的关注点分离。所有以RESTful风格构建的应用程序原则上也必须是客户机-服务器。
无状态的
对服务器的每个客户机请求都要求完全表示其状态。服务器必须能够在不使用任何服务器上下文或服务器会话状态的情况下完全理解客户端请求。因此,所有的状态都必须保存在客户机上。
缓存
可以使用缓存约束,从而将响应数据标记为可缓存或不可缓存。任何标记为可缓存的数据都可以被重用作为对相同后续请求的响应。
统一的接口
所有组件必须通过一个统一的接口进行交互。因为所有组件的交互都是通过这个接口进行的,所以与不同服务的交互非常简单。界面是一样的!这也意味着可以孤立地进行实现更改。这些变化不会影响基本组件的交互,因为统一的接口总是不变的。一个缺点是你被界面束缚住了。如果通过更改接口可以为特定服务提供优化,那么您就不走运了,因为REST禁止这样做。然而,从好的方面来看,REST是为web优化的,因此REST在HTTP上非常流行!
上述概念代表了REST的定义特征,并将REST体系结构与其他体系结构(如web服务)区分开来。值得注意的是,REST服务是web服务,但web服务不一定是REST服务。
请参阅REST设计原则的博客文章,了解更多关于REST和上述要点的详细信息。
编辑:根据评论更新内容
尽管SOAP和REST在HTTP协议上有相似之处,但SOAP是一组比REST更严格的消息传递模式。SOAP中的规则是相关的,因为没有它们我们就无法实现任何程度的标准化。REST作为一种体系结构风格不需要处理,而且本质上更通用。本着信息交换的精神,SOAP和REST都依赖于公认的法律,每个人都决定遵守这些法律。 SOAP和REST的选择取决于所使用的编程语言、所使用的环境和规范。