Ajax 和 REST，第 2 部分

这个共分两部分的系列文章的第 1 部分 中，我们讨论了对于那些需要动态和个性化的用户界面，同时又要求可伸缩性的 Web 应用程序来说，Ajax/REST 架构风格可能带来的好处。给定这些需求之后，我解释了为什么相对于传统的服务器端 Web 应用程序架构风格来说，Ajax/REST 极为出色。但只有在您成功设想、规划、开发、测试和部署了 Ajax 应用程序之后，用户才能享受这些美好的运行时特性。本文说明了 Ajax/REST 应用程序的开发时特性的问题。其目标是为那些有兴趣在实际应用程序中使用 Ajax 的读者解答两个重要的问题： 是否应该在自己的 IT 应用程序中使用 Ajax 技术吗？ 如果答案是肯定的，那么应怎样来提高成功开发和部署 Ajax 技术的机会？
Ajax/REST 架构风格的新兴给使用传统服务器端 Web 应用程序风格的组织带来了一些挑战。尽管与传统模型相比，Ajax 具有许多引人注目的架构优点，但立即全面转换成纯粹的 Ajax/REST 架构对于所有组织来说并不现实。那些缺乏 Ajax 开发技巧的组织可向现有服务器端 Web 架构逐渐、增量式地添加 Ajax 功能，从而开始采用 Ajax 技术。随着这些组织在 Ajax/REST 使用方面的经验逐步增加，他们就可以安心地尝试更有趣、更有野心的项目。

请查看Ajax 资源中心，这是您获得 Ajax 编程模型的一站式场所，其中包含文章和教程、论坛、blog、wiki、事件和新闻。任何事件都会在这里报导。
Ajax 是一种由一组技术构成的架构风格。这些技术本身并没有好坏之分；它们都是中立的。只有在某些组织能够应用某种技术来解决特定的问题或满足特定的需求时，这种技术才会或多或少地有用。因此要回答 “我应该使用 Ajax 吗？” 这个问题，您必须评估自己的组织正在尝试解决的问题是什么，Ajax 可以对您实现目标提供怎样的帮助（还是根本就帮不上忙），以及您的组织是否具有项目成功所需要的恰当人员。
我们可能会纳闷，“采纳 Ajax” 到底是什么意思。要利用 Ajax，组织并不需要重新编写使用纯 Ajax/REST 架构的程序。我建议您从一些小程序入手，逐渐积累一些经验和信心，而不是直接立即采用纯粹的 Ajax/REST 架构。
采纳 Ajax 可以意味着完成一些轻量和细微的任务 —— 可能是重新实现 Web 应用程序的一个小特性，以使其更酷、更具响应性。Netflix 电影反馈特性就是这种轻量级风格的一个例子。顾客可以通过点击 1 到 5 星来快速给电影评分。每次点击会立即更新 它们的 Netflix 参数，并相应地调整推荐电影。
在采纳的整个领域内，高端采纳就是诸如 Google 的 Gmail 和 Maps 之类的应用程序，它们已经重新定义了 Web 应用程序开发的当前发展水平。这些应用程序因其众多的直观交互特性、可视化效果和根据用户操作和数据不断调节用户界面方面的能力而知名。
设想一下，如果您为自己的行业开发一个像 Google Maps 一样精密的程序会接受到多少正面的反应，这非常有趣。但应该现实一点。Google 可能是世界上最出色的 Web 开发组织，因此以它为基准来衡量 Ajax 的能力是非常危险的。不要忘记，Google（明智地）只有为黄金时间做好准备后才会发布自己的新应用程序，因此我们只看到了成功。可以推测，即使是 Google 的天才们偶尔也会在应用 Ajax 时失败，我们只是不知道这些失败而已。
纯 Ajax/REST 是一种新的架构风格，相对于诸如 JSP（JavaServer™ Page 技术）和 PHP 等较为成熟的 Web 应用程序风格来说，它仍然很难实现。除非提供下一代的 Web 用户经验是主要需求，而且还有世界级的 Web 开发团队，否则您的组织最好像 Netflix 一样最初 “小规模地采纳 Ajax”，而不是像 Google 一样 “大规模地采纳 Ajax”。
问问自己，Ajax 编程风格有哪些特征使它对于您的应用程序的需求具有吸引力。您的公司正在寻找响应性更高的 UI 能提供的生产力增长点吗？您希望部署一个高度动态和个性化，又具备可伸缩性的应用程序吗？对于您的目标客户群来说，“酷” 会成为一种具有差异化优势的特性吗？所有这一切都是合理的理由，还有些其他方面的理由。关键在于，您必须能够找到一个合情合理的采纳 Ajax 的理由。下面是 Ajax 可以很好地实现的 3 种功能：
响应性更好的 UI。 在传统的服务器端 Web 应用程序中，任何与服务器的交互都要求刷新页面，这意味着这中间需要 2 到 5 秒的延时，还要刷新整个页面。Ajax 使用户可以与服务器通过 “fire and forget” 的交互方式来与服务器交互：用户执行一个操作，系统可以在后台处理该任务，同时用户可以继续处理其他任务。UI 只需要更新有新信息要显示的部分即可，而不用重画整个页面。如果一切顺利，Ajax 风格的 UI 可以让用户实现并维护这种流程，从而提高用户满意度和生产力。
迷人。对于那些对外的应用程序和产品来说，只实现需要实现的功能已不足以使之成为一种好产品。您的客户现在有着太多的选择。您需要一种产品来吸引用户，并使他们为之着迷。就像谚语所说的那样，“性感就是一种特质”。这并不是说需要将开发人员可以想像到的所有铃声和钟声都包含在其中 —— 看一下最低配置设计的 iPod 是如何击败那些具有 10 倍控制功能的便携式音乐播放器就能明白这个道理。问题的关键是提供一种包含众多细微特性的一流设计，帮助用户以一种轻松愉快的方式来完成自己要做的事情。
Gmail 是一个很好的例子。从外表上来说，Gmail 只不过是另外一个基于 Web 的 e-mail 应用程序，这种技术已经存在 10 年之久了。但是 Gmail 使用 Ajax 做了一些正确的事情。您之前曾经由于意外地关闭浏览器而丢失过未发送的 e-mail 消息吗？Gmail 开发人员仔细考虑了这个问题，通过精心设计，差不多每分钟都会将未发送的消息的一份副本保存到草稿文件夹中。每次都要查找随时都会使用的 e-mail 地址是不是很烦呢？Gmail 开发人员仔细考虑了这个问题，基于以前发送的 e-mail 消息提供了一种精心设计的地址补全算法。
“迷人” 对于外部及商业应用程序来说非常重要，但是对于内部业务应用程序来说则没这么重要。一切取决于环境。
不牺牲可伸缩性的个性化。在过去的十五年中，随着传统服务器端应用程序朝着更加动态化和个性化的方向不断发展，开发人员和中间件也越来越多地向在服务器端存储大量的会话状态而努力。这种方式会推动个性化的发展，但对于可伸缩性来说却是个噩耗。正如在第 1 部分 中所介绍的一样，Ajax 应用程序通常都是将会话状态保存到客户机端，并通过无状态的服务与服务器进行交互，这样可以获得动态性和个性化都非常好的 Web 应用程序，而不会牺牲可伸缩性。
这三方面的收益会帮助您的组织取得成功吗？如果不行，那 Ajax 又提供了哪些其他特别的优势来为您的组织的成功贡献力量呢？如果您现在还找不到有说服力的具体理由来采用 Ajax，那么我建议您暂时先不要考虑 Ajax 了，直到找到这样一个理由为止。如果您的确有这样的理由，那么请继续阅读本文。




回页首
您已经确定 Ajax 可以为组织带来一些独特的价值，这可以证明为采用这种新兴技术而冒的风险是值得的。本节将讨论如何将 Ajax 技术成功整合到我们的应用程序和软件开发过程中。在下一节中，我们将讨论在 “大规模采纳 Ajax” 技术开发时所需考虑的一些特殊事项。
对于一种有用的新兴技术，没有什么打击能比某个项目试图使用这种技术但却在众人的瞩目下失败更严重了。这通常是由于尚不具备足够的技能，却一次过快地尝试过多新东西而引起的。但是现在很难找到具有丰富 Ajax 开发经验的开发人员；这种技术还太年轻。
为了解决这个问题，开发组织应该通过在真正的项目上实施 Ajax 来逐渐积累使用 Ajax 的经验，但是先不要在关键特性上尝试这种技术。集中精力先将一些小特性部署到真实的世界中。从错误中不断学习和调整。如果试图过早地迈出一大步，那么就会给项目带来太多风险。这一步迈得越大，经过一个完整的设计/开发/测试/部署周期所需要的时间也就越长，而这是获取实践经验的关键。
这个建议更适用于那些希望 “小规模尝试 Ajax” 的组织；不过对于那些希望 “大规模采纳 Ajax” 技术的组织来说，他们也可以通过循环往复的开发方式从小处入手，正如我们在“大规模采纳 Ajax 技术”的特殊考虑事项 一节中讨论的一样。
设想一下，您的 Web 开发人员团队中有些人在过去 10 年中已成功交付了很多 PHP、Java 或 .NET 服务器端 Web 应用程序，如果他们可以顺利成长为 Ajax 专家，那的确非常令人兴奋，但是实际情况可能并非如此。尽管我们仍然在 Web 开发这个领域内工作，但是 Ajax 架构风格和支持技术需要开发人员忘却旧知识，重新学习新语言和新模式。这种转型的确 是可能的，不过需要花费一些时间。
在传统的服务器端 Web 开发中，您需要处理链接的点击和表单的提交，并使用一个完整的 HTML 页面进行响应。通常一个工作流都会跨越很多页面，因此服务器端应用程序逻辑必须维护与浏览器之间的会话。服务器必须记住整个应用程序一次次的点击，这样在用户与 Web 应用程序进行交互时，才能提供无缝的工作流。在 Ajax 世界中，我们从这个 “绿色屏幕” 模型转换成了一个真正的客户机-服务器模型，其中客户机是有状态的，而且是动态的，服务器只需要负责提供原子的无状态服务即可。这种新编程风格要求具备客户端和服务器端方面的不同技巧。
在客户端，我们需要那些在长于 CSS、JavaScript 和文档对象模型（DOM）编程的开发人员。问题是大部分开发组织都宣称 “我们具有使用 JavaScript 和 CSS 的经验”，但那往往是一些微不足道的功能，例如修饰文本和在客户端进行表单的验证。认为具有这点 JavaScript/CSS 经验的服务器端 Web 开发人员可以胜任大规模 Ajax 应用程序的工作就像是认为会开车的人就有资格 Daytona 500 赛事一样荒唐。
这也是为什么从小处入手如此重要的另外一个原因。我们的 Web 开发人员现在可能还不具备创建 Gmail 这么重量级的 Ajax 应用程序所需要的技能和经验，不过他们应该可以在现有服务器端 Web 应用程序上实现一些小规模的改进。随着时间和经验的积累，他们逐渐就可以使用 Ajax 来实现更加复杂的场景了。
在服务器端，Ajax 代表了一种转换，因为我们可以将一些不引人注目的会话管理和工作流状态从服务器上移开了。一旦我们积累了足够的经验，Ajax 风格的 “有状态客户机/无状态服务器” 更容易理解和管理，但是这种架构风格的改变需要一些新的技能。我们的服务开发人员应该很好地理解 HTTP 协议，了解 TEST 架构风格的知识，并且具备开发分布式服务的经验，例如远程方法调用（RMI）和远程过程调用（RPC）。尽管 REST 架构风格与 RPC 有一些根本性的区别，但是它们所涉及的一些非功能性的基本准则（边界安全性、网络延迟和非可靠性）都是通用的。
DOM、CSS 和 XMLHttpRequest（XHR）“标准” 与浏览器有很大的不同。那些不希望选择现有框架来解决这些差异的开发人员可能会花费大量意料之外的时间来编写自己的信息管道代码，以便对浏览器间的不一致性进行规范化。您的信息管道代码的品质在达到目前可用框架已达到的品质之前，需要有很长一段时间。一种可行的框架是开源的 Dojo 工具包（请参看参考资料）。
开发 Ajax 应用程序涉及两种截然不同的行为：使用 HTML/JavaScript/CSS/DOM 实现 UI 和应用程序逻辑，以及使用早已建立的服务器端平台（例如 PHP、J2EE 和 .NET）来实现服务器逻辑。在服务器端，可以使用以前一直使用的工具。在客户端，则需要学习使用一些新工具。对于希望支持的每个浏览器，都可能都需要一个不同的 Ajax 工具包。这里有一个通用工具功能的列表（请参看参考资料 中支持两种最流行的 Web 浏览器 —— Microsoft Internet Explorer 和 Mozilla Firefox 的工具的链接）：

对于从 J2EE 或 .NET 方面过渡过来的开发人员来说，普遍的痛苦之一就是 JavaScript 编程语言的代码补全功能尚不成熟。这是 JavaScript 动态类型特性所决定的，另外也与 JavaScript 历史上用户群较小，没有为很好的代码补全技术培育很好的用户群这个事实有关。代码补全功能现在正在使用诸如 Aptana 之类的技术进行改进，但是在达到 Eclipse Java 开发人员或 Visual Studio C# 开发人员所习惯的程度之前，仍然有很长一段路要走。
编写代码：编辑器和 IDE。 在客户机端 Ajax 开发中，我们需要编写 HTML、CSS 和 JavaScript 文件的组合。代码编辑器可以通过语法高亮显示、语法错误检查以及代码补全功能来提高我们的生产效率。
检查结构：DOM 检查器。由于 Ajax Web 页面的很多可视化结构都是在用户与页面进行交互时动态创建的，因此为了探索页面实际的结构，仅仅查看源代码并不能满足要求。源代码很可能与我们所看到的 UI 根本就没有任何相似之处。我们需要在与页面进行交互时对 DOM 结构进行检查。DOM 查看器有一个很好的补足特性是 “实际源代码” 检查器，它能对 DOM 当前状态的 HTML 源代码进行反向工程，这样就可以为那些习惯查看 HTML 源代码的开发人员提供一种直观的手段来了解页面的内容。
检查行为：JavaScript 调试器。在编写一些小 JavaScript 脚本来验证表单或提供少量交互能力时，大部分开发人员都可以使用简单的 alert 语句来定位问题所在。但是当您开始进行大规模 Ajax 开发时，就需要为希望支持的每种 Web 浏览器来寻找并学习一种 JavaScript 调试器。
检查客户机-服务器交互：XHR 监视器。 Ajax 工具包最后一个重要的工具是 XmlHttpRequest（XHR）监视器。XHR 是一个 JavaScript 对象，它可以与服务器进行 Ajax 风格的远程通信。XHR 监视器使我们可以对请求/响应对进行监视，包括它们的头和内容。

对于目前开发领域最前沿的敏捷开发技术，您可能会纳闷，单元测试在整个 Ajax 框架中究竟处于什么位置。在编写本文时，Ajax 世界中还没有占统治地位的单元测试框架。每个框架（例如 Dojo 或 Scriptaculous）都试图采用自己的优化单元测试框架。Michael Mahemoff 撰写的 Ajax Design Patterns 的第 19 章（请参看参考资料）对 2006 年的单元测试状况进行了很好的总结，并讨论了各种 Ajax 框架的单元测试功能。
文档中也明确提到，如果没有开发人员的努力，Ajax 会破坏我们对 Web 站点的一些基本期望：例如，后退按钮、书签或浏览器的 “加载” 控件都有可能无法正常工作。我所给出的 “从小处入手” 的建议在这里也能提供一些帮助。只要您只使用 Ajax 来实现一些增量新特性，它们只会更新页面状态，而不会对导航或工作流造成影响，那么后退按钮和书签都不会有任何问题。但是加载时间可能会成为一个问题，尤其是当我们只在本地开发环境上进行测试时更是如此，此时网络延时并不会成为太大的制约因素。
考虑一下：在传统的 Web 应用程序中，当用户点击一个链接或提交一个表单时，即使后续页面的加载花费了 10 秒钟，它们也会从浏览器的 “加载” 控件中看到即时反馈。在 Ajax 应用程序中，点击一个可以触发 XHR 请求的控件并不会激活 “加载” 控件。只在本地开发环境上进行测试的危险在于：HTTP 请求、响应和后续的 UI 更新看起来似乎都是即时发生的，这造成了缺乏浏览器 “加载” 反馈机制貌似也不是什么问题的假象。但在产品环境中，用户距离服务器可能会有成百上千里远，缺乏这种反馈机制就可能会产生困扰并挫败他们的信心。用户可能会纳闷：“我点中这个控件了吗？让我再点一下看看。仍然什么都没有！”
遗憾的是，即使您在工程方面作出了最大的努力，网络延迟依然会存在，因此我们必须接受这个事实。假设有时用户点击控件和服务器的响应到达之间存在一些时间的滞后。当用户作出某种表示发起一个远程调用时，浏览器会提供一条即时反馈，说明它已经看到了用户的这个表示。临时禁用控件或显示一条消息说明正在发生什么，直到接收到服务器的响应并使用这些信息来更新 UI 之后才删除这条消息。网络调用是瓶颈所在；编写需要执行很长时间的 JavaScript 代码还比较困难。
问题的关键是我们需要在真实的环境中进行测试，此时这些可用性问题都很容易发现。问题发现得越早，相应进行响应的时间也就越早。
在真实环境中进行测试的另外一个方面是要确保在需要支持的每种浏览器的每个版本上进行所有的功能测试。例如，如果您声称要支持 Firefox 1.5 和 2.0 以及 Internet Explorer 6 和 7，那就需要在这些浏览器上持续进行测试。或许这是显而易见的道理，但开发人员却很容易陷入一些怀习惯：只在自己喜欢的浏览器上进行开发和测试，以后在其他浏览器上发现问题时就会需要重新修整自己的代码。




回页首
尽管我们已经建议您不要去尝试创建像 Gmail 或 Google Maps 那样庞大的 Ajax 应用程序，但是有些业务或者工程代理可能会迫使您那样做。我们的第一反应是：不要这样做 —— 从小处入手，不但积累经验。但是如果立即就要构建一个纯 Ajax 应用程序，就请继续阅读本文。
您的开发团队现在就更加重要了，因为您不是简单地使用新技术来扩展久经验证的架构，而是要采用一个全新的架构。您的团队虽然在 Ajax 方面的经验很少，但需要作出一些重要的决策 —— 这些设计决策可能会导致可怕的错误后果。
您需要一些在 JavaScript/DOM 和 CSS 方面具有丰富经验的成员。如果没有丰富 JavaScript 经验的人，就要寻找一些在其他脚本编程语言（例如 Perl、Python 或 Ruby）方面具有丰富经验的人。Lisp 或 Scheme 等功能编程语言方面的经验也会很有帮助，但经验丰富的 Lisp/Scheme 程序员可能比熟练的 JavaScript 程序员还要稀少。
不要低估良好的 CSS 对应用程序品质的重要影响。缺乏对 CSS 的深入理解可能会导致一些原本不必那样糟糕、难以维护的代码，这会使得首次或再次重写代码更加困难。
重新编写？你说什么？
每当您进行新领域的开发工作时，第一次就可以做出正确决策的可能性很小。您可能会脚步蹒跚地弄出一些难经推敲、满是缺陷的设计，也可以先从小处着手，然后随着不断学习新知识并获得哪些能做哪些不能做的经验之后，再不断更新设计。
Ajax 提出了一项独特的挑战，因为用户经验和底层架构模式与服务器端的对应部分有着很大的区别。在您的 UI 中，可能会发现一些细微但有持续性影响的瑕疵：后退按钮并不能像如期工作，当用户调用远程操作时没有太多反馈，等等。遗憾的是，在具备这方面的经验并明白必须修改设计中的哪些地方以便修复这些问题之前，您很难为这些问题设计解决方案。
希望重新编写自己的应用程序的另一原因是在您获得使用 JavaScript/DOM 和 CSS 经验的同时，您会发现一些新术语和模式，它们可以带来更加简明、可读性和可维护性更好的代码。另外，随着您编写的代码越来越多，您就可以开始着手解决一些通用的问题，尽管这些问题的通用性还不足以进入第三方的框架，但却足以放入我们自己的库中，而不是到处散落于顶层的代码中。重构原来的代码从而使用新的库代码，这样从长远来看是值得的，不过需要花费一些时间，而且这种活动需要不断进行下去。您会发现，自己逐渐进入了框架领域，这里又有一些自己的问题集。
随着您在大规模应用程序中取得不断进展，就会发现，很多通用应用程序服务都不是由纯粹的 JavaScript/DOM/CSS 或全新的 Ajax 框架（例如 Dojo 和 Prototype）提供的。您要尝试创建自己的框架级的代码来简化新应用程序级功能的创建。这通常不是什么坏事；大部分最好的开发框架（例如 Ruby on Rails）都已经从具体的应用程序需求中提取出来了。但是务必谨慎；我已经警告过，在小范围内采纳 Ajax 是可行的，但是大规模采纳 Ajax 会非常困难 —— 难度可能会高出一个数量级。支持大规模采纳 Ajax 的设计框架级技术的难度又会高出一个数量级，尤其是在您刚刚接触 Ajax 技术领域时更是如此。
框架代码引入了更多层次的抽象和间接调用，这使得代码路径很难理解。经验之一是尽可能在具体的应用程序层进行工作，只有在应用程序中至少有 3 个部分都可能会使用代码所提供的功能时，才考虑将部分代码移动到一个框架和可重用的库中。
新领域开发中的一个主要的反模式就：在最初设计和实现一个真正的用户可用并可提供反馈意见的小产品之间需要花费太多时间。因此，在您着手实现大型的新 Ajax 应用程序之前，应该先在几周之内提供一个基本可以工作的展示模型，以便让用户开始提供反馈。UI 可能还非常原始，代码也许并不完美，但如果您在让用户体验新应用程序之前先花费 6 个月的时间进行开发，结果也是这样；惟一的区别就是，要丢弃的代码和 UI 都要多上 10 倍。
您需要在很长的设计周期中加速循环过程，使真正的用户一直在一个仿真产品条件的环境中体验产品。这种方法的最高境界是搭建一个测试服务器，开发人员每隔几天就在上面更新代码，这样用户和项目主管就可以体验新产品并提供反馈了。




回页首
采纳 Ajax 技术最大的风险是目前业界普遍缺乏实践经验。由于这个原因，我建议您从小处入手，让开发团队开始积累经验并培养自信，这样就不会给项目造成太大的风险。如果您决定，现在就集中精力投身于纯 Ajax 设计，那么请现实一点，应该理解，这种方式的成功几率很低。除非您拥有世界级的 Web 开发团队，以及可以支持迭代开发和实验的开发组织，否则很可能要失败。
不过随着时间的推移，事情会变得越来越简单，风险也会越来越低，因为越来越多的实践者会不断积累经验，新的框架、工具和最佳实践也会不断涌现。Ajax 会变得更加安全，也会成为更普及的技术 ……. 不过这个阶段可能不会在短时间内到来。