RESTful与Openstack

 抽象(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和资源的前提下，再去看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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/18796236/viewspace-1841214/