我已经阅读了有关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更加标准化(例如:安全性)。
那么,我在这些方面是否正确?
Answers:
不幸的是,关于REST有很多误解和误解。@cmd不仅反映您的问题和答案,而且反映与Stack Overflow上的主题相关的大多数问题和答案。
SOAP和REST无法直接进行比较,因为第一个是协议(或至少是协议),第二个是体系结构样式。这可能是引起混乱的根源之一,因为人们倾向于将REST以外的任何HTTP API称为SOAP。
稍作努力并尝试建立比较,SOAP和REST之间的主要区别在于客户端和服务器实现之间的耦合程度。SOAP客户端的工作方式类似于自定义桌面应用程序,与服务器紧密耦合。客户端和服务器之间存在严格的合同,如果任何一方更改任何内容,一切都会中断。在进行任何更改后,您需要不断更新,但更容易确定是否遵守合同。
REST客户端更像是浏览器。这是一个通用客户端,知道如何使用协议和标准化方法,并且应用程序必须适合其中。您不会通过创建其他方法来违反协议标准,而是可以使用标准方法并在您的媒体类型上使用它们来创建操作。如果做得正确,耦合度就会降低,并且可以更优雅地处理更改。除了入口点和媒体类型之外,客户端应该以对API零知识的方式进入REST服务。在SOAP中,客户端需要有关将要使用的所有内容的先前知识,或者甚至不会开始交互。此外,REST客户端可以通过服务器本身提供的按需代码进行扩展,
我认为这些是了解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 OPS例如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表象小号大老牛逼转让(BOT))
RE表象小号大老对象是牛逼 ransferred是REST,即我们不会发送对象,我们发送对象的状态。REST是一种建筑风格。它没有定义很多标准,例如SOAP。REST用于通过互联网公开公共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
对于/user/1234.json
GET而言,/user/1234.xml
对于GET对于GET)。为什么要使用SOAP?
休息和肥皂之间的区别
肥皂
休息
有关更多详细信息,请参见此处
首先:正式,正确的问题将是
web services + WSDL + SOAP
VSREST
。因为尽管松散地使用了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
和体内的IDREST方法对事物的看法不同。URL不应代表动作,而应代表事物(在REST术语中称为资源)。由于HTTP协议(我们已经在使用)支持动词,因此请使用这些动词来指定对事物执行什么动作。
因此,使用REST方法,可以在URL上找到12号客户myapp/customers/12
。要查看客户数据,请使用GET请求命中URL。要删除它,请使用带有DELETE动词的相同 URL。要再次更新它,请使用带有POST动词的相同 URL,并在请求正文中添加新内容。
有关必须满足的服务才能被视为真正的RESTful的更多详细信息,请参阅Richardson成熟度模型。本文提供了示例,并且更重要的是,解释了为什么(所谓的)SOAP服务是0级REST服务(尽管0级意味着对该模型的依从性较低,这不是令人反感的,并且仍然有用)在许多情况下)。
REST
是不是Web服务?那是什么JAX-RS
?
在许多答案中已经涵盖的许多其他问题中,我要强调的是SOAP可以定义合同,WSDL,WSDL定义支持的操作,复杂类型等。SOAP面向操作,而REST面向资源。就个人而言,我会选择SOAP来实现内部企业应用程序之间的复杂接口,而选择REST来实现与外界的公共,更简单,无状态的接口。