Ajax和REST框架结合 为Web应用再添优势(1)
服务器端 Web 应用程序因采用富应用程序模型和交付个性化内容而具备了融入式(immersive) 的特点，这种特点越突出，应用程序架构对 Web 架构风格 REST(Representational State Transfer)的违背就越多。这种违背会降低应用程序的可伸缩性，增加系统复杂性。通过与 REST 相互协调，Ajax 架构将使融入式 Web 应用程序消除这些负面影响，尽享 REST 那些出色的特性。
在短短 15 年中，World Wide Web 已经从一项研究实验成长为现代社会的技术支柱。最初发明 Web 的目的是使人们可以轻松发布和链接信息，现在它已经发展为软件应用程序的可行平台。但随着应用程序通过使用富应用程序模型和生成个性化内容而获得了更多的融入性，它们的架构对 Web 架构风格 REST(Representational State Transfer)的违背也越来越多。这种违背会降低应用程序的可伸缩性，增加系统复杂性。
新兴的 Ajax Web 客户机架构风格让融入式 Web 应用程序与 REST 架构风格协调一致。使它们可以尽享 REST 那些出色的特性，同时又消除了应用程序违背 REST 准则时带来的不良特性。本文将介绍为融入式 Web 应用程序成功结合 Ajax 和 REST 的方法与原因。
REST:Web 架构
尽管 World Wide Web 是在数十年的相关研究基础上建立起来的，但它的有效诞生日期是 1990 年 12 月，当时 Tim Berners-Lee 完成了 Web 主要组件的工作原型:统一资源标识符(URI)、HTTP、HTML、浏览器和服务器。Web 被迅猛采用，远远超过了先驱者们的预期。在 Roy Fielding 最出名的系列文章中，他描述了自己当时的心情:
“尽管对其成功感到兴奋不已，但是 Internet 开发者社区逐渐开始担心，Web 使用的这种快速增长，以及早期 HTTP 的一些拙劣的网络特性，会快速压倒 Internet 基础设施所能承担的容量，从而导致突然的崩塌。”
Fielding 和其他人对 Web 架构及其是否能够足以支持各种扩展和用法重新进行了审视。这种重新审视的有形结果包括更新诸如 URI 和 HTTP 之类的一些重要标准。这种重新审视还获得了一些无形但却非常有意义的结果:为超级媒体应用程序确定了一种新的架构风格，Fielding 将其命名为 REST(Representational State Transfer)。Fielding 断言，使用且符合 REST 设计约束的 Web 上部署的组件可以充分利用 Web 的有用特性。他还警告说，违背 REST 准则的 Web 组件都将无法利用这些优点。
早期时，大部分 Web 站点和简单的 Web 应用程序实际上都是遵守 REST 准则的。但是随着融入式 Web 应用程序的日益普及，Web 应用程序架构逐渐开始背离 REST 准则了，此后因果循环，情况日益恶化。融入式服务器端 Web 架构的问题很难分析清楚，因为在使用这种架构风格的十年中，已经建立起这样一种信仰:这些问题都是 Web 应用程序架构所固有的。实际上，这并非是 Web 应用程序架构的问题。而是由服务器端 Web 应用程序架构风格所产生的问题。要打破这种偏见，我们来回顾一下整个架构是如何发展到现在这种状态的，这会很有帮助。我们将说明为什么在 Ajax 应用程序创建在商业上可行之后，过去接受的很多假设现在都不再成立了。
Web 应用程序的简史
Berners-Lee 创造了 Web，最初是将 Web 作为研究人员远程共享文档和在文档之间创建简单链接以加速知识和思想传播的一种手段。然而，URI 标准的架构特征很快实现了除静态文件之外更多内容的共享。
提供静态文档的 Web 站点
Web 上最早的内容由一些静态 HTML 文档组成，其中有很多到其他静态文档的链接，如图 1 所示:
图 1. 提供静态文档的 Web 站点
REST 使静态文档的检索极其高效、可伸缩，这是因为它们可以根据 URI 和最后修改日期来轻松缓存。很快开发人员就超越了静态文档的领域，开始动态文档的提供。
早期的动态 Web 应用程序
Berners-Lee 和其他人设计了 URI 标准，为资源的统一唯一标识提供支持，同时使其表示(HTML、文本等)根据 Web 客户机(通常是 Web 浏览器)和 Web 服务器之间的协商结果而变化。由于 URI 将资源标识和资源的底层存储机制区分开来，因此 Web 开发人员可以创建一些程序，使之检查 URI 语法，并动态生成文档，将预先定义的 UI 元素和动态检索的数据(通常是从关系数据库中)合并在一起，如图 2 所示。尽管这些文档是生成的，但是它们的缓存特征与静态文件的完全相同。
图 2. 以嵌入 HTML 模板代码形式提供数据库记录的 Web 站点
此类早期应用程序的一个简单例子是统一目录 Web 应用程序。这种应用程序通常以如下方式工作：
- 用户在 Web 表单中输入名字（例如，Bill Higgins），并单击提交按钮。
- 表单根据输入的名字创建一个 URI，并从服务器上请求这个 URI 的内容（例如 GET http://psu.edu/Directory/Bill+Higgins）。
- 服务器检查这个 URI，并使用这个学生的电话号码和地址来生成一个 Web 页面。
- 服务器将所生成的页面发回到用户的浏览器上。
这种交互的一个重要特性是它是幂等的（idempotent），也就是说除非底层资源发生变化（例如 Bill 修改了自己的电话号码），否则同一请求的结果总是相同的。这意味着浏览器或代理服务器都可以在本地对 Bill Higgins 的文档进行缓存，只要底层资源没有发生变化，那就可以从本地缓存中检索资源，而不再需要从远程服务器检索。这种方法能提高用户感受到的响应性，并增加系统整体效率和可伸缩性。这些早期的动态 Web 应用程序可以很好地工作，将大量的信息送至用户指尖。
融入式 Web 应用程序下一代 Web 应用程序的目标就是高度融入，提供个性化的内容和富应用程序模型。在过去十年中，Web 开发人员成功创建了这些融入式应用程序。一个非常恰当的例子是 Amazon.com 电子商务站点。当用户与 Amazon Web 应用程序进行交互时，它会创建复杂的客户页面来推荐有针对性的商品，显示浏览历史记录，并显示用户购物车中商品的价格。
融入式服务器端应用程序和 REST
融入式 Web 应用程序确实非常有用，但服务器端的融入式 Web 应用程序风格从根本上来说是不符合 REST 架构准则的。具体来说，它违背了一项关键的 REST 约束，并且没有利用 REST 最为重要的一些优点，因此又产生了一组新问题。
违背了 “无状态服务器” 约束
REST 的 “客户机－无状态－服务器” 约束禁止在服务器上保存会话状态。符合这一约束进行设计可以提高系统的可见性、可靠性和可伸缩性。但是融入式服务器端 Web 应用程序希望能够为单个用户提供大量个性化内容，因此必须在两种设计之间作出选择。第一种设计要在每个客户机请求中都发送大量状态信息，因此每个请求都完整地保留了上下文的内容，服务器是无状态的。第二种解决方案表面上来看比较简单，应用程序开发人员和中间件供应商都比较倾向于这种方法，它只是简单地发送一个用户标识，并在服务器端为这个标识关联一个 “用户会话”（如图 3 所示）。第二种设计直接违背了客户机-无状态-服务器约束。尽管它确实可以实现我们想要的用户功能（具体来说就是指个性化），但却对这个架构进行了极大的改动。
图 3. 融入式服务器端 Web 应用程序，其中包含了大量服务器端会话状态 
Java™ Servlet 的 HttpSession API 正是一个此类变动的例子。HttpSession 让我们可以在状态和特定用户之间建立关联。这个 API 看起来对于开发新手非常简单。实际上，它似乎可以将任何对象保存到 HttpSession 中，并且不需要自己实现任何特定的查找逻辑就可以将这些对象取出来。但是当我们开始在 HttpSession 中放入更多对象时，就会开始注意到我们的应用服务器要占用的内存和处理资源越来越多。很快我们就确定自己需要将应用程序部署到集群环境中来应对日益增加的资源需求。然后就会认识到，要让 HttpSession 在集群环境中工作，每个对象都必须实现 Java 的 Serializable 接口，以使会话数据能够在集群环境中的服务器间传递。然后必须确定应用服务器在关机/重启过程中是否要继续维护会话数据。很快您就会质疑，违背客户机－无状态－服务器约束是否真的是一个好主意。（实际上，很多开发人员都不了解这个约束。）
