1、REST(Representational State Transfer)是 HTTP 协议的作者 Roy Fielding 博士在其博士论文中提出的一种互联网应用构架风格。与以远程对象为核心的 ORB 和以服务为核心的 SOA 相比，以资源为核心的 REST 让我们从崭新的视角审视互联网应用。REST 为互联网应用量身定做的简洁模型、与 HTTP 协议的完美结合、构架的高扩展性，为互联网应用构架设计和异构系统集成设计带来了一股清新的空气。语言生态环境计算机发展至今，产生了许许多多不同的语言，每种语言都定义了自己独特的生态环境。在这个生态环境内的程序共享相同的类型系统、运行时环境、并发模型等。
2、虽然所有程序的本质是相同的：从问题领域到机器领域的映射，但无法回避的是不同生态环境的程序很难跨越彼此的边界。同样是 int，在 A和 B 语言通常截然不同（CLR 和 JVM 能部分解决类型共享问题），更不用说 A语言具有但 B 语言不具有的某些语言特性(CLR 和 JVM 没法解决)。当系统可以在单一的生态环境中自给自足时，跨越生态环境的问题并不存在；但在多数互联网应用中，系统的各个部分通常既是生产者又是消费者，必须要打破生态环境的界限才能相互协作。比如，A 公司的 Service A，需要对外提供服务，而 Service A 又依赖于 B 公司的 Service B 和 C 公司的 Ser
3、vice C；由于无法保证不同公司都采用同样的语言，因此各服务的接口必须保证语言无关性。在我所了解的范围内，有 3 种跨域生态环境的方式：1. ORB(Object Request Broker)以 CORBA 为代表，其核心概念是远程对象（remote object）。熟悉.Net Remoting 的朋友应该能体会其风格（需要说明的是.Net Remoting 只跨越微软的生态环境）。不同生态环境的程序可以像调用本地对象一样调用远程对象代理的方法，ORB 会负责连接到远程的对象，并处理数据的序列化与反序列化。2. SOA其核心概念是服务(Service)。比如：我们要提供整数加法 Web
4、服务，我们会很自然地想到通过类似下面的 url 来表达服务接口：http:/ xml 结构表达结果：3. REST其核心概念是资源(Resource)。在 REST 的世界中，没有服务的概念，同样是上面的例子，在 REST 的世界中，http:/ 是一个 xml 网页资源的 id，而非服务的接口。所以，REST 让我们从资源的角度来审视互联网应用并指导我们的设计，这是它与 ORB 和 SOA 最本质的区别。下面我们将更详细的介绍，REST 以资源为核心的模型和相应的设计风格。状态表述转移在 REST 的世界中，资源即状态，而互联网就是一个巨大的状态机：每个网页是其一个状态；url 是状态的表述
5、；REST 风格的应用则是从一个状态迁移到下一个状态的状态转移过程。早期互联网只有静态页面的时候，通过超链接在静态网页间浏览跳转的 page-link-page-link模式就是一种典型的状态转移过程。无状态服务器REST 风格应用可以实现交互，但它却天然地具有服务器无状态的特征。在状态迁移的过程中，服务器不需要记录任何 Session，所有的状态都通过 url的形式记录在了客户端。PS:更准确地说，这里的无状态服务器，是指服务器不保存会话状态(Session)；而资源本身则是天然的状态，通常是需要被保存的；本文提到的无状态服务器均指无会话状态服务器。举个例子：一个心理测试的应用，需要用户做
6、2 次选择题，每次可选 A、B两种答案，2 次选择完毕之后将告知用户属于何种心理类型。如果按 ORB 或 SOA 的服务思维，很容易想到在服务器端保存 Session，每次选择以后修改 Session，根据 Session 产生结果。但如果以 REST 的状态表述转移模型为指导，我们会自然地得出这样设计：每一个页面表示一个状态（存在于客户端），页面包含了到下一个页面的超链接，每当用户选 a 或选 b 时分别转移到下一个相应的状态。这样，所有的会话状态其实都是通过 url 的形式保存在了客户端，服务器端实现了无状态。另外，需要说明的是，虽然上图有 7 个状态，但并非一定需要在服务器预先生成 7
7、个静态页面，它们完全可以是动态页面，这不影响状态转移的概念模型以及服务器无状态的特征。有构架设计经验的朋友应该很清楚，与有状态服务设计相比，无状态服务容易实现系统性能的横向扩展。通过增加硬件，部署多个无状态服务，并进行load balance 不会受到制约；而有状态服务模式，Session 的存储、共享都会带来性能瓶颈，且无法通过增加硬件消除。Google 搜索就是一个典型的无状态服务。试想一下，当你搜索“周杰伦”以后，Google 提示你有数百万的结果，并每 10 条一页分成若干页，Google 会把结果保存进服务器 Session 吗，然后当你翻页的时候，再从 Session 中取吗？显然
8、这样庞大的 Session，即使是 Google 也无法承受。Google 把搜索结果的每一页视为资源（状态），并通过 url 来表示，同一搜索关键字的不同分页通过 start 参数来进行区分。当你从第一页点击第二页的链接时，只是从一个状态跳到了下一个状态而已；对于 Google 而言，其实是一条新的查询（按 REST 的观点，获取新的资源），而两次查询很可能是由不同的服务器在处理，而用户却感觉 Google 似乎记住了会话。从上面的例子中，我们初步体会到了一点 REST 风格的味道。但需要说明，REST 风格包含了无状态服务器的特征；但反过来，并非具有无状态服务器特征的都是 REST。SOA
9、 同样可以是无状态的，REST 的核心还是资源。CRUD上一节我们通过两个例子初步体会了 REST 状态表述转移的味道，但应该指出这两个例子还仅仅是简单的资源获取。REST 是以资源为核心的，没有服务的概念，这的确让人怀疑 REST 能否像 ORB 或 SOA 一样支持复杂的应用？在回答这个问题之前，让我们先暂时离开 REST，把眼光转向基于关系数据库的 3 层构架。通常业务逻辑层对外提供若干的功能接口（如图中定义的 IOrderService），对内通过数据访问层访问数据库。我们知道，关系数据库只定义了CRUD(Create, Read, Update, Delete)四种标准的数据操作，分
10、别对应于insert/select/update/delete 四种 sql 语句。经验告诉我们，关系数据库在若干张表上进行关系运算是足以支持各种复杂业务逻辑的，因为所有业务功能最终都会被映射到数据库上的 CRUD 四种标准操作。下面这个有趣的三角形能帮助我们理解这个问题：图中的三角分别代表：数据类型、操作、实例。可以把他们想象成可以调节的按钮，业务逻辑层的方式是：定义了少量的服务实例，把大量的操作放在服务实例下面，形象地比喻为“一扇小门，里面装了很多东西”；而数据库的方式则是提供了大量数据实例和 CRUD 四种标准操作，可比喻为“很多门，每扇门里面装少量的东西”。以资源为核心的 REST 和
11、以数据为核心的关系数据库是类似的。数据和资源本质上都是状态，对状态的操作 CRUD 少一个不行，多一个多余。因此，REST也采用 CRUD 四种标准操作，分别对应于 HTTP 协议的 POST/GET/PUT/DELETE 方法。虽然 HTTP 协议支持 POST/GET/PUT/DELETE 以外的 HEAD 等方法，可以把这些非标准方法作为有用的补充，但不应影响 REST 模型的纯洁性。上一节中，我们看到 REST 风格的应用像一个状态机；而这里我们则看到它像一个数据库。按REST 方式定义出的资源（Url）和相应的操作就像下面这个样子（值得重申的是，从 Url 的含义“统一资源定位符”就
12、可以看出其通用性，这也是 REST 资源表示的优势所在）：REST 完美地结合了 HTTP 协议，所以更容易无缝接入互联网。另外，有人提到 “一个网站对外暴露的网页数可以作为衡量它为互联网所做贡献的指标”，如果从这个角度来看，以资源为核心的 REST 方式比服务为核心的 SOA 对互联网更加友好。但应该采用哪种风格的构架还是取决于应用本身的特点，一般来讲，对于以提供和管理数据为主的，且希望做 SEO 的应用适合 REST 风格，这包括大多数 WEB2.0 的应用；而以计算和业务逻辑为主，且强调安全性的应用不太适合REST 风格。但应避免不加分析先入为主的采用面向服务的思维，有时候恰当运用状态表
13、述转移模式的 REST 构架不但可以实现业务逻辑，而且具有更好的伸缩性，正如上一节谈到的心理测试服务和 Google 搜索一样。REST 的价值就在于让我们在设计构架的时候多了一种视角，所谓“眼界决定世界”。Cache 由于 REST 的 Url 表示资源和无状态服务特点，使得 Cache 机制变得异常简单，且 HTTP 协议中有直接支持。服务器响应可以通过 cache-control:max-age,expires 指定资源缓存时间；还可以在响应头的 last-modified 参数标明资源的最后修改时间，客户端请求可以带上 if-modified-since 参数，如果资源未过期，服务器只
14、需用返回 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 的掌握和应用还需继续努力，希望得到高手的指点！
