REST Service 的最佳实践，第 2 部分 REST service 化一个数据系统

look_w

引言在 Web 变成可编程的 platform 的进程中，有一些应运而生的新的服务的应用场景。我们来看一个具体的例子。Lily 是 Web 2.0 team 一个 Web 开发人员，她想买一些 Web 2.0 开发相关的书来开阔和加深她对 Web 2.0 技术的理解。她希望怎么做呢？她打开她订阅的 eBay畅销书服务（一个 Feed），看到目前最畅销的一组关于 Web 2.0 的书籍，在她浏览这些书的介绍的时候，她还想看看这些书在 Amazon上的书评。等她决定好了买哪些书的时候，她想最好能货比三家，她要知道各个书商提供的 书的价格比较，她选择了一家性价比比较合理的书商后需要付钱购买，比如用 Goolge Check Out 来付账。服务之间的导航关系如图 1 所示。
图 1. 买书所需用的的服务以及关系今天，lily 如果想做到这一点，要么 IT developer 帮她专门开发一个集成的系统，把这些不同 vendor 提供的 Web 服务集成起来：eBay 提供的 畅销书服务，Amazon 提供的 书评服务，directtextbook.com 提供的 书的价格比较 服务，Google 提供的 Goolge Check Out 服务。但显然这种方法实施性和适应性都较差，因为 lily 的需求不固定，浏览的路径也不固定，IT developer 很难决定需要集成哪些 Web 服务，很难满足像 lily 这样的不固定的需求。另外，Lily 还可以选择使用现有的 Mashups 的产品，如 IBM Mashup Center，但是她需要做比较枯燥乏味而又不是那么容易的 widget 之间的 wiring，而且她还要自己知道这些个相关的 Web 服务。对 lily 而言，如果有这样一个系统，她可以从最开始的 eBay 畅销书服务开始浏览，然后查看 Amazon 的书评，就像现在的 Web 上面的 HTML 页面之间通过 hyperlink 浏览一样，她也可以很容易的通过鼠标的点击、选择、输入一些很少的东西再辅以搜索就可以从一个服务达到另一个服务，平滑、自然、简单、轻松。
这是一个美好的梦想，如何能实现这个梦想？作为第一步，每个企业或者业务系统都必须服务化，实现数据的灵活访问，也就是企业信息系统的解锁，让普通人以 Web 的方式就能轻松的访问。基于此，我们分析 lily 买书这个场景中的几个 Web 服务可知，这些 Web 服务虽然来自不同的系统，但他们之间是有联系的。eBay 提供的畅销书服务的数据里面包含书的 ISBN 信息，而 Amazon 的书评服务和 directtext.com 提供的书的价格比较服务都需要 ISBN 信息才能返回相应的书的书评和价格比较。另外如果现在很多人都用 Goolge Check Out 付账，说明他的 popularity 比较高。当用户想要购买的时候，可以用它。如果我们要满足 lily 的要求而又不需要 IT developer 的参与，我们就需要一种方式描述和建立服务之间的关联，发现和利用这种关联来改善普通人们使用互联网的体验 – 像使用 HTML 为基础的内容 Web 一样来自由地从一个服务浏览到另外一个服务，这正是 REST 架构风格可以解决的问题。
传统的 Web 业务系统的分析在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。Martin Fowler 在《 Patterns of Enterprise Application Architecture 》一书中，将整个架构分为三个主要的层：表示层、领域层和数据源层，如图 2 所示。
表示层 (User Interface Layer) 位于最上层，离用户最近，为用户提供一种交互式操作的界面，用于显示数据和接收用户输入的数据。
业务逻辑层（Business Logic Layer）是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。
数据访问层（Data Access Layer）有时候也称为是持久层，其功能主要是负责数据库的访问，直接操作数据库，针对数据的增、删、改、查。简单的说法就是实现对数据表的 Select，Insert，Update，Delete 的操作。如果要加入 ORM 的元素，那么就会包括对象和数据表之间的 mapping，以及对象实体的持久化。
分层的结构给 Web 应用的开发带来了很多好处，比如开发人员可以只关注整个结构中的其中某一层；可以很容易的用新的实现来替换原有层次的实现；可以降低层与层之间的依赖；有利于标准化；利于各层逻辑的复用。现在也是作为 Web 应用的主流架构提供。
图 2. Web 应用的三层架构企业信息系统面临的挑战尽管企业现在有很多的数据系统和应用系统，但是还仍然面临以下的严峻挑战：

• 现有的应用系统的“更新”速度跟不上“变化”的速度。也就是说，IT 的更新速度跟不上业务需求的变化速度。
• 通常业务人员的数据需求是非常宽泛和任意的，IT 系统很难用一个固定的逻辑写出一个固定的系统来满足。现实生活中的需求是多种多样的，一个用固定逻辑写出来的系统只能满足一部分的需求，不够灵活。
• 通常业务人员请求的数据可能来自很多其他的领域，比如在公安领域，警察办案除了警察自己的数据库以外，还需要交通部门的数据，中国移动的数据，等这些数据都不是写几个 SQL 语句就能拿到的。这个挑战设计到不同系统之间的集成。怎么样把各个系统的资产变得可重用，还能以一种简单的标准的协议互相通信。
• 数据拿到之后对数据还需要做一定的随机的处理，比如合并、过滤、排序等，现有的固定逻辑的业务系统也很难满足。