2.3.1　REST技术

REST架构风格是全新的针对Web应用的开发风格，是当今世界最成功的互联网超媒体分布式系统架构，它使得人们真正理解了HTTP协议的本来面貌。随着REST架构成为主流技术，一种全新的互联网网络应用开发的思维方式开始流行。

REST（Representational State Transfer，表述性状态转移）是由Roy Thomas Fielding博士在他的论文Architectural Styles and the Design of Network-based Software Architectures中提出的一个术语。REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。

基于Web的架构，实际上就是各种规范的集合，这些规范共同组成了Web架构，如HTTP协议、客户端服务器模式。在原有规范的基础上增加新的规范，就会形成新的架构。而REST正是这样一种架构，他结合了一系列的规范，它形成了一种新的基于Web的架构风格。

传统的Web应用大都是B/S架构，它的规范包括客户机－服务器、无状态性、缓存等。

1.Web应用下的规范

（1）客户机－服务器

客户机-服务器规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为可能。

（2）无状态性

无状态性是在客户机－服务器约束的基础上添加的又一层规范。它要求通信必须在本质上是无状态的，即从客户机到服务器的每个request都必须包含理解该request所必需的所有信息。这个规范改善了系统的可见性（无状态性使得客户机端和服务器端不必保存对方的详细信息，服务器只需要处理当前request，而不必了解所有的request历史）、可靠性（无状态性减少了服务器从局部错误中恢复的任务量）和可伸缩性（无状态性使得服务器端可以很容易地释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上下文中，因此增加了在一系列request中发送重复数据的开销，严重降低了效率。

（3）缓存

为了改善无状态性带来的网络低效性，Web技术添加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户机端缓存response数据的功能。但是由于客户机端缓存了信息，也就同时增加了客户机与服务器数据不一致的可能，从而降低了可靠性。

2.REST规范

B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况，引入了REST。REST在原有的架构上增加了3个新规范：统一接口、分层系统和按需代码。

（1）统一接口

REST架构风格的核心特征就是强调组件之间有一个统一的接口，这表现在REST世界中，网络上所有的事物都被抽象为资源，而REST就是通过通用的连接器接口对资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，极大地简化了系统，从而改善了系统的交互性和可重用性。并且REST针对Web的常见情况做了优化，使得REST接口被设计为可以高效地转移大粒度的超媒体数据，这也导致REST接口对其他架构并不是最优的。

（2）分层系统

分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，这也提高了系统的可伸缩性。

（3）按需代码

REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码来扩展客户端功能，但这在改善系统可扩展性的同时，也降低了可见性。所以它只是REST的一个可选的约束。

REST架构是针对Web应用而设计的，其目的是降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则：

①网络上的所有事物都被抽象为资源（resource）。

②每个资源对应唯一的资源标识符（resource identifier）。

③通过通用的连接器接口（generic connector interface）对资源进行操作。

④对资源的各种操作不会改变资源标识符。

⑤所有的操作都是无状态的（stateless）。

REST中的资源所指的不是数据，而是数据和表现形式的组合，比如“最新访问的10位会员”和“最活跃的10位会员”在数据上可能有重叠或者完全相同，而由于它们的表现形式不同，所以被归为不同的资源。资源标识符就是URI（Uniform Resource Identifier），不管是图片、Word文档还是视频文件，甚至只是一种虚拟的服务，也无论是xml格式、txt文件格式还是其他文件格式，全部通过URI对资源进行唯一标识。

REST是基于HTTP协议的，任何对资源的操作行为都是通过HTTP协议实现。以往的Web开发大多数用的都是HTTP协议中的GET和POST方法，对其他方法很少使用，这实际上是因为对HTTP协议片面的理解造成的。HTTP不仅是一个传输数据的协议，它还是一个具有丰富内涵的网络软件协议。它不仅仅能对互联网资源进行唯一定位，而且还能告诉用户如何对该资源进行操作。HTTP把对一个资源的操作限制在4个方法以内：GET、POST、PUT和DELETE，这正是对资源CRUD[Create（增加）、Read（读取查询）、Update（更新）、Delete（删除）]操作的实现。由于资源和URI是一一对应的，执行这些操作时URI没有变化，这和以往的Web开发有很大的区别。正由于这一点，极大地简化了Web开发，也使得URI可以被设计成更为直观的反映资源的结构，这种URI设计称为RESTful的URI。这为开发人员引入了一种新的思维方式：通过URI来设计系统结构。当然了，这种设计方式对一些特定情况也是不适用的，也就是说不是所有的URI都可以RESTful的。

REST之所以可以提高系统的可伸缩性，是因为它要求所有的操作都是无状态的。由于没有了上下文（Context）的约束，做分布式和集群时就更为简单，也可以让系统更为有效地利用缓冲池（Pool）。并且由于服务器端不需要记录客户机端的一系列访问，也减少了服务器端的性能。

REST不仅是一种崭新的架构，它带来的更是一种全新的Web开发过程中的思维方式：通过URI来设计系统结构。在REST中，所有的URI都对应着资源，只要URI的设计是良好的，那么其呈现的系统结构也就是良好的。这点和TDD（Test Driven Development）相似，它是通过测试用例来设计系统的接口，每个测试用例都表示一系列用户的需求。开发人员不需要一开始就编写功能，而只需要把需要实现的功能通过测试用例的形式表现出来即可。这个和REST中通过URI设计系统结构的方式类似，只需要根据需求设计出合理地URI，这些URI不一定非要链接到指定的页面或者完成一些行为，只要它们能够直观地表现出系统的用户接口。根据这些URI，就可以方便地设计系统结构。从REST架构的概念上来看，所有能够被抽象成资源的东西都可以被指定为一个URI，而开发人员所需要做的工作就是如何把用户需求抽象为资源，对资源抽象的越精确，对REST的应用来说就越好，这和传统MVC开发模式中基于Action的思想差别非常大。设计良好的URI，不但对于开发人员来说可以更明确地认识系统结构，对使用者来说也方便记忆和识别资源，因为URI足够简单和有意义。按照以往的设计模式，很多URI后面都是一堆参数，对于使用者来说也是很不方便的。

既然REST这么好用，那么是不是所有的Web应用都能采取此种架构呢？答案是否定的。直到现在为止，MVC（Model View Controller）模式依然是Web开发最普遍的模式，绝大多数公司和开发人员都采取此种架构来开发Web应用，并且其思维方式也停留于此。MVC模式由数据、视图和控制器构成，通过事件（Event）触发Controller来改变Model和View。加上Webwork、Struts等开源框架的加入，MVC开发模式已经相当成熟，其思想根本就是基于Action来驱动。从开发人员的角度来说，贸然接受一个新的架构会带来风险，其中的不确定因素太多。并且REST新的思维方式是把所有用户需求抽象为资源，这在实际开发中是比较难做到的，因为并不是所有的用户需求都能被抽象为资源，这也就是说不是整个系统的结构都能通过REST来表现。所以在开发中，需要根据以上两点在REST和MVC中做出选择。比较好的办法是混用REST和MVC，因为这适合绝大多数Web应用开发，开发人员只需要对比较容易、能够抽象为资源的用户需求采取REST开发模式，而对其他需求采取MVC开发即可。这里需要提到的是ROR（Ruby on Rails）框架，这是一个基于Ruby语言的Web开发框架，它极大地提高了Web开发的速度。更为重要的是，ROR（从1.2版本起）框架是第一个引入REST作为核心思想的Web开发框架，它提供了对REST最好的支持，也是当今最成功的应用REST的Web开发框架。实际上，ROR的REST实现就是REST和MVC混用，开发人员采用ROR框架，可以更快更好地构建Web应用。

对开发人员来说，REST不仅在Web开发上贡献了自己的力量，同时可以学到如何把软件工程原则系统地应用于对一个真实软件的设计和评估上。对于云计算中间层架构的设计，REST无疑是最好、最通用的技术。