说说REST和软件通信的历史

   什么是Rest?
     rest,即REST(Representational State Transfer 表述性状态转移)是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。

     REST特点:
     1. Rest是一种设计风格,不是一个标准。
     2. Rest通常使用HTTP,URI,XML,HTML等流行的协议和标准
     3. Rest是从资源的角度来观察网络的,而资源是由URI来指定的。
     4. Rest对资源的操作类型通常包括:获取,创建,删除和修改,这四种操作分别对应着HTTP协议请求的GET,POST,DELETE和PUT方法。
     5. 资源的表现形式可以为:XML,HTML,JSON的文本。
     6. Rest是服务端-客户端结构中的一种应用方法。
     7. Rest使用的是HTTP协议,因此是无状态的。

     接下来,我们来了解下为什么要Rest?要弄清楚这个问题首先要了解一下计算机软件之间通讯技术的发展历程。在计算机通讯中,TCP/IP协议是最为通用的标准协议,TCP是传输控制协议,IP是网际协议,但这两种协议都是非常原始的(RAW),TCP协议是传输层协议,而IP是网络层协议。通过TCP/IP的确能胜任将信息从一个计算机传递给另外一台。但大家都知道比较底层的东西,往往比较难于理解。因此一些应用层协议营运而生,最初的应用层协议有SMTP,POP3,FTP,HTTP等,时至今日,大家每天使用最多的仍然是这些老牌应用协议。但这些协议同时都是有应用条件的。

RMI(remote method invocation,面向对象的远程方法调用)
RPC(remote procedure call,远程过程调用)
SOAP(simple object access protoal,简单对象访问协议)
REST(representational state transfer,表达性状态转移)
以上都理解为调用远程方法的一些通信技术“风格”。

1.Tcp/Ip (socket,RMI)
     早些时候,程序员们为了让两个应用程序之间能够通讯,通常采用的是使用Socket的开发的TCP/IP通讯程序,并且都是自己定义数据格式规范,这种模式的优点是个性化,通常效率较高,但同时因为都各自为政,往往是开发了好多种程序,但每种都不一样,这对于爱偷懒的程序员来讲,真是杯具了呀!
     RMI就好比它是本地工作,采用tcp/ip协议,客户端直接调用服务端上的一些方法。优点是强类型,编译期可检查错误,缺点是只能基于JAVA语言,客户机与服务器紧耦合。

2.RPC
     一些程序员开始想到,如果调用远程的一个方法能够像调用本地方法一样,那就简化多了,于是RPC模式的通讯产生了. RPC使用C/S方式,采用http协议,发送请求到服务器,等待服务器返回结果。这个请求包括一个参数集和一个文本集,通常形成“classname.methodname”形式。优点是跨语言跨平台,C端、S端有更大的独立性,缺点是不支持对象,无法在编译器检查错误,只能在运行期检查。

3.SOAP
     之后为了标准化,跨平台又产生了基于SOAP协议的消息通讯模型。SOAP是在XML-RPC基础上,使用标准的XML描述了RPC的请求信息(URI/类/方法/参数/返回值)。因为XML-RPC只能使用有限的数据类型种类和一些简单的数据结构,SOAP能支持更多的类型和数据结构。优点是跨语言,非常适合异步通信和针对松耦合的C/S,缺点是必须做很多运行时检查。

4.REST
     但随着时间的推移和SOAP的推广情况,大家很快发现,其实世界上已经存在了一个最为开放,最为通用的应用协议,那就是HTTP,使用SOAP的确让进程间通讯变得简单易用,但并不是每个厂商都愿意将自己的老系统再升级为支持SOAP,而且SOAP的解析也并不是每种语言都内置支持,比如JS.而HTTP正好完美了解决了这个问题,那好吧,我们就设计一种使用HTTP协议来完成服务端-客户端通讯的方法吧,Rest应运而生。
     REST一般用来和SOAP做比较,它采用简单的URL方式来代替一个对象,优点是轻量,可读性较好,不需要其他类库支持,缺点是URL可能会很长,不容易解析。

 
REST与RPC风格之比较
 
     RPC(远程过程调用)的架构,是应用在基于XML-RPC(或者 RPC风格)的SOAP的Web服务中的。客户端发出命令,以使服务做出特定的操作。换句话说,RPC有动词的倾向。
     REST强调资源(名词)有统一的接口以此来对它们寻址,而RPC强调过程(动词)有统一的接口来激发它们。一个基于RPC的架构,动词数量是没有限制的。REST说,我们使用四个动词——非常熟悉,HTTP标准的GET、POST、PUT以及DELETE——来进行请求和响应,REST使用资源寻址来处理其可变性。

REST和SOAP风格之比较
     REST风格的Web服务依赖一套简单的“动词”,HTTP标准的GET、POST、PUT以及DELETE,把所有的复杂性都转移到了指定资源的“名词”中。与 REST 架构相比,SOAP 架构图明显不同的是:所有的 SOAP 消息发送都使用 HTTP POST 方法,并且所有 SOAP 消息的 URI 都是一样的,这是基于 SOAP 的 Web 服务的基本实践特征。
     在Web服务发展的初期,XML格式化消息的第一个主要用途是,应用于XML-RPC协议,其中RPC代表远程过程调用。在XML远程过程调用(XML-RPC)中,客户端发送一条特定消息,该消息中必须包括名称、运行服务的程序以及输入参数。相反, REST风格的请求却不关心正在运行的程序是什么,它仅仅请求命名资源。
     XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大,于是就出现了SOAP——其最初的定义是简单对象访问协议。之后,大家逐渐意识到SOAP其实并不简单,而且也不需要必须使用面向对象语言,所以,现在人们只是沿用SOAP这个名称而已。
     XML-RPC只有简单的数据类型集,取而代之,SOAP是通过利用XML Schema的不断发展来定义数据类型的。同时,SOAP也能够利用XML 命名空间,这是XML-RPC所不需要的。如此一来,SOAP消息的开头部分就可以是任何类型的XML命名空间声明,其代价是在系统之间增加了更多的复杂性和不兼容性。
     另外,非常重要一点是,REST是需要请求HTTP的,与其相比,SOAP更具优势,SOAP消息可以由所有能够处理Unicode文本的传输方式来传送,很可惜,这一点通常不被人们所认可。事实是,由于HTTP穿透防火墙的便捷性,以及开发商们对Web非常熟悉,因此,人们还在继续强调着HTTP传输。
     随着计算机行业的觉醒,人们发现了基于XML的Web服务的商业潜力,于是,各家公司开始不断地发掘想法、观点、论据以及标准化尝试。W3C曾经设法以“Web服务活动”的名义来组织成果展,其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。

一个简单的REST举例
     假设我们希望一个Web服务暴露一部分目录,从这个目录中,用户将能够得到一些描述、图片、安装指令等等。为了得到数字“n1996-01”的描述,用户需要格式化一个GET请求,类似于下面的这个URL:
     http://company.com/catalog/description/n1996-01
     在处理这个请求时,“/catalog”将映射到一个服务中,之后,通过该服务对“description/n1996-01”进行解释,从而定位资源。在创建响应时,服务需要使用内容类型(Content-Type)的头文件来指定返回格式。在这种情况下,假定返回格式是HTML或者XML,客户端能够使用它来控制页面的布局。如果要得到图片,那么这个请求将对“/catalog/picture/n1996-01”进行寻址,返回的响应将是图片内容类型(Content-Type)。
 
REST风格web service和SOAPweb service的选择    
 
以下从成熟度,效率和易用性,安全性三方面讲如何选择使用这两种风格:
     成熟度(总的来说SOAP在成熟度上优于REST)

     SOAP虽然发展到现在已经脱离了初衷,但是对于异构环境服务发布和调用,以及厂商的支持都已经达到了较为成熟的情况。不同平台,开发语言之间通过SOAP来交互的web service都能够较好的互通(在部分复杂和特殊的参数和返回对象解析上,协议没有作很细致的规定,导致还是需要作部分修正)
     REST国外很多大网站都发布了自己的开发API,很多都提供了SOAP和REST两种Web Service,根据调查部分网站的REST风格的使用情况要高于SOAP。但是由于REST只是一种基于Http协议实现资源操作的思想,因此各个网站的REST实现都自有一套,在后面会讲诉各个大网站的REST API的风格。也正是因为这种各自实现的情况,在性能和可用性上会大大高于SOAP发布的web service,但统一通用方面远远不及SOAP。由于这些大网站的SP往往专注于此网站的API开发,因此通用性要求不高。
     由于没有类似于SOAP的权威性协议作为规范,REST实现的各种协议仅仅只能算是私有协议,当然需要遵循REST的思想,但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。

     效率和易用性(REST更胜一筹)

     SOAP协议对于消息体和消息头都有定义,同时消息头的可扩展性为各种互联网的标准提供了扩展的基础,WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容,导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。
     REST被人们的重视,其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计,同时也最大限度的利用了Http最初的应用协议设计理念。同时,在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式,除了传统的xml作为数据承载,还有(JSON,RSS,ATOM)等形式,这对很多网站前端开发人员来说就能够很好的mashup各种资源信息。

     安全性:
     这点其实可以放入到成熟度中,不过在当前的互联网应用和平台开发设计过程中,安全已经被提到了很高的高度,特别是作为外部接口给第三方调用,安全性可能会高过业务逻辑本身。
     SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的,当前已经得到了各个厂商的支持,.net ,php ,java 都已经对其有了很好的支持(虽然在一些细节上还是有不兼容的问题,但是互通基本上是可以的)。
     REST没有任何规范对于安全方面作说明,同时现在开放REST风格API的网站主要分成两种,一种是自定义了安全信息封装在消息中(其实这和SOAP没有什么区别),另外一种就是靠硬件SSL来保障,但是这只能够保证点到点的安全,如果是需要多点传输的话SSL就无能为力了。安全这块其实也是一个很大的问题,今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO,其实是直接采用了XML-Security和XML-Signature,效率看起来也不是很高。未来REST规范化和通用化过程中的安全是否也会采用这两种规范,是未知的,但是加入的越多,REST失去它高效性的优势越多。
 
 
     具体选择举例:
     在开发人员的意识里,对于Web服务的开发而言,REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此之外,现在,有许多集成开发环境能够在现有代码的基础上,依据接口方法自动生成SOAP。如果你需要使用WSDL来发布你的服务,或者你需要一些安全功能如消息签名和加密,那么,SOAP能够确保消息的安全性。另一方面,如果你希望使用简单接口来公布一些信息,而不需要繁琐的处理过程,那么,REST也许是最佳选择。
     假如我们要通讯的两个应用程序都是同一个架构的,比如都是.Net Application,或者都是Java Application,或者二者是其他对SOAP支持较好的程序,那么建议使用Soap形式来实现通讯,但如果服务的客户有使用浏览器调用服务,有使用js调用服务的需求,那么最好服务最好还是设计成Rest风格的。也就是说现阶段其实Rest的开放性,通用性都要优于SOAP.

知识共享许可协议
《说说REST和软件通信的历史》常伟华 创作。
采用 知识共享 署名-相同方式共享 3.0 中国大陆 许可协议进行许可。
  • 多说评论
  • 签名
  • 新浪微博
  • 默认评论
  • Tab Header 5

0 条评论 / 点击此处发表评论

Tab Content 5

开发技术


开发平台和工具

sitemap     174.31ms