Ajax和REST框架结合 为Web应用再添优势(1)(2)
使分布式缓存变为不可能
融入式服务器端 Web 应用程序的第二个严重后果在于：它实际上不能利用 REST 的第一类支持进行资源缓存。引用 Fielding 的话来说，“添加缓存约束的优点是可以部分或完全避免某些交互操作，从而可以通过减少一系列交互的平均延迟来提高效率、可伸缩性以及用户可以感受到的性能。不过这样做的代价是如果缓存中的陈旧数据与通过将请求直接发送给服务器而获得的数据有很大区别，那么缓存的可靠性就降低了。”
我们可以将融入式 Web 应用程序近似地看作一个活动实体，它会根据用户提供的新输入内容、其他人输入的新内容以及新的后台数据而不断发生变化。由于服务器必须根据多个用户与应用程序的交互来生成每个页面，因此我们实际上无法两次生成相同的文档。因此，Web 浏览器或代理服务器无法缓存服务器资源。
有几种解决方案可以用来处理资源无法缓存的问题。一种就是创建细粒度的资源在服务器端的缓存，这样服务器就可以通过预先组合好的部分来构建一个粗粒度的页面，而不是通过基本元素（HTML 和数据）从头开始一步步地构建这种页面了。但是问题依然存在：每个请求都会导致大量的服务器处理，这会损害系统的可伸缩性，还可能会对用户感受到的响应性造成负面影响。
无法提供可缓存资源的另外一个结果是：动态程度相当高的 Web 应用程序必须显式地禁止搜索引擎和其他类型的 “机器人”作出请求，因为处理这类请求的成本都非常昂贵；而在符合 REST 准则的应用程序中，只需一次性地将某个资源提供给那一类 “机器人”，然后对它们的后续访问发送一条简单的 “Not-modified” 消息即可。
但是为什么要在一个负载过重的服务器上集中这么多的资源消耗呢？从理论上来说，我们什么时候可以将处理和内存需求分布到客户机呢？简单的答案是给定传统 Web 浏览器约束，这是不可行的。但是 Ajax 架构风格使开发人员可以将处理和状态需求分布到客户机。请继续阅读，学习为什么选择使用 Ajax 风格的融入式应用程序可以继续遵循 REST 准则，并充分利用它的优势。
Ajax 和 REST
正如我们前面看到的一样，传统的服务器端 Web 应用程序将数据的标识和服务器上的动态数据元素合并在了一起，并将所构成的完整 HTML 文档返回给浏览器。Ajax 应用程序在其主要 UI 和浏览器中的主要逻辑方面有所不同；基于浏览器的应用程序代码可以在必要时获取新的服务器数据，并将这些数据织入当前页面。呈现和数据绑定的位置看起来可能是一个实现细节，但是这种区别会导致完全不同的架构风格。
利用有状态 Web 客户机的优点
人们通常将 Ajax 应用程序描述成无需在每次点击时彻底地刷新整页的 Web 页面。尽管这个描述非常确切，但是根本的动机在于彻底刷新整页会令用户不耐烦，从而无法获得愉快、融入式的用户体验。从架构的角度来看，整个页面全部刷新的设计甚至非常危险，这种设计使您无法选择在客户机存储应用程序状态，这可能会导致妨碍应用程序充分利用 Web 最强大的架构设计点的设计决策。
Ajax 让我们不需要进行完全刷新就可以与服务器进行交互，这一事实使有状态客户机再次成为可用选择。这一点对于动态融入式 Web 应用程序架构的可能性有深远的影响：由于应用程序资源和数据资源的绑定转换到了客户端，因此这些应用程序都可以享受这两个世界中最好的东西 ―― 融入式 Web 应用程序中动态、个性化的用户体验，以及遵守 REST 准则的应用程序中简单、可伸缩的架构。
缓存 Ajax 引擎
设想一下，将 Amazon.com 彻底重新实现为一个 Ajax 应用程序 ―― 一个 Web 页面可以从服务器上动态获取所有的数据。（出于商业原因，Amazon 可能并不希望这样做，不过那是其他文章讨论的话题了。）由于现在有很多 UI 和应用程序逻辑都可以在客户机而不是在服务器上运行，根据 Garrett 的说法，最初加载页面时需要下载 Amazon 的 Ajax “引擎”。这个引擎包含大量应用程序逻辑（以 JavaScript 代码实现），另外还有此后将使用从服务器上异步获取的数据填充的 UI 框架（见图 4）：
图 4. 融入式 Ajax 应用程序 
Ajax 引擎一个有趣的特征就是：尽管它包含了很多应用程序逻辑和表示框架元素，但是如果经过恰当的设计，它可以不包含任何业务数据或个性化内容。应用程序和表示都冻结在部署时。在典型的 Web 环境中，应用程序资源可能 6 个月才会变更一次。这意味着负责隔离应用程序资源和数据资源的 Ajax 引擎是高度可缓存的。
Dojo Toolkit 就是一个很好的例子。Dojo 提供了构建时工具来创建一个包含所有应用程序逻辑、表示和风格的压缩 JavaScript 文件。由于它终究只是一个文件，因此 Web 浏览器可以对其进行缓存，这意味着我们第二次访问启用 Dojo 的 Web 应用程序时，很可能就会从浏览器缓存中加载 Ajax，而不是从服务器上加载它。我们可以将这种情况与高度融入化的服务器端 Web 应用程序进行一下对比，后者每次请求都会导致大量的服务器处理，因为浏览器和网络中介不能对缓存不断变化的资源。
由于 Ajax 应用程序引擎只是一个文件，因此它也是可以使用代理缓存的。在大型的企业内部网中，只要有一名员工曾经下载过某个特定版本的应用程序的 Ajax 引擎，其他任何人都可以从内部网网关上上获取一个缓存过的拷贝。
因此对于应用程序资源来说，经过良好定义的 Ajax 应用程序引擎符合 REST 准则，与服务器端 Web 应用程序相比，它具有显著的可伸缩性优势。
缓存 Ajax 数据
用户浏览一个 Ajax Web 站点，加载 Ajax 应用程序引擎，最好是从浏览器缓存中加载的，否则就从本地代理服务器加载。那么对于业务数据来说情况如何呢？由于应用程序逻辑和状态都在浏览器上驻留并执行，因此应用程序与服务器的交互就与传统 Web 应用程序的方式有很大的不同。不需要获取混合的内容页面，只需要获取业务数据即可。
现在回到 Amazon.com 的例子上来，假设我们点击了一个链接，要查看有关设计模式的一本书籍。在 Amazon.com 目前的应用程序中，链接点击操作会发送很多标识所请求的资源的信息。它还会发送很多会话状态信息，这让服务器可以创建一个新页面，其中可以包括之前的状态（例如最近查看的内容）、个性化信息（例如您在 1999 年购买的书籍）以及实际的业务资源本身。应用程序是动态且高度个性化的 ―― 但是却不能缓存，也无法伸缩（正如 Amazon 所示范的一样，这些架构问题都可以通过投入大量资金构建基础设施来克服）。现在我们考虑一下这个操作在（假想的）Ajax 版本的应用程序中的情况。对于 “最近查看的内容” 并不需要进行处理。当我们点击某个链接时，这些在页面上已经存在的信息并不会消失。有两个请求很可能会与设计模式的书籍有关：
- /Books/0201633612（其中 0201633612 是设计模式书的 ISBN 号）
- /PurchaseHistory/0201633612/bhiggins@us.ibm.com
第一个假定的请求会返回有关书籍的信息（作者、标题、简介等）；其中并没有包含特定于用户的数据。特定于用户的数据意味着当更多用户请求相同的资源时，很可能会从 Internet 上的中间节点上来检索缓存版本，而不是从原始服务器上检索这些资源。这种特性会降低服务器和总体网络负载。另外一方面，第二个请求包含了特定于用户的信息（Bill Higgins 的购买该书的历史记录）。由于这些数据包括一些个性化信息，因此只有一名用户需要从这个 URI 中获取并缓存数据。尽管这种个性化数据并没有非个性化数据的可伸缩特性，但是重要的问题是这些信息都是直接从 URL 中获取的，因此都具有这样的正面特征：它们都不会妨碍其他可缓存的应用程序和数据资源的缓存。
Ajax 和健壮性
Ajax 架构风格的另外一个优点是它可以轻松处理服务器的故障。正如我们前面介绍的一样，具有融入式用户体验的服务器端 Web 应用程序通常会在服务器上保存大量的用户会话状态。如果服务器发生了故障，会话状态就丢失了，那么用户就会体验到非常奇怪的浏览器行为（“为什么我又回到主页上来了？我的购物车中的东西都到哪里去了？”）。在采用有状态客户机和无状态服务的 Ajax 应用程序中，服务器崩溃/重新启动对于用户来说都是完全透明的，因为服务器崩溃不会影响会话状态，这些都保存在用户的浏览器中；无状态服务的行为是幂等的，可以由用户请求的内容来单独确定。
(责任编辑：铭铭 mingming_ky@126.com TEL：（010）68476636)
