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的核心还是资源，下一节将会继续就这个话题进行探讨，谢谢关注！