ITPub博客

首页 > 云计算 > 虚拟化 > RESTful与Openstack

RESTful与Openstack

原创 虚拟化 作者:hxw2ljj 时间:2015-11-19 16:40:03 0 删除 编辑
 抽象(Abstraction)是人类掌控、理解复杂事物的屠龙刀、倚天剑,反映到工程上,也即模块化设计,因此接口也成为了大家挂在嘴边上最多的一个词。理解学习一个事物、模块最好的方式,应该是去了解它的接口,而不是一下子深入到细节,很容易不识庐山真面目。
    Openstack集成了若干项目,基于面向服务的架构(SOA),每个项目独立提供服务,而并不在意使用者是谁(当然前提是合法的用户),做什么用途。具体地,Openstack每个项目的接口遵循REST原则,通常也被称为RESTful接口。很显然,并不是通过HTTP提供的接口就是RESTful接口,但是大家往往就是这么认为的..... 所以在学习Openstack之前,我们得要好好地理解一下什么是RESTful。

1. 什么是RESTful[1]
    REST这个词,是Roy Thomas Fielding在他2000年的博士论文中提出的。Fielding是一个非常重要的人,他是HTTP协议(1.0版和1.1版)的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席。所以,他的这篇论文一经发表,就引起了关注,并且立即对互联网开发产生了深远的影响。
Fielding将他对互联网软件的架构原则,定名为REST,即Representational State Transfer的缩写。我对这个词组的翻译是"表现层状态转化"。如果一个架构符合REST原则,就称它为RESTful架构。

    要理解RESTful架构,最好的方法就是去理解Representational State Transfer这个词组到底是什么意思,它的每一个词代表了什么涵义。如果你把这个名称搞懂了,也就不难体会REST是一种什么样的设计。

    REST的名称"表现层状态转化"中,省略了主语。"表现层"其实指的是"资源"(Resources)的"表现层"。所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务,总之就是一个具体的实体。你可以用一个URI(统一资源定位符)指向它,每种资源对应一个特定的URI。要获取这个资源,访问它的URI就可以,因此URI就成了每一个资源的地址或独一无二的识别符。

    "资源"是一种信息实体,它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式,叫做它的"表现层"(Representation)。比如,文本可以用txt格式表现,也可以用HTML格式、XML格式、JSON格式表现,甚至可以采用二进制格式;图片可以用JPG格式表现,也可以用PNG格式表现。URI只代表资源的实体,不代表它的形式。严格地说,有些网址最后的".html"后缀名是不必要的,因为这个后缀名表示格式,属于"表现层"范畴,而URI应该只代表"资源"的位置。它的具体表现形式,应该在HTTP请求的头信息中用Accept和Content-Type字段指定,这两个字段才是对"表现层"的描述。

    访问一个网站,就代表了客户端和服务器的一个互动过程。在这个过程中,势必涉及到数据和状态的变化。互联网通信协议HTTP协议,是一个无状态协议。这意味着,所有的状态都保存在服务器端。因此,如果客户端想要操作服务器,必须通过某种手段,让服务器端发生"状态转化"(State Transfer)。而这种转化是建立在表现层之上的,所以就是"表现层状态转化"。客户端用到的手段,只能是HTTP协议。具体来说,就是HTTP协议里面,四个表示操作方式的动词:GET、POST、PUT、DELETE。它们分别对应四种基本操作:GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源。

2. REST的四个基本实践原则[2]

 

a) 显示的使用HTTP方法;

对于资源的操作,通常可以总结为CRUD(Create, Read, Update, Delete),对应到HTTP方法分别就是POST, GET, PUT以及DELETE。我们在设计接口时,必须显示的使用这些方法,也即服务器收到客户端的请求后,通过判断HTTP方法就能够知道对于资源的操作类型。有很多时候,比如原型,大家为了图省事,只采用一种方法,例如GET,而将真正地操作类型编码在URI中或者HTTP正文中,这些都是不符合REST原则的作法。

b) 无状态;

web开发人员最熟悉的一个词就是session,也即会话。服务端会将客户端的很多状态保存在session里,这样的解决方案看起来很美,但是但是,一旦要做web优化,例如负载均衡的时候麻烦就来了,会话必须在不同的服务器之间复制,尽管很多中间件或者平台帮大家搞定了这个事情,但是一旦一旦出问题了,找root cause那是相当的麻烦。而REST要求遵循的服务器端Stateless设计,也即服务器不保存状态,所有状态都保存在客户端,客户端在发送请求消息时,需要在请求消息中携带web service所需要的完整信息,包括参数、上下文等。这样的好处很明显,任何部署了相关应用的web服务器都能够接受来自客户端的请求,并且服务器端做的任何优化,例如服务器集群、负载均衡,对于客户端而言都是透明的。

c) URI命名/组织采用类似目录结构

URI表示的资源,还是那句话-"Power of Abstraction",所有的复杂事物都是由经过抽象的实体组合而成的,所以资源和资源必然存在着某种组合、包含的关系,反应到名字上也理应如此,例如典型的目录结构。

d) 采用XML、JSON传输信息

3. Openstack的RESTful接口

 

以Openstack中的Quantum为例,众所周知Quantum主要通过插件的方式提供网络服务。外部实体通过调用Quantum-Server提供的RESTful接口,创建、删除、更新、查询网络服务或者资源。Quantum提供的基本网络资源包括:

Network: 表示一个(逻辑上的)二层网络

Subnet: 表示一个IP地址段,用于通过DHCP服务分配给虚拟机;

Port: 表示逻辑二层网络上的一个端口,对应连接到某个虚拟机的网络接口

RESTful与Openstack

RESTful与Openstack

在理解了RESTful和资源的前提下,再去看Quantum API(2.0),理解肯定会更深了一步:

http://wiki.openstack.org/Quantum/APIv2-specification


[1] http://kb.cnblogs.com/page/114905/

[2] http://www.ibm.com/developerworks/webservices/library/ws-restful/

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/18796236/viewspace-1841214/,如需转载,请注明出处,否则将追究法律责任。

上一篇: kubernetes分布式
全部评论

注册时间:2010-11-22

  • 博文量
    58
  • 访问量
    42895