通常业务逻辑层对外提供若干的功能接口（如图中定义的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》