RESTful架构风格及其演变与发展
2020-06-03于洋
于洋
摘 要: RESTful架构风格已经提出将近20年,在移动互联网和微服务大潮下,RESTful架构风格服务已经成为提供web服务的最主流技术,经过多年的应用和沉淀,该架构风格已经成熟稳定,而对当前阶段的RESTful架构风格进行系统性梳理和论述的文档并不多,文章从RESTful架构风格的特点、演变和兴衰等角度,对该架构风格进行综合性阐述。
关键词: REST; RESTful架構风格; 微服务; 架构
中图分类号:TP399 文献标识码:A 文章编号:1006-8228(2020)04-10-04
Review of RESTful architecture style and its evolution
Yu Yang
(Power China Huadong Engineering Corporation Limited, Hangzhou, Zhejiang 310014, China)
Abstract: RESTful architecture has been put forward for almost 20 years, and under the tendency of mobile Internet and micro service, RESTful services have become the most popular technology in Web service. After years of application, this architecture has been mature and stable, but there are very few papers discuss the current RESTful architecture systematically. This paper will make a comprehensive demonstration of RESTful architecture style, from the aspect of its feature, evolution and its rise and fall.
Key words: REST; REST architecture style; micro service; architecture
0 引言
在移动互联网的大潮下,移动端的开发需求越来越多,Web端的开发也逐渐流行起前后端分离的架构,这些都要求后台服务采用RESTful架构风格的API,如果开发者对RESTful架构风格不甚了解,开发出的RESTful API总会貌合神离,既让开发者无法提供规范的Web服务,也会让服务消费者困惑。现在RESTful架构风格已经提出将近20年,经过多年应用和沉淀,该架构风格已经成熟稳定,有必要对此架构风格进行系统性梳理,以便让开发者快速达成共识,提高协作效率。
1 RESTful架构风格概述
RESTful架构风格最初由Roy T. Fielding(HTTP/1.1协议专家组负责人)在其2000年的博士学位论文中提出[1]。HTTP就是该架构风格的一个典型应用。从其诞生之日开始,就因其可扩展性和简单性受到越来越多的架构师和开发者的青睐。一方面,随着云计算和移动计算的兴起,许多企业愿意在互联网上共享自己的数据、功能;另一方面,在企业中,RESTful API(也称RESTful Web服务)逐渐超越SOAP成为实现SOA的重要手段之一。时至今日,RESTful架构风格已成为企业级服务的标配。
REST即Representational State Transfer的缩写,可译为“表现层状态转化”。REST最大的几个特点为:资源、统一接口、URI和无状态。
1.1 RESTful架构风格的特点
1.1.1 资源
所谓“资源”,即网络上的一个实体,或网络上的一个具体信息[2]。资源通过某种载体承载内容,文本可以用txt或HTML、XML等标记型文本格式表现,其他资源可以采用二进制格式。
与资源相对应的是数据,数据(尤其是数据库)是一种更抽象的、对计算机更高效和友好的信息表现形式,是面向计算机抽象的逻辑模型。
资源和数据关系如图1所示。
1.1.2 统一接口
RESTful架构风格规定,数据的基本操作,即CRUD(create,read,update和delete,即数据的增删查改)操作,分别对应HTTP方法,统一了数据操作的接口,仅通过HTTP方法,即可完成对数据的所有增删查改工作[3]。
GET(SELECT):从服务器取出资源(一项或多项)。
POST(CREATE):在服务器新建一个资源。
PUT(UPDATE):在服务器更新资源(客户端提供完整资源数据)。
PATCH(UPDATE):在服务器更新资源(客户端提供需要修改的资源数据)。
DELETE(DELETE):从服务器删除资源。
1.1.3 URI
URI即统一资源定位符,RESTful架构风格要求用URI指向资源,每个URI对应一个特定的资源,一个资源可以有一个或多个URI与之对应。要获取这个资源,访问其URI即可,URI就是资源的地址或识别符。在Web开发中,URI通常为URL。
1.1.4 无状态
所谓无状态的,即所有的资源,都可以通过URI定位,且这个定位与其他资源无关,不会因为其他资源的变化而改变。与无状态相对的是有状态,二者的区别,主要在于操作资源时,是否依赖基于状态的上下文背景。例如查询员工工资的应用场景,在有状态的系统中,查询工资需要登录系统,进入查询工资的页面,再发起工资查询请求,以获取工资的金额,由于查询工资的每一步操作都依赖于前一步操作,只要前置操作不成功,后续操作就无法执行,因此,这类系统是有状态的;而在无状态的系统中,输入一个url即可得到指定员工的工资信息,没有前置操作需要依赖,这种场景即为无状态。
在无状态的系统中,资源均有URI 与之对应,对资源的操作通过统一的HTTP接口、基于HTTP动词来响应,这极大降低了RESTful API的学习成本,也使得RESTful架构风格成为一种与开发语言无关、兼容异构系统的架构风格。
1.2 RESTful架构风格的鉴权机制
1.2.1 认证机制
由于RESTful架构風格的系统是无状态的,用户认证尤为重要。例如上文提到的员工工资,是一个隐私资源,只有员工本人或其他少数有权限的人有权访问,禁止用户随意查看。RESTful架构风格的系统如果不通过认证机制对资源做限制,所有资源将以公开方式暴露出来,既不合理,也不安全。
认证机制通常是一种独立的、通用的公共组件,不属于RESTful架构风格,但却是RESTful风格系统的基本组成部分,常用的认证机制包括 session auth(即通过用户名密码登录),basic auth,token auth和OAuth[4],在RESTfulAPI开发中常用的认证机制为后三者,随着RESTfulAPI的广泛应用,以及OAuth的严谨性和安全性,现在OAuth已成为RESTful架构风格中最常用的认证机制,和RESTful架构风格一起,成为企业级服务的标配。
1.2.2 权限机制
在业务系统开发实践中,通过认证机制确认资源的请求者往往只是RESTful API 鉴权的第一步,接下来还要确认请求者是否被许可使用、修改、删除或创建资源,这需要使用系统的权限机制。权限机制通常与系统的业务逻辑绑定,因此权限机制在每个系统中各自实现,基于用户和角色的权限机制具备一定的通用性,如果涉及到对象级的权限机制,每个系统各不相同。
2 RESTful架构风格的演变
2.1 本真REST和hybrid风格
在RESTful架构风格兴起之初,存在本真REST和hybrid风格之分。本真REST即上文阐述的RESTful架构风格,具备上述的4个特点,是真正意义上的RESTful风格;而hybrid风格,是最初的一些开发者出于对REST的误解,或者只是借鉴了RESTful的一些优点,开发的具备一部分RESTful风格的特点服务。
Hybrid风格的特色是,基于HTTP通信协议,使用GET方法获取资源,用POST方法实现资源的创建、修改和删除,因此对于获取资源的API,hybrid风格和本真REST并无二致,但由于它没有采用REST规定的HTTP动词进行资源的创建、修改和删除,因此从本质上讲,hybrid风格并非RESTful架构风格。Hybrid风格之所以存在,抛弃误解的因素,最主要的原因是对传统RPC风格服务的改造。因此,开发RESTful 服务如果没有历史包袱,就不建议使用hybrid风格。
2.2 现在的RESTful架构风格
随着RESTful架构风格的应用越来越普及,开发者也逐渐发现本真REST潜在的问题。由于本真REST要求用HTTP动词来实现和开放资源的基本操作(即数据创建、获取、更新和删除操作),并以此组合出资源的在实际应用场景中的具体业务逻辑,而CRUD不能有效表达所有的业务和操作。如批量删除资源操作,如果严格使用本真REST API,只有单个资源删除的API可用,批量删除时需要循环调用多次该API,这既低效,也对服务器不友好。合理的API应该是只对服务器做一次请求,调用一个API实现批量删除,在RESTful架构风格下实现该需求,只能采用变通的方法:
⑴ 对于少量数据或有规律数据的批量删除,可以设计一个API指向资源集,提供对资源集的过滤查询和删除服务,批量删除时请求该服务API,删除查询到的所有数据。这里涉及到由对资源删除操作到提供资源集删除服务的语义转换;
⑵ 对于大量无规律数据的批量删除,要变通删除语义,把对资源的批量删除视为资源批量修改的一种特殊情况,将DELETE方法转换为PUT方法后再进行资源批量操作;而这里不能将DELETE操作变通为POST操作,是由于RESTful架构风格要求操作的幂等性,PUT和DELETE均是幂等的,不幂等的POST操作只允许用于资源创建操作中,因此变通和语义转换,依然是在RESTful前提下进行的;
⑶ 所以,现在的RESTful架构风格,是在本真REST的基础上进行了扩展,对CRUD以外的操作,语义化并映射到相对合理的HTTP方法中,再进行API的开发,目前这些变通的API,没有统一的设计与实现标准。
3 RESTful架构风格的发展
3.1 REST的兴起与RPC的衰落
RESTful 架构风格初露头角之时,面向服务的架构(SOA)[5]已经兴起,当时开发SOA系统的技术基础为RPC技术[6],因此RPC风格API曾是Web Service的主流,其最初是基于XML-RPC协议(一个远程过程调用(remote procedure call,RPC)的分布式计算协议),后来渐渐被SOAP协议(简单对象访问协议(Simple Object Access Protocol))取代;RPC风格的服务,不仅可以用HTTP,还可以用TCP或其他通信协议。
RPC风格的API,受开发服务采用语言的束缚比较大,如.NET框架中,开发web service的传统方式是使用WCF,基于WCF开发的服务即RPC风格的服务,使用该服务的客户端通常要用C#来实现,如果使用python或其他语言,很难实现可以直接与服务通信客户端;进入移动互联网时代后,RPC风格的API很难在移动终端使用,而RESTful风格的服务,由于可以直接以json等文本格式为数据载体,以HTTP方法统一接口完成数据操作,客户端的开发不依赖于服务实现的技术,移动终端也可以轻松使用服务,这使得REST逐渐取代RPC成为开发web service的主流架构风格。
3.2 REST的成熟与RPC的再次兴起
在移动互联网的大潮下,RESTful架构风格在Web服务开发上的使用越来越普遍,自2014年微服务架构兴起后,RESTful架构风格的应用更是步入新的高峰,现在hybrid风格的服务已鲜有出现,本真REST+鉴权机制已成为企业级服务的共识。随着应用的普及,一方面RESTful风格日益成熟,演化成了上一章节介绍的模式;另一方面,由于RESTful架构风格只能采用HTTP协议,以文本格式作为数据的载体,其数据传输和网络通信的效率比RPC要差,这在业务量级巨大或性能要求高的系统中,为RPC的再次兴起带来了机会。虽然先前基于SOAP的RPC服务不再是主流,但RPC技术却一直在发展壮大,现在很多微服务框架,服务间的通信基于支持多种协议的RPC技术,也出现了gRPC等跨语言的RPC技术,这些均在当前微服务大潮下得到广泛应用。
现在,RESTful架构风格的服务是对外开放服务的主流技術,而在企业内部,甚至在一个系统的各个模块之间,已经不再是RESTful风格一家独大的局面,在实际的系统开发中,需要架构师基于现实的要求,选择合适的服务架构方案。
3.3 GraphQL的兴起
RESTful架构风格被广泛应用后,面对多种多样的业务场景,开发者开始意识到RESTful风格的API在获取资源时的便捷性和有效性有待改进。调用RESTfulAPI时,如果想获取多种类型的资源,开发者需要发起多个不同类型的资源请求,然后在客户端把资源组合成预期的格式,其有效性和便捷性均不及一个请求获取预期结果,而这却正是GraphQL具备的优势。GraphQL相当于在RESTfulAPI实践积累的基础上提出的一种新API风格,潜力巨大,目前还处于萌芽阶段。
RESTful架构风格发展至今已经历了近20个年头历练,而GraphQL是2015年左右由FaceBook提出了一种新的API载体,暂时还无法撼动RESTful架构风格在Web服务开发中的地位。
4 结束语
RESTful架构风格已经提出将近20年,在移动互联网和微服务大潮下,RESTful架构风格服务已经成为提供web服务的最主流技术,经过多年的应用和沉淀,该架构风格已经成熟稳定。虽然随着技术的发展和业务对技术需求的不断深入,RESTful架构风格在某些应用场景下也存在力有不逮的情况,但其应用场景和边界也日益清晰,目前尚未出现衰落的迹象。
目前,RESTful架构风格的服务依然是对外开放服务的主流技术,在企业内部,以及一个系统的各个模块之间,服务间的调用不再是RESTful风格一家独大的局面,初露头角的GraphQL,暂时也无法撼动RESTful架构风格在Web服务开发中的地位。
参考文献(References):
[1] Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures[D].Doctor,CALIFORNIA:UNIVERSITY OF CALIFORNIA,2000.
[2] Leonard Richardson/Sam Ruby.RESTful Web Services[M].California:O'Reilly Media,2007-5-18.
[3] SubbuAllamaraju. RESTful Web Services Cookbook中文版[M].电子工业出版社,2011.
[4] Ryan Boyd.Getting Started with OAuth 2.0[M].O'ReillyMedia,2012-2-29.
[5] 欧阳纯萍,李业荣.SOA面向服务体系结构的探讨[A].2006通信理论与技术新进展--第十一届全国青年通信学术会议论文集[C].中国通信学会,2006:766-771
[6] 姜虹.基于Web Services的RPC体系结构的研究[D].西安工业大学硕士学位论文,2008.