【REST系列】杂谈:REST发展初期的坎坷之路(技术环境分析以及REST&SOAP的冲突)

·  阅读 267

这是我参与8月更文挑战的第19天,活动详情查看:8月更文挑战


==建议先阅读==:详解REST和RESTful 主要参考资料


引言

REST 是Roy Thomas Fielding在他2000年的博士论文中提出的:==为分布式超媒体系统设计的REST架构风格== “这篇论文一经发表,就引起了关注,并且立即对互联网开发产生了深远的影响” - - 很多人这么说。在现在看来,REST确实体现出了举足轻重的地位,然而在其发展初期并没有很顺利。这主要是受以下两个因素的影响

1. 技术背景有限,论文阅读难度大

论文是==2000年==发表的,定义是==为分布式媒体系统设计的REST架构风格==

但是在2000年,互联网技术还比较有限。以"分布式"来说,2000年的分布式网络服务还不成熟,比较成熟的分布式架构--SOA 也是在2006年才开始逐渐被使用。为不影响阅读,另外整理了一篇分布式的发展历程:《简述分布式的定义、分类、技术发展历史进程

然后再来看一下Fielding的REST论文。读过论文的应该都知道,论文中都是理论设想,并没有给出具体的技术实现。 以下是REST论文译者李琨被采访的内容。采访于2007年。从中可以得到一些线索:"随着web技术的发展验证了REST的有效性",也印证了REST提出时并没有足够的技术去支撑理论 在这里插入图片描述

小结

一句话总结这个原因:技术背景有限、论文阅读难度大,使得能够足够支撑人们去 研究和使用REST 的条件不足


2. "成熟易用的SOAP"降低了REST的讨论热度

REST刚刚提出,晦涩难懂,需要时间去理解和实现

然而互联网的快速发展不等人,几乎在同一时间,简单易用的SOAP方案迅速被开发者所使用...

SOAP是什么

SOAP 是基于 XML 的简易通信协议,可基于多种协议来实现,但通常都是基于HTTP 简述1:SOAP 是用于访问网络服务的协议。 简述2:SOAP=HTTP+XML+RPC

SOAP(Simple Object Access Protocol,即简单对象访问协议)是用于Web服务(web service)交换数据的一种协议规范。

此标准由IBM、Microsoft、UserLand和DevelopMentor在1998年共同提出,并得到IBM、莲花(Lotus)、康柏(Compaq)等公司的支持,于2000年提交给万维网联盟(World Wide Web Consortium,W3C)

SOAP使用XML数据格式,以描述调用的远程过程、参数、返回值和出错信息等等。其实SOAP最早是针对RPC的一种解决方案,很轻量,同时作为应用协议可以基于多种传输协议来传递消息(HTTP/HTTPS、SMTP、TCP、UDP等)。 随着SOAP作为WebService的广泛应用,不断地增加附加的内容,使得现在开发人员觉得SOAP很重,使用门槛很高,而且随着需求的增长,又不得增加协议以支持安全性,这使SOAP变得异常庞大,背离了简单的初衷。在SOAP后续的发展过程中,WS-*一系列协议的制定,增加了SOAP的成熟度,也给SOAP增加了负担。

用一个简单的例子来说明 SOAP 使用过程:一个 SOAP 消息可以发送到一个具有 Web Service 功能的 Web 站点。例如,一个含有房价信息的数据库,消息的参数中标明这是一个查询消息,此站点将返回一个 XML 格式的信息,其中包含了查询结果 (价格,位置,特点,或者其他信息)。由于数据是用一种标准化的可分析的结构来传递的,所以可以直接被站点所利用。

SOAP和REST的冲突

我是从以下这篇论文首次得知,REST和SOAP产生了冲突。不过这里只简述了冲突的发展,并没有详细介绍冲突的原因 《REST深入剖析及实践策略研究》3.1.1论文原文。“SOAP首先被开发者所接受,但逐渐暴露出一系列的问题,同时REST的研究也开始有了成果,开发者开始倾向于REST” 在这里插入图片描述

造成SOAP与REST产生冲突的条件有两个:出发点相同但思路不同、时间吻合

冲突条件① 出发点相同但思路不同

这是从《REST与SOAP的冲突》 中找到的一个核心原因:==二者对web的理解不同==。它们都试图解决同样的问题:应该如何提供Web服务,使web架构更加规范化。但是SOAP和REST使用的技术和准则却大相径庭,甚至截然相反。

  • SOAP最初是作为一个RPC规范被提出来的。SOAP认为Web服务就是一组消息的交互,而Web只是用来承载这一交换过程的一个中间载体
  • REST认为Web本身就是一组资源的集合,Web服务本质上就是对资源的访问

所以在当时对解决"如何提供Web服务"这个问题上,有SOAP方案和REST方案。 SOAP方案因为更易上手、受大量知名公司推崇,所以被快速应用起来。而REST方案因为太晦涩难懂,没有足够的技术支撑,就没那么被看重

【附:REST为什么后来居上?、SOAP的缺点是什么?】

  • 虽然SOAP是协议规范,REST是架构风格。但是REST将web服务抽象为对资源的操作,并要求组件之间有统一的接口,这也就间接地影响和规范了协议的使用。Fielding作为HTTP协议的起草人之一,以及Apache Web服务器开发者,对Web的理解显然更深刻一些。
  • 事实也证明,REST对web的理解比SOAP更为有效:随着时间的发展,SOAP的缺点慢慢暴露出来。这主要体现于:虽然REST和SOAP理论上都没有指定必须使用HTTP,但实际上二者通常都是基于HTTP来实现的 (==推荐阅读==《SOAP、REST与HTTP的关系分析》)
    • SOAP是在HTTP的基础之上,基于xml来实现的,随着SOAP作为Web服务的广泛应用,以及需求的增长,又不断地增加附加的内容和支持安全性,这使得SOAP越来越重量化,传输效率低,背离了简单易用的初心
    • 而REST充分利用了HTTP的特性,使得其本身非常轻量,在使用过程中更加简单清晰

冲突条件② 时间吻合

SOAP在1998年由IBM、Microsoft、UserLand和DevelopMentor共同提出,并得到IBM等知名公司的支持,于2000年提交给万维网联盟(W3C)。 REST在2000年由Fielding在其论文中被提出

所以SOAP的提出比REST更早两年,当REST被提出时,SOAP已经被提交到了W3C,成为了一个标准协议

小结

一句话总结这个原因:几近同时出现的SOAP和REST,用不同的方式来解决了如何提供web服务。由于SOAP的成熟易用,并不像REST一样需要时间去研究和实现,所以在提出之际就快速发展,被广泛使用,从而降低了REST的讨论热度


总结

所以在当时看来

  • REST晦涩难懂,没有足够的时间研究、技术支撑
  • SOAP成熟有效,协议规范足够web服务使用、足够规范web架构

那么企业就更应该使用SOAP来进行开发,没有必要去琢磨REST。

直到SOAP的缺陷慢慢暴露,各种新技术也在慢慢出现,对REST的研究有了一系列的结果,REST才开始步入实战化。

  • 在协议方面,SOAP逐渐被RESTfulAPI(REST形式的API)取代
  • 在架构方面,REST伴随着SOA,为分布式架构指明了方向

    2008年的博文: Style of WebService: REST vs. SOAP 在这里插入图片描述

这,就是REST发展初期的坎坷之路


欢迎指正和补充

分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改