REST构架风格

转过来的东西，概念比较新，先留在这里

http://www.cnblogs.com/weidagang2046/archive/2009/05/08/1452322.html

REST构架风格介绍之一：状态表述转移

REST(Representational State Transfer)是HTTP协议的作者Roy Fielding博士在其博士论文中提出的一种互联网应用构架风格。与以远程对象为核心的ORB和以服务为核心的SOA相比，以资源为核心的REST让我们从崭新的视角审视互联网应用。REST为互联网应用量身定做的简洁模型、与HTTP协议的完美结合、构架的高伸缩性，为互联网应用构架设计和异构系统集成设计带来了一股清新的空气。

本文希望与大家分享REST风格构架设计的体会，错误不足之处欢迎批评指正。

语言生态环境

计算机发展至今，产生了许许多多不同的语言，每种语言都定义了自己独特的生态环境。在同一生态环境内的程序共享相同的类型系统、运行时环境、并发模型等。虽然所有程序的本质是相同的：从问题领域到机器领域的映射，但无法回避的是不同生态环境的程序很难跨越彼此的边界。同样是int，在A和B语言通常截然不同（CLR和JVM能部分解决类型共享问题），更不用说A语言具有但B语言不具有的某些语言特性(CLR和JVM没法解决)。

当系统可以在单一的生态环境中自给自足时，跨越生态环境的问题并不存在；但在多数互联网应用中，系统的各个部分通常既是生产者又是消费者，必须要打破生态环境的界限才能相互协作。比如，A公司的Service A，需要对外提供服务，而Service A又依赖于B公司的Service B和C公司的Service C；由于无法保证不同公司都采用同样的语言，因此各服务的接口必须保证语言无关性。在我所了解的范围内，有3种跨域生态环境的方式：

1.      ORB(Object Request Broker)

以CORBA为代表，其核心概念是远程对象（remote object）。熟悉.Net Remoting的朋友应该能体会其风格（需要说明的是.Net Remoting只跨越微软的生态环境）。不同生态环境的程序可以像调用本地对象一样调用远程对象代理的方法，ORB会负责连接到远程的对象，并处理数据的序列化与反序列化。

2.      SOA

其核心概念是服务(Service)。比如：我们要提供整数加法Web服务，我们会很自然地想到通过类似下面的url来表达服务接口：

http://www.example.com/add?a=1&b=2

并通过xml结构表达结果：

<sum>3</sum>

3.      REST

其核心概念是资源(Resource)。在REST的世界中，没有服务的概念，同样是上面的例子，在REST的世界中，http://www.example.com/add?a=1&b=2是一个xml网页资源的id，而非服务的接口。所以，REST让我们从资源的角度来审视互联网应用并指导我们的设计，这是它与ORB和SOA最本质的区别。下面我们将更详细的介绍，REST以资源为核心的模型和相应的设计风格。

状态表述转移

在REST的世界中，资源即状态，而互联网就是一个巨大的状态机：每个网页是其一个状态；url是状态的表述；REST风格的应用则是从一个状态迁移到下一个状态的状态转移过程。早期互联网只有静态页面的时候，通过超链接在静态网页间浏览跳转的page->link->page->link…模式就是一种典型的状态转移过程。

无状态服务器

REST风格应用可以实现交互，但它却天然地具有服务器无状态的特征。在状态迁移的过程中，服务器不需要记录任何Session，所有的状态都通过url的形式记录在了客户端。PS:更准确地说，这里的无状态服务器，是指服务器不保存会话状态(Session)；而资源本身则是天然的状态，通常是需要被保存的；本文提到的无状态服务器均指无会话状态服务器。

举个例子：一个心理测试的应用，需要用户做2次选择题，每次可选A、B两种答案，2次选择完毕之后将告知用户属于何种心理类型。

如果按ORB或SOA的服务思维，很容易想到在服务器端保存Session，每次选择以后修改Session，根据Session产生结果。但如果以REST的状态表述转移模型为指导，我们会自然地得出这样设计：

每一个页面表示一个状态（存在于客户端），页面包含了到下一个页面的超链接，每当用户选a或选b时分别转移到下一个相应的状态。这样，所有的会话状态其实都是通过url的形式保存在了客户端，服务器端实现了无状态。另外，需要说明的是，虽然上图有7个状态，但并非一定需要在服务器预先生成7个静态页面，它们完全可以是动态页面，这不影响状态转移的概念模型以及服务器无状态的特征。

有构架设计经验的朋友应该很清楚，与有状态服务设计相比，无状态服务容易实现系统性能的横向伸缩性。通过增加硬件，部署多个无状态服务，并进行load balance不会受到制约；而有状态服务模式，Session的存储、共享都会带来性能瓶颈，且无法通过增加硬件消除。无状态服务器的背后是有状态的客户端，由于REST将所有状态都保存在客户端，所以存在一定的安全隐患，这也目前业界对REST的主要担忧。因此，在决定是否采用REST风格构架前应从应用本身的特点出发，综合伸缩性、交互性、安全性等因素综合考虑。

Google搜索就是一个典型的无状态服务。试想一下，当你搜索“周杰伦”以后，Google提示你有数百万的结果，并每10条一页分成若干页，Google会把结果保存进服务器Session吗，然后当你翻页的时候，再从Session中取吗？显然这样庞大的Session，即使是Google也无法承受。来看看Google的url：

第一页：http://www.google.cn/search?q=%E5%91%A8%E6%9D%B0%E4%BC%A6&hl=zh-CN&newwindow=1&start=0&sa=N 

第二页：http://www.google.cn/search?q=%E5%91%A8%E6%9D%B0%E4%BC%A6&hl=zh-CN&newwindow=1&start=10&sa=N

Google把搜索结果的每一页视为资源（状态），并通过url来表示，同一搜索关键字的不同分页通过start参数来进行区分。当你从第一页点击第二页的链接时，只是从一个状态跳到了下一个状态而已；对于Google而言，其实是一条新的查询（按REST的观点，获取新的资源），而两次查询很可能是由不同的服务器在处理，而用户却感觉Google似乎记住了会话。

从上面的例子中，我们初步体会到了一点REST风格的味道。需要说明，REST风格包含了无状态服务器的特征；但反过来，并非具有无状态服务器特征的都是REST。SOA同样可以是无状态的，REST的核心还是资源，下一节将会继续就这个话题进行探讨，谢谢关注！

 

上一节我们通过两个例子初步体会了REST状态表述转移的味道，但应该指出这两个例子还仅仅是简单的资源获取。REST是以资源为核心的，没有服务的概念，这的确让人怀疑REST能否像ORB或SOA一样支持复杂的应用？在回答这个问题之前，让我们先暂时离开REST，把眼光转向基于关系数据库的3层构架。

通常业务逻辑层对外提供若干的功能接口（如图中定义的IOrderService），对内通过数据访问层访问数据库。我们知道，关系数据库只定义了CRUD(Create, Read, Update, Delete)四种标准的数据操作，分别对应于insert/select/update/delete四种sql语句。经验告诉我们，关系数据库在若干张表上进行关系运算是足以支持各种复杂业务逻辑的，因为所有业务功能最终都会被映射到数据库上的CRUD四种标准操作。下面这个有趣的三角形能帮助我们理解这个问题：

图中的三角分别代表：数据类型、操作、实例。可以把他们想象成可以调节的按钮，业务逻辑层的方式是：定义了少量的服务实例，把大量的操作放在服务实例下面，形象地比喻为“一扇小门，里面装了很多东西”；而数据库的方式则是提供了大量数据实例和CRUD四种标准操作，可比喻为“很多门，每扇门里面装少量的东西”。

以资源为核心的REST和以数据为核心的关系数据库是类似的。数据和资源本质上都是状态，对状态的操作CRUD少一个不行，多一个多余。因此，REST也采用CRUD四种标准操作，分别对应于HTTP协议的POST/GET/PUT/DELETE方法。虽然HTTP协议支持POST/GET/PUT/DELETE以外的HEAD等方法，可以把这些非标准方法作为有用的补充，但不应影响REST模型的纯洁性。上一节中，我们看到REST风格的应用像一个状态机；而这里我们则看到它像一个数据库。按REST方式定义出的资源（Url）和相应的操作就像下面这个样子（值得重申的是，从Url的含义“统一资源定位符”就可以看出其通用性，这也是REST资源表示的优势所在）：

REST完美地结合了HTTP协议，所以更容易无缝接入互联网。另外，有人提到 “一个网站对外暴露的网页数可以作为衡量它为互联网所做贡献的指标”，如果从这个角度来看，以资源为核心的REST方式比服务为核心的SOA对互联网更加友好。但应该采用哪种风格的构架还是取决于应用本身的特点，一般来讲，对于以提供和管理数据为主的，且希望做SEO的应用适合REST风格，这包括大多数WEB2.0的应用；而以计算和业务逻辑为主，且强调安全性的应用不太适合REST风格。但应避免不加分析先入为主的采用面向服务的思维，有时候恰当运用状态表述转移模式的REST构架不但可以实现业务逻辑，而且具有更好的伸缩性，正如上一节谈到的心理测试服务和Google搜索一样。REST的价值就在于让我们在设计构架的时候多了一种视角，所谓“眼界决定世界”。

Cache

由于REST的Url表示资源和无状态服务特点，使得Cache机制变得异常简单，且HTTP协议中有直接支持。服务器响应可以通过cache-control:max-age,expires指定资源缓存时间；还可以在响应头的last-modified参数标明资源的最后修改时间，客户端请求可以带上if-modified-since参数，如果资源未过期，服务器只需用返回304 not modified状态即可，这样就避免了服务器端重复工作，也节省网络带宽；etag参数也是常用的cache控制参数，可以解决last-modified时间精度不够的问题。另外，HTTP协议还对Proxy机制有直接的支持，与Cache机制结合，在需要高性能的应用中，可以在服务器与客户端之间部署若干专门用于Cache目的Caching Proxy Server提高系统吞吐量。

总结

最后总结一下REST的要点：1. Url表示资源；2.  CRUD操作；3. 状态表述转移。至于无状态服务、Http状态码、Cache控制、Proxy等则属于上面几个要点的推论，理解REST的关键还在于理解以资源为核心的模型。本文是我接触REST不到一年时间的一些体会和总结，深知对REST的掌握和应用还需继续努力，希望得到高手的指点！

相关链接

1.《如何获取一杯咖啡——星巴克REST案例分析》

2.《深入浅出REST》