REST架构（精选三篇）
REST架构 篇1
互联网作为一个完整的整体,实现了不同领域不同行业不同Web信息系统之间的信息传输,然而不同的分布式信息系统之间如何协同完成一个完整的业务,是Web信息系统急需解决的问题。Web Service的出现,极大地解决了异构分布式系统相互协作与通信的难题,通过一套完整的系统框架与统一的功能服务与接口,能够为各个Web信息系统提供最基础的功能服务,从而突破了地理区域、系统功能等多方面的限制,使得不同的计算机信息管理系统之间无阻碍的无缝通信。随着时间的推移,传统的Web Service构架已经很难适应新的需求,以REST结构为基础的Web Service应运而生,它通过设计统一的接口,并将计算机的各种信息看作为资源,通过全局的资源标识,配备层次化的系统组件,从而为Web信息系统的开发、部署、运维提供了便利,极大地提升了系统开发的效率与质量,降低了开发成本与维护成本。此外,基于REST架构的Web Service开发的信息管理系统,提升了HTTP与URI的利用效率,与当前主流的EJB,CORBA或DCOM结构的分布式系统具有很强的兼容性,很容易实现系统之间的通信,加上接口设计简单、调用方便,REST已经逐渐成了当前主流的Web信息系统的Web Service框架设计的重要参考依据。
2 Web Service的关键技术
Web Service基于一系列专门的、开放的通信协议,能够很好地实现遵循相同Web Service系统之间的相互调用,从而实现了互联网的不同Web系统之间数据集成和分布式处理的基础,极大地促进了互联网的发展以及应用软件系统的应用。
Web Service实现的关键技术主要包括以下几个方面。第一种关键技术是XML技术,该技术为基于Web Service的信息管理系统设定了专门的结构化的语义定义与标记规范和语法,通过简单的、开放的描述式定义,为Web Service结构定义与Web信息系统的开发提供了统一的、易操作的数据表现形式,极大地推动了Web信息系统的发展。第二种关键技术是WSDL,该技术为Web Service提供了标准的描述语言,WSDL在描述Web Service服务接口时,主要采用消息、类型、端口等基本部分,而调用Web Service接口时,只需要对该接口的基本定义、依赖的协议以及相应的消息结构进行了解,即可实现对WSDL描述的Web Service接口的调用,实现其基本功能。第三种关键技术为SOAP技术,是简单对象访问协议,利用SOAP这一轻量级的简单访问协议,可以完成互联网的不同计算机之间使用XML语言描述的标准化、结构化数据信息的传输通信,从而实现两个异构平台的相互操作。SOAP技术的使用,能够迅速提高Web Service接口服务的速度,而且其在定义接口框架时,模块化程度非常高,没有包含传输语义,所以其与应用程序或其他服务接口之间的扩展方面也非常好,极大地促进了Web Service在Web系统中的应用。第四种关键技术为UDDI,该技术主要为Web Service提供宿主,通过专门的、统一的集成协议,实现Web Service接口的发布与查询的操作。
3 REST架构的Web Service
3.1 REST介绍
REST是在Browser/Server的基础上添加了另外3个规范性的组成,第一个为统一接口,第二个为分层系统,第三个为按需代码。
统一接口为REST定义了对系统资源进行操作统一的方法和链接入口,REST架构的核心就是资源,它将互联网中所有的可访问、操作的数据信息都看作资源进行处理,从而简化了REST对不同数据信息的处理方式和过程,也为REST的高度重用性以及不同分布式异构系统的高交互性奠定了基础。
分层系统的定义使得Web Service的定义和实现Web系统不同的层次之间具有良好的独立性,从而降低了系统层次依赖耦合性和复杂性,而良好的接口封装、应用功能实现等干扰性大大降低,从而为Web系统的可维护性、扩展性等奠定了良好的基础。
按需代码则是Web Service可选的要求,通过按需代码开发者可以在客户端的应用程序进行功能扩展,从而实现对客户需求的满足,从而使得系统更加人性化,提升其友好性。
3.2 REST的资源及其标识
REST架构的核心理念就是对互联网中的数据进行统一的资源式处理,即将各种互联网信息抽取成资源。互联网中,信息种类繁多,例如文本、数据、文档等文本信息,音频、视频等多媒体信息,天气服务、资源集合等其他信息,这些对于REST来说,都是资源。通过对具体的资源实体的抽取与映射,REST可以获取到互联网中的各种各样的信息。
REST对特定资源的映射是通过资源标识来定义和标识,而这个资源标识的命名必须具有唯一性和持续性。在Web Service中,对于资源进行标识的是URI,它是Web Service最基本的组成部分。因为REST对互联网的各个数据资源的标识具有唯一性,所以Web Service中对于不同的资源,其URI是唯一的。值得说明的是,URI的关联是将URI与资源之间的映射与对应,URI本身不会对资源进行操作,如果Web Service的接口服务想去访问互联网的资源,必须通过解析URI,而后去访问、操作相应资源,通过HTTP协议的POST,GET,DELETE,PUT等基本方法,将URI放置到HTTP请求报文中,便可实现对网络资源的查询、修改、添加、删除等基本操作,从而实现互联网中不同计算机之间的Web信息系统的数据操作。
在REST里面,HTTP的相应的操作被称之为方法信息,Web信息系统的终端用户通过GUI操作向服务器发送相应请求,此时的HTTP请求包含了网络资源的URI以及客户的增删改查的操作请求,这些操作就是方法信息,是REST结构下的Web服务操作方法。通过这些方法信息的识别,服务器能够很清楚地了解客户端的操作请求,从而对相应的资源进行标准化的操作。
3.3 Restlet的开发框架
为了能够较好地实现REST下的Web Service各个组成与操作,Restlet将REST,URI以及HTTP请求操作等分装成各种类,为使用者提供了良好的封装性、集成性和可扩展性,从而为使用Restlet框架的应用系统实现了Restful Web Service支持。Restlet框架的类层结构如图1所示。
图1中APPlication类是对REST各个资源进行管理的类定义和封装;Fliters类是实现过滤功能的类,其主要是在程序调用执行之前或之后来启动handle方法进行专门的处理;Router类是实现路由功能类的定义,是同时对多个Restlet对象进行处理的功能实现,其通过将各个Restlet对象的URI放置到对应的请求中来实现相应的处理。
4 结语
Web Service是为分布式计算机系统提供专门软件服务的一种技术,通过XML,WSDL,SOAP,UDDI等关键技术以及一系列的通信协议,能够很好地实现遵循相同Web Service系统之间的相互调用。REST架构的Web Service对互联网中的数据进行统一的资源式处理,将其通过资源提取,并以URI匹配的资源标识和HTTP操作请求为基础,来实现对互联网资源的操作,从而实现Web信息管理系统的基本功能。
摘要：文章主要针对表述性状态传递(Representational State Transfer,REST)架构的Web Service进行研究,首先介绍了Web Service的可扩展标记语言(Extensible Markup Language,XML),网络服务描述语言(Web Services Description Language,WSDL),简单对象访问协议(Simple Object Access Protocol,SOAP),通用描述、发现与集成服务(Universal Description Discovery and Integration,UDDI)等关键技术,而后对REST的Web Service的基本构成、统一资源标识符(Uniform Resource Identifier,URI)资源标识和HTTP操作方法进行研究,并以Restlet开源框架为例介绍了REST的Web Service接口服务,从而为Web信息系统提供接口服务。
关键词：REST,Web Service,资源标识,HTTP
参考文献
[1]俞黎敏.Web Services之REST风格架构设计[J].程序员,2010(11):26.
[2]史玉珍,刘玉坤,李哲秀.基于REST Web Services的图书联合目录研究与实现[J].计算机与数字工程,2012(7):128-130.
[3]王义荣,邬群勇,马亨冰.REST风格的地理信息Web服务研究[J].福建电脑,2010(1):73-74.
REST架构 篇2
随着网络技术的快速发展, 人们对于Web应用的需求不再局限于通过简单页面快速获取资讯, 对于Web应用的用户交互和用户体验都有了更高的要求。然而, 在传统的Web应用程序中, 客户端自身缺少缓存和逻辑处理能力, 无法给用户带来丰富的交互体验。而且客户端过分依赖服务器端的处理能力导致在大型的Web应用中, 服务器维护成本会越来越高。此外, 如何提高系统的可伸缩性以及如何充分利用HTTP协议建立统一接口从而降低开发复杂度都是当今Web应用程序开发中亟待解决的问题。
REST (Representational State Transfer) [1], 即表述性状态转移, 是一种面向资源的开发模式。其核心思想是将web应用中所有信息均可抽象为“资源”[2], 而所有操作也都是基于资源完成的。与面向Action开发模式不同的是, REST架构提出了基于“资源”操作的无状态性来保证系统可伸缩性。而且REST架构提出“分离关注点”的理念, 并约束客户端和服务器端应用统一接口进行必要通信, 使得客户端和服务器端实现松耦合, 从而达到了简化Web应用的整体架构, 降低通信负载以及开发复杂性的目的。
REST作为一组良好的设计原则广泛应用于Web应用程序开发过程中, 但是直到目前为止, 人们习惯于在开发过程中根据自身实际的开发条件有选择地应用部分REST的设计原则。本文旨在探讨一种通用的基于REST的Web应用架构参考模型, 该模型依赖于现有的HTTP协议, 有效发挥REST设计原则, 提炼出一组明确规范的最优实践步骤, 降低Web应用的开发成本, 保证遵循参考模型开发的Web应用具备良好的可扩展性和可伸缩性。
1 REST的架构设计
REST架构设计融合了多种基于网络架构设计, 强调网络应用的可伸缩性、接口的通用性、组件的独立部署以及减少交互延迟而提高性能。
REST架构设计中用到的网络基础架构设计包括客户-服务器设计、无状态设计、缓存设计, 除此之外, 它还加入了统一接口设计, 并将按需代码设计作为一个可选项。REST架构设计通过融合客户端-服务器设计, REST实现了用户接口和数据存储的分离, 同时简化了服务器组件, 改善了系统的可伸缩性;更重要的是, 这种分离允许组件间的独立进化, 支持多组织领域内的Web应用规模扩展的需求。在客户-服务器架构设计的基础上, 我们引入无状态设计从而改善了Web应用的可见性、可靠性和可伸缩性, 但也因为无法在服务器端保存上下文数据而增加在一系列请求中重复数据的发送次数, 降低了网络性能。为改善Web应用的网络效率, REST增加了缓存设计。统一接口设计是REST架构设计的核心特征, 它坚持Web应用组件之间要有统一的接口从而简化了Web应用的整体结构, 改善了交互的可见性, 促进了独立组件的可进化性。
REST架构设计[3]定义了现代优质Web应用架构的标准, 提出了五条重要的网络应用设计原则[4]。
标识所有资源
在Web的命名空间中, 标识资源意味着资源获得一个唯一全局的ID。对资源使用一致的命名规则的最大好处是Web应用可以在最大范围内有效地运行。
链接所有资源
在Web应用中, 被标识的资源需要使用链接进行指引。链接在所有资源都被标识的Web空间中提供了一种所有资源互联互通的途径。客户端可以通过服务器端提供的一组链接将Web应用从一个运行状态切换到另一个运行状态。
使用统一接口
如图1所示, 在传统Web开发中, Web应用会拥有许多种类的数据和面向数据的多种不同操作以及固定数量的运行实例。运行实例即为Web应用入口, 客户端通过实例访问Web应用。在REST架构设计中, 客户端访问应用的方式不变, 但Web应用拥有固定数量的操作 (GET、PUT、POST和DELETE) , 丰富的数据种类 (资源) 和多个程序入口。使用REST架构设计中统一操作接口的意义就在于使Web应用成为Web空间中的一部分, 使所有Web应用之间的交互融合更为通畅, 使对资源的操作更为简易便捷。
资源多重表示
在理想情况下, 资源表述应该使用标准的表示格式, 这样Web空间任意两个基于REST的Web应用可以实现自由交互。在很多实际情况中, 我们需要使用非标准资源表式构造较为封闭的Web小空间。在这种情形下, 跨越组织边界的Web应用之间可以通过HTTP提供的内容协商机制进行交互。
通信无状态性
REST架构设计的无状态通信原则并不是指Web应用不可以有中间状态, 而是强调服务器端不保存除单次请求外与客户端的通信会话上下文。REST架构设计要求会话状态保存在客户端抑或包含在资源访问请求中。在REST架构设计中, 由于服务器端的无状态约束, 服务提供方无需关注客户端的运行状态从而避免了大量客户端状态信息消耗服务器端资源的情况, Web应用的可伸缩性得到了改善。另外, Web应用的容错性也得到了提升, REST架构设计的通信无状态性为客户端屏蔽了服务器端的变化。在连续的访问请求中, 客户端并不依赖于同一台服务器, 即使在某次请求后, 原响应服务器失效了, 新服务器无需了解之前的会话状态即可响应客户端新的资源访问请求, 而客户端也不会察觉到响应服务器已发生变化。
2 基于REST的面向资源Web应用架构参考模型的结构描述
基于REST的面向资源[5]Web应用架构参考模型主要包括三个部分:服务提供方、用户代理方以及连接通信模块[6] (图2所示) 。
服务提供方运行于服务器端, 负责建立资源来源库, 以此为基础将服务数据和服务逻辑构建成资源, 向外公布资源信息说明服务内容;接受用户代理方的请求, 通过资源的形式向外提供服务内容。用户代理方运行于浏览器端, 负责与用户进行交互, 通过接收用户触发的事件, 向服务提供方申请相关资源信息, 将资源内容展示给用户。连接通信模块部署在用户代理方和服务提供方的两端, 双方通过连接模块进行资源数据表示的传输, 连接模块为上层提供抽象的资源访问接口, 隐藏通信机制的实现细节。
2.1 服务提供方
服务提供方使用三层结构的组织形式, 这三层自下而上分别对应的是数据持久层、资源构建层和发布解析层。服务提供方的层次结构如图3所示:
数据持久层负责与数据库管理系统之间的通信, 资源来源以数据库记录的形式存储于数据库中, 数据持久层为资源构建层提供资源来源。
资源构建层由若干元资源构建模块和若干数据表示生成模块共同组成。一个元资源对应一个元资源构建模块和多个数据表示生成模块。资源构建层给出某个元资源的定义, 在元资源构建模块中根据定义明确组成元资源的资源来源, 确定资源来源的使用规则, 比如直接选取单个资源来源的属性值作为元资源的属性值、选取多个资源来源的属性值形成元资源的属性值、或者使用资源来源的属性值进行判定选取判断结果作为元资源的属性值。资源构建层通过元资源构建模块整合资源来源, 创建元资源的抽象表示。在此基础上, 资源构建层可以通过对请求中资源表示类型参数的判断调用合适的数据表示生成模块, 将抽象形式的元资源转化为特定格式的数据文件。
请求解析模块和资源信息发布模块共同组成发布解析层。发布解析层通过请求解析模块对操作资源的请求进行预处理, 过滤对资源的无效请求。这些无效请求包括对未公开资源的访问请求、内含资源未开放操作的超越权限请求、要求提供的资源表示无法满足的请求。发布解析层会将合法请求传递到资源构建层中, 资源构建层使用元资源构建模块对请求进行响应。对于非法请求, 发布解析层会通过请求解析模块生成包含错误响应消息, 对拒绝请求的原因进行描述。发布解析层通过资源信息发布模块对外显示服务提供方的服务内容。资源构建层向发布解析层提供可生成元资源的列表以及它们的定义, 发布解析层在此基础上确定向外暴露的元资源列表, 并根据元资源定义确定对于暴露的元资源可进行的操作。资源信息发布模块对于服务内容的描述也为请求解析模块对于请求的预处理过程提供依据。
2.2 用户代理方
用户代理方采用类MVC的组织形式, 由展示器、资源配置器和资源池三部分组成。用户代理方的层次结构如图4所示。
展示器是使用者看到并与用户代理方进行交互的界面接口。展示器将页面元素划分为静态元素和动态元素, 使用者通过页面逻辑操控动态元素的变化。展示器通过视图模板定义了界面的静态框架和显示风格;另一方面, 展示器使用数据模块对状态资源进行了封装形成动态页面元素, 其中使用数据定义文件获取或者更改状态资源中的数据内容, 使用数据显示文件确定数据定义文件展示形式以及和使用者进行交互的方式。
资源配置器接受展示器发出的动态元素触发事件, 根据业务流程, 为展示器调配状态资源。资源配置器通过业务规则抽象模块将业务流程转化为元资源之间的关系集合。资源配置器使用状态资源生成模块接收展示器触发事件, 从资源池获取元资源对象, 从业务规则抽象模块获取元资源关系, 将两者相结合从而生成展示器所需要的状态资源。
资源池使用连接器从服务提供方获取元资源的特定格式表示, 通过元资源缓存模块将元资源的文件表示转化为元资源对象, 并对其进行管理。资源池采用“调用创建”的缓存策略, 当资源配置器第一次向资源池发出获取某个元资源对象请求, 资源池将该元资源的表示文件实例化缓存起来。
3 基于REST的面向资源Web应用架构参考模型的视图描述
本节将在前面一节对于参考模型结构描述的基础上, 从数据流视图角度进一步深入分析基于REST的面向资源Web应用架构参考模型, 并从功能视图的角度归纳基于REST的面向资源Web应用架构参考模型所具有的基本特性。
3.1 面向资源Web应用架构参考模型的数据流视图
本小节将从参考模型的数据书视图的角度, 即通过数据在参考模型中的流动路径[7], 进一步展示各组件之间的交互关系。
当用户通过浏览器进行操作时, 展示器会接收到输入事件, 如果输入信息有效, 展示器会将事件信息经由数据模块传入到资源配置器中的状态资源构建模块。状态资源构建模块会从事件信息中获取展示器需要的元资源信息, 并从业务规则抽象模块查询到和需要元资源有关的关系列表。之后, 状态资源构建模块会确定与输入事件匹配的状态资源需要的元资源列表, 将元资源的URI列表传入资源池。资源池根据URI信息首先判断是否在内存中已创建了元资源对象, 如果没有, 则接着在本地查找是否存在元资源的数据表示文件, 如果存在, 资源池将会根据数据表示文件创建元资源对象后, 将其返回给状态资源构建模块。状态资源构建模块将一个或多个元资源对象和与元资源有关的关系列表组合生成状态资源, 展示器中的数据模块会依此得到数据定义文件和数据显示文件, 浏览器会将动态数据文件和视图模板结合起来进行渲染, 向用户显示操作后的效果。
当资源池在本地未找到符合要求的元资源, 资源池会通过连接模块向服务提供方发出HTTP请求消息, 服务提供方的请求解析模块会通过资源信息发布模块生成的服务描述对请求进行有效性验证。如果没有通过验证, 请求解析模块会将描述验证失败信息传递到连接模块, 进而生成HTTP响应消息, 返回给用户代理方;如果通过了验证, 请求会被路由到合适的元资源构建模块, 元资源构建模块从数据持久层中获得资源来源进行整合, 并根据请求中的表示类型调用对应的数据表示生成模块得到特定格式的资源数据表示, 之后连接模块会将其封装为HTTP响应消息传送回用户代理方。 (如图5)
3.2 面向资源Web应用架构参考模型的功能视图
本小节将用户代理方和服务提供方作为一个有机整体, 阐述面向资源Web应用架构参考模型具备的两大功能可缓存和状态分离。
●可缓存
资源与统一资源定位符是一一对应的, 服务提供方将资源与URI进行绑定以服务描述的方式向外界发布, 用户代理方可以通过服务描述中的URI访问到相关的元资源。
参考模型使用两层缓存机制:内存中的元资源对象和本地的元资源缓存文件。
当资源配置器第一次配置某个状态资源时, 资源配置器会使用所需元资源的URI通过资源池向服务提供方发出请求, 收到响应后资源池会在本地创建相应的元资源表示文件, 进而生成元资源对象。当资源配置器再次使用具有相同URI的元资源时, 资源池会直接返回缓存中的元资源, 避免第二次与服务提供方通信, 节省带宽。
资源配置器还会将状态资源中的与元资源相关的URI传入资源池, 资源池会从服务提供方获取这些URI对应的元资源数据表示文件, 存放在本地。根据空间局部性原则, 用户在接下来的操作中很有可能需要这些URI对应的元资源, 这时, 由于在本地已经缓存了元资源数据表示文件, 用户代理方可以节省向服务提供方请求元资源的时间, 迅速地响应用户操作, 提升用户体验。
●状态分离
本参考模型通过将资源状态和应用状态分别保存在服务提供方和用户代理方实现了服务提供方的无状态性。这意味着对于服务提供方和用户代理方来说, 每个HTTP请求都是完全独立的, 当前的HTTP请求中包含了服务提供方实现用户代理方意图所需的全部信息, 服务提供方无需保存之前用户代理方的HTTP请求记录。
无状态性简化了服务提供方和用户代理方的交互过程, 实现了服务提供方和用户代理方的异步操作, 大大减少了异常出现的情况, 具有较高的可靠性。服务提供方无需耗费大量资源用于保存诸多用户提供方的运行状态, 无需判断当前HTTP请求与哪个用户提供方相关, 用户提供方无需担心响应超时后如
何重置状态, 只需要重新发送HTTP请求。
本参考模型中, 状态资源中包含有元资源以及指向相关资源的URL, 状态资源通过URL相互链接起来从而具有连通性。应用状态是一个状态资源的集合, 用户代理器通过状态资源中的元资源展示当前程序运行所处的应用状态, 并通过各个状态资源中的URL显示出在当前状态有哪些后续状态是可以进入的。用户代理器也可以通过在展示器中给出URL链接来引导状态资源的改变, 从而改变程序的应用状态。
4 面向资源Web应用架构参考模型的应用优势
这一节将综合前面两节讨论的内容, 讨论与传统的C/S和B/S的Web应用架构或Web服务架构相比, 采用该参考模型进行开发的优势, 以及该参考模型如何为Web应用带来较高的可扩展性和可伸缩性。
面向资源Web应用架构参考模型的应用优势[8]主要体现在以下几个方面:
1.参考模型的模块划分清晰, 耦合性低, 使得Web应用适合于迭代开发, 具有易开发性。参考模型采用MVC的设计模式规划用户代理方和服务提供方的结构, 将数据、业务逻辑和展示逻辑相分离。在此基础上, 参考模型采用分离关注点原则, 在用户代理方和服务提供方引入资源的概念, 将复杂的应用逻辑和服务逻辑分解为对状态资源和元资源的操作, 以元资源之间关系推动应用状态的转移。采用参考模型, 开发人员无需了解Web应用的所有业务逻辑, 可以以某个资源作为单元开发模块, 从纵向上逐一实现数据层、业务逻辑层和表示层。由于资源之间的关联性, 开发人员也容易实现单元模块的集成。
2.参考模型具有可扩展性和可伸缩性, 使得Web应用易维护性强。参考模型的可扩展性体现在两个方面。参考模型使用统一接口对资源进行操作, 当服务提供方的资源名称发生变化, 用户代理方无需更改应用逻辑, 只需要修改对应的URI内容;参考模型使用资源作为服务的最小单元, 资源之间相对独立, 当用户代理方有新的需求, 服务提供方无需更改已有的程序结构, 只需要添加新的资源。另一方面, 由于用户代理方和服务提供方具有层次结构, 每一层次相互独立, 通过接口进行交互, 每个层次的变化对其他层次的影响都比较小。参考模型服务提供方只保存资源状态, 具有无状态性。无状态性保证了各个http请求之间没有相互依赖, 极大地提高了Web应用的可伸缩性。当现有服务器无法满足请求处理需要, 只需要新增一台服务器, 因为无状态性, 服务提供方不需要在各台服务器之间协调工作, 将请求随机分配到所有服务器上便可以实现负载均衡。
3.参考模型可以实现Web应用的高效开发。参考模型采用MVC模式设计用户代理方和服务提供方, 使得开发人员之间的分工明确, 逻辑程序员专注于业务逻辑, 界面程序员将关注点放在表现形式上。参考模型以资源作为Web应用的开发单元, 可以更好地进行单元测试, 提高了Web应用的可验证性。
5 结论
本文针对目前Web应用开发过程存在的缺乏丰富用户体验、系统可伸缩性差以及无法充分利用HTTP统一接口优势等不足展开研究, 探索面向资源的新型Web应用开发模式, 提出面向资源Web应用架构参考模型。本文的关注点在于参考模型的结构视图、数据视图和功能视图, 忽略了参考模型的安全视图, 在下一步的研究中, 需要对面向资源Web应用架构参考模型的安全性进行全面深入的探讨。
参考文献
[1]Roy Thomas Fielding.Architectural Styles and the Design of Network-based Software Architectures[A].Dissertation submitted in partial satisfaction of the requirements for the degree of doctor of philosophy in Information and Computer Science, 2000.
[2]Leonard Richardson, Sam Ruby著.徐涵, 李红军, 胡伟译RESTful Web Services中文版[M].北京:电子工业出版社, 2008.
[3]Stefan Tilkov著, 徐涵译.解答有关REST的十点疑惑[OL].2008.http://www.infoq.com/cn/articles/tilkov-rest-doubts
[4]Stefan Tilkov著, 苑永凯译.深入浅出REST[OL].2007.http://www.infoq.com/cn/articles/rest-introduction
[5]Gregor Roth著, 马国耀译.Restful HTTP的实践[OL].2009.http://www.infoq.com/cn/articles/designing-restful-http-apps-roth
[6]李锟.REST与面向资源的Web开发[OL].2008.LI K.REST and resource-oriented Web development[OL].2008.http://www.docin.com/p-106805857.html
[7]李昂.REST架构工作流中间件设计与实现[J].计算机工程与设计, 2012, 33 (9) :3455-3464.LI A.Designing and Implementation of RESTful workflow middleware[J].Computer Engineering and Design, 2012, 33 (9) :3455-3464.
REST架构 篇3
共用态势图(COP)简称态势图,是军事指挥部门了解战场态势的主要手段,是战场态势感知系统、服务和应用的关键,服务于共用战场态势信息仓库,能更快、更好地引导同步规划和执行决策。与商业、工业部门的许多信息管理系统类似,态势图建立在管理数据资产的观点上[1]。随着多系统间数据共享需求,Web服务成为较好的提供数据方式。Web服务方便各种平台、语言和技术开发的分布式计算系统,能够相互协作和交互。Web服务返回的是与平台无关的xml文档,可以支持异构系统,降低服务器端和客户端的耦合[2],能够满足不同系统对态势数据的需求。同一系统中,能够方便进行二三维一体化展现,更好地提供对态势数据的感知。三维视图更接近现实场景,更直观表达战场态势信息。利用已有的二维态势数据软件成果,扩展设计二三维一体化的态势数据服务系统,能够满足不同显示场景下的战场数据展现。
1 REST服务优点
从面向过程到面向对象编程,再到面向服务架构,通过服务所暴露的接口,实现网络环境下的业务集成和互操作,不受平台环境限制,并易于重复使用[3]。目前主流的Web service实现包括基于简单对象访问协议(Simple Object access protocol SOAP)的Web Service和REST架构的Web Service。SOAP架构的Web Service要求客户端在HTTP信封里放入一个SOAP信封。SOAP信封可以包含一个对RPC(Remote Procedure Call)调用的描述,即方法信息和作用域信息都在SOAP信封里;而REST架构的Web服务方法信息都在HTTP里[5],作用域信息在URI里。所有REST服务共用HTTP的标准词汇[5]。
REST架构的态势数据服务优势:①支持多形态、多语言场景和系统环境的访问和调用;②数据量较小,对于移动终端等客户端设备,可以较快处理,节省移动设备的有限资源;③易实现安全策略。安全控制的常见方法是:所有从客户端发出的HTTP请求都经过代理服务器,代理服务器可以制定安全策略对某些请求拒绝,而REST架构就是利用HTTP本身的方法信息作为它的动作信息。对于态势数据管理服务,REST服务结构有利于与外部安全控制服务对接,实现访问控制。
2 二三维一体化特点
态势数据主要依托地理信息系统GIS(Geographic Information System)展现,而目前GIS已经可以较好地支持二三维一体化。GIS的二三维一体化技术,是GIS基于空间共享思想在应用层次的扩展。用户基于平台获得数据,可以搭建二维或三维应用,二维与三维在数据上是一体的,在应用上是一体的,在展现上也是一体的[4]。
态势数据的二三维一体化技术,是基于态势统一数据服务而扩展的。态势数据载体是在GIS上显示具有一定军事意义的图形符号。而态势数据展现依托二三维一体化的GIS,可以实现数据、操作、显示的二三维一体化。
(1)二三维数据一体化。构建统一的数据管理引擎,提供二维图形符号库和三维图形符号库,基于统一数据结构构建图形符号库数据。在基于二维数据管理的基础上,增加对三维数据属性的支持,共享同一份态势数据。
(2)二三维操作一体化。提供二三维一体的图形符号数据对象服务,可以保证在二三维交互式编辑时处理的是同一份图形符号对象,并且对图形对象的编辑也是基于同样的服务接口,做到二三维操作处理一体化。
(3)二三维显示一体化。服务提供的关于图形符号对象的描述是矢量信息。三维的态势展示根据二维矢量信息进行延展,二三维解析相同数据,并展现成各自维度上的图形符号对象。在共享同一份态势图文件时,二维显示可以忽略三维属性信息,但是三维显示会根据属性信息,构建自己的显示对象。
3 二三维一体REST态势数据服务接口设计
3.1 态势数据服务功能设计
(1)二三维一体态势文件服务。态势文件使得态势数据能够实体化,能够使用其它文件传输方式对态势文件进行分发传递。由服务提供态势文件的获取、删除,并且提供打开和保存功能,不同平台解释同一份态势文件保持语义上的一致。二三维可以共用同一个态势文件服务接口。
(2)二三维一体图形符号描述服务。图形符号对象是态势数据的元数据。图形符号对象矢量化表达,可以使不同平台根据绘制引擎进行解析矢量数据绘制。可以不与平台绘制引擎紧耦合,使不同绘制引擎均可根据数据进行图形符号数据展现。二三维可以共用同一个符号描述服务接口。
(3)二三维一体图形符号数据对象服务。可以根据图形符号所在的符号库标识和自身标识创建图形符号对象。图形符号库数据管理允许客户端创建、删除、修改二三维图形符号对象。
(4)二三维一体图形符号库管理访问服务。图形符号库以文件形式存在,定义了所有可以用来表达战场态势的图形符号。图形符号库管理服务可以对二维和三维的图形符号库进行增加、删除、修改操作。
3.2 资源结构和URI设计
REST使用URI(资源统一标识符)来表示组件之间交互所涉及的特定资源[6]。二三维一体态势文件类资源如表1所示;二三维一体图形符号矢量描述资源如表2所示;二三维一体图形符号数据对象资源如表3所示;二三维一体图形符号库资源如表4所示。
4 结语
REST服务框架采用Restlet(一个开源的Java框架)实现。提供二三维一体态势文件服务、二三维一体图形符号描述服务、二三维一体图形符号数据对象服务、二三维一体化图形符号库接口。这些二三维一体化服务接口作为统一的态势数据访问核心,能够支持不同系统对态势数据的需求,也能满足不同维度对态势数据展现多样性的需求。REST服务框架已通过浏览器客户端的二三维一体化成果验证,可以实现二三维数据的一体化、操作的一体化、显示的一体化。
摘要：研究了REST风格服务,设计实现了REST架构的二三维一体化态势数据服务系统,能满足联合作战时不同系统之间数据共享,相同系统之间数据共用。设计的态势数据服务系统能够支撑浏览器上的二三维态势一体化展现以及未来移动终端上的二三维一体化,能较好满足作战中对于态势数据服务的需求。
