Ajax/REST：应对Ajax软件开发的挑战

　　Ajax 的流行程度呈爆炸式增长。老式的 Web 框架正在为支持 Ajax 而自行革新，新的纯 Ajax 框架正在开发之中，很多组织正在考虑采用 Ajax，或者已经开始了构建 Ajax 应用程序的工作。但在所有这些悸动之中，只有相当少的组织成功开发了 Ajax 应用程序。本文是分为两部分的系列文章的第二部分，本文将帮助您决定是否应在实际 IT 应用程序中使用 Ajax，旨在提高您在 Ajax 开发中取得成功的机会。查看第一部分文章：Ajax/REST 架构风格的优点。

　　在这个共分两部分的系列文章的 第 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 是一种由一组技术构成的架构风格。这些技术本身并没有好坏之分;它们都是中立的。只有在某些组织能够应用某种技术来解决特定的问题或满足特定的需求时，这种技术才会或多或少地有用。因此要回答 “我应该使用 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 能为您达成目标带来怎样的帮助

　　问问自己，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 了，直到找到这样一个理由为止。如果您的确有这样的理由，那么请继续阅读本文。