陈彦名
(中国移动通信集团设计院有限公司,北京 100080)
2000年,表述性状态转移(REpresentational State Transfer,REST)首 次 由Day Software公 司的首席科学家,Apach软件基金会的合作创始人Roy Thomas Fielding博士在他的博士论文中提出。REST不是标准,而是架构约束条件和原则,是一种设计风格[1]。
Amazon公司在2002年推出了AWS云计算服务,在2006年3月,在AWS中推出S3云存储服务,S3的接口就是REST风格的。S3获得了成功,促进了REST的普及[2]。而2008年前后的SOAP兴起带动了REST和传统Web服务方式(SOAP)的讨论,REST风格的API在互联网领域开始逐渐流行起来。2008年,JCP通过了JSR-311规范,提供了Java语言REST接口的参考规范, REST开始大势发展起来。
由于REST API非常适用于互联网对用户提供接口应用,因此近年来得到了快速的发展。REST API当前已经是互联网应用的主流API风格,国内外知名网站大多提供了开放的REST API供用户重开发。
互联网采用REST API的主要原因如下:
(1) 互联网中存在大量的资源;
(2) 各种资源可满足无状态特征;
(3) 大部分资源能通过URI来表达;
(4) 互联网水平扩展性极强;
(5) 用户可利用API返回的内容进行二次开发;
(6) 用户可随时、随地对内容资源进行访问;
(7) 通过HTTP协议保证用户使用的安全性。
目前,国外开放的REST API产品有Google产品,如Google翻译,Google BigQuery,Google眼镜等;Amazon.com提供的一系列REST API,比较著名的有Amazon云服务S3的API接口;Twitter。国内著名互联网平台开放的REST API有新浪微博;淘宝、腾讯、百度云、移动微博的REST API开放平台等。
TM Forum(全球电信管理论坛)是一个非盈利性组织,宗旨是领导服务供应商在通信、媒体和云服务市场提供最好的IT,帮助行业建立、交换和收益于数字服务,其他成员来自195个国家700组织和公司,很多成员都来自传统的电信运营商和设备商,最近也发起了云服务策略,期望行业在基于云服务的市场里克服一些阻力以实现云服务增长。该组织提出了REST API可用于“多云服务管理计划”中的“简单管理API”项目,多云服务即依靠多个云平台承载某项服务,在其简单管理API定义REST风格架构为云平台与云平台之间,云平台与终端之间提供一套完善且标准化的管理接口,从而实现跨平台的无缝服务。
REST 从资源的角度来观察整个网络,分布在各处的资源由URI确定,而客户端的应用通过URI来获取资源的表示方式。获得这些表徵致使这些应用程序转变了其状态。随着不断获取资源的表示方式,客户端应用不断地在转变着其状态,所谓表述性状态转移(REpresentational State Transfer)[3]。例如,在移动通信网络管理的统计指标中,“下载流量最多的前n位客户”和“使用4G流量最多的n位用户”在数据上可能是重叠或者完全相同的,但由于他们的表现形式不同,所以被归为不同的资源,每个资源对应一个唯一的资源标识符(Uniform Resource Identifier,URI)。因此,当网络管理员希望获取“下载流量最大的前n个用户”时,输入URI1获取相应的资源,当其希望得到“使用4G流量最多的n位用户”时,输入URI2获取相应的资源。由于URI的编写方式是独一无二的,因此资源也就具有唯一性,被用户使用唯一的途径进行访问,如图1所示。
图1 REST中资源的概念
REST采用URI对资源进行访问,每个URI都能够使用以下7种HTTP方法:GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS,对应增删改查等操作[1]。
而使用REST的另一个奇妙之处在于它的状态表述转移特点,如上所述,每个对象都被当作资源,当这些资源分布在不同的逻辑和物理区域时,依然能通过唯一的URI被访问。这些资源就是“状态”,这样,互联网就是一个巨大的状态机:每个网页是它的一个状态;URI是这些状态的表述方式;REST风格的应用则是从一个状态迁移到下一个状态的状态转移过程[1]。
最后,REST风格的无状态服务器特点使得在状态迁移的过程中,服务器不需要记录任何Session,所有的状态都通过URL的形式记录在了客户端。对资源的各种操作都不会改变资源标识。
大多数浏览器、HTTP服务器对于URL的长度都是有限制的,因此REST API一般不能传递过于复杂的参数。从响应速度来看,REST方式API服务端往往会采取多实例来实现处理能力的水平扩展,其负载均衡过程中,会加大一次请求的操作延时。但是目前可以利用缓存Cache来提高响应速度,通过“客户端”使用“缓存”下来的数据,减少“客户端”和“服务器”端的交互次数,从而达到提高网络性能的目的。
以Amazon S3提供的REST API为例,其设计目标是时延小于300 ms,而用户实测一般处于200 ms到300ms之间。由于Amazon同时提供了基于REST的和基于SOAP的Web服务, 因此他们做了两者速度的比较,据Amazon宣称,REST风格的Web服务比基于SOAP的快6倍。
从安全性角度来进行分析,目前没有专门针对REST的特定安全规范,但REST可以使用HTTP协议的所有安全方式 ,REST API基于HTTP协议,可提供如下安全方式:
(1) 用户名/口令(防止非授权访问);
(2) SSL通信(防止中间人攻击);
(3) 消息体摘要(防抵赖);
(4) 直接应用其它WEB安全协议、鉴权、认证。
以目前世界规模最大的亚马逊Web云计算服务为例,其基于REST方式的接口模式尚无安全问题出现,而目前,淘宝、新浪等都开放了REST接口,也尚无安全问题。当然,黑客技术也在不断发展,安全问题长期存在,REST技术也会不断前进,在竞争中不断发展起来。
目前,最流行的两种主流Webservice方式分别为基于SOAP的和基于REST的,从流行程度而言,SOAP流行已久,业界有很多较成熟的应用,而REST API为后起之秀,正在受到广泛关注。API聚合网站ProgrammableWeb对比了该网站上2008年和2010年各种不同的API协议部署量,2008年对REST关注度为60%,对SOAP的关注度为25%;到2010年,对REST的关注度为74%,对SOAP的关注度为15%。
从协议上而言,SOAP仅使用HTTP的POST方法传输封装好的XML文件,用UDDI进行服务注册和搜索,用WSDL描述如何使用SOAP来调用Web服务。REST直接将HTTP作为应用协议,也是HTTP协议设计的初衷。SOAP学习成本高,开发难度大,加之协议随着需求增加而不断扩充,其并发性能下降,但SOAP已经得到广泛的部署,且稳健性较好。REST目前主要针对大量的Web 2.0网站使用,高效以及简洁易用,处于发展趋势种。
图2为REST和SOAP的对比图,分别从风格、定义、资源、URI、数据响应模型等多方面对这两种方式进行了对比,各有各的优势,只是REST的易扩展性符合了Web 2.0的发展,也最佳的匹配了目前云计算的发展方向,因此越来越得到设计者们的认可。
图2 REST和SOAP技术对比图
根据REST适用场景,可以分析REST在移动通信网络管理中的应用场景。一是适用于第三方集成商做二次开发,例如目前互联网开放API多被用户(第三方)利用来进行二次开发,二是REST API非常适合云计算类环境。这是因为Web应用程序最重要的 REST原则是,客户端和服务器之间的交互在请求之间是无状态的;从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启,客户端不会得到通知,无状态请求可以由任何可用服务器回答;客户端可以缓存数据以改进性能。因此,我们可以分析在移动通信网络管理中,REST能提供如下几种应用场景。
根据REST的特点,针对非实时性、扩展性要求较高的应用,可建议采用REST API接口方式。而在大数据时代,移动通信的用户数和用量越来越庞大,少量存储设备已经不能很好的满足现网需求,并且,网络容量的扩张也往往超出预想,如性能管理系统由于存储、处理、上报海量的性能数据,要求时延较小、可扩展性强,可采用REST API进行接口实现,完成各项合适的功能,例如号码跟踪、投诉/故障查询、用户记录钻取查询等功能,见表1所示。
表1 性能管理系统内部建议REST API举例
在移动通信网络管理中,不同管理系统模块之间也经常性存在数据和信息交互,例如,资源管理系统在执行网络资源调度或业务资源开通等作业时,就经常用到性能管理系统模块内的性能数据,而资源管理系统对实时性要求并不强烈,不需要在秒级范围内得到性能系统提供的数据,因此这两种模块间也可以采用REST API接口进行内容交互,如图3所示。但是,REST并不支持事件通知,不适用上报告警,因此,不适用于与告警模块的交互。目前,已经有部分厂家成功采用了REST API方式实现模块间的资源调用。
图3 移动通信网络管理模块间采用REST API方式进行交互
例如,在进行客服端、记账平台、采购、营销策略分析APP开发时,可以采用REST API方式进行(如图4所示),既保证了任何位置的数据都随时方便的被获取,又保证了提供这些APP应用的数据可以随时更替、变换、扩展。
图4 移动通信模块向外部提供应用时采用REST API方式
REST作为一种正在新兴发展的技术,正处在蓬勃向上的过程中,其优点很多,例如,该方式可以利用缓存Cache来提高响应速度,具有较好的水平扩展性,浏览器即可做客户端,简化软件开发的需求,相对于其他叠加的HTTP协议之上的机制,REST的软件依赖性更小,并且在软件技术演进中的长期的兼容性更好。这些优点这使得REST风格在对应云计算、大数据技术表现出了强有力的优势,在移动通信行业现阶段积极采用云计算模式进行架构和资源设计的情况下,在目前大数据的呼声越来越高涨的环境下,REST风格无疑是顺应这一趋势的最佳选择。
但是,任何事物都有两面性,REST的发展也受到了很大的约束,例如,对于老系统改造来说,全面切换到REST风格工作量巨大,并且REST不支持事件通知,使得实时告警等需求不能完成,需要通过客户端轮询来模拟事件通知。另外,目前的REST还缺少比较强力的参考实现,与其它Web技术比较,例如SOAP来说,也没有绝对的优势,要求使用者分场景、分需求的来进行技术选择。因此,在移动通信网络管理中采用该技术时,应该顺势而为且与其它技术一起结合取长补短,搜索和分析业界已有成功案例,最好是在新建系统中采用该技术,而不是大规模改造旧系统,由此带来的效益和性价比才能达到最好。
[1]Jim Webber, Savas Parastatidis, Ian Robinson.REST in practice[M].Carlifornia:O'Reilly Media, 2010:12.
[2]唐京伟.基于云计算的分布式存储技术[J].中国传媒科技, 2013(15):21.
[3]Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian.马国耀, 等, 译.SOA与REST:用REST构建企业级SOA解决方案[M].北京:人民邮电出版社, 2013:43-56.