在這個共分兩部分的系列文章的 第 1 部分中，我們討論了對于那些需要動態(tài)和個性化的用戶界面，同時又要求可伸縮性的 Web 應用程序來說，Ajax/REST架構風格可能帶來的好處。給定這些需求之后，我解釋了為什么相對于傳統(tǒng)的服務器端 Web 應用程序架構風格來說，Ajax/REST極為出色。但只有在您成功設想、規(guī)劃、開發(fā)、測試和部署了 Ajax 應用程序之后，用戶才能享受這些美好的運行時特性。本文說明了 Ajax/REST應用程序的開發(fā)時特性的問題。其目標是為那些有興趣在實際應用程序中使用 Ajax 的讀者解答兩個重要的問題：

• 是否應該在自己的 IT 應用程序中使用 Ajax 技術嗎？
• 如果答案是肯定的，那么應怎樣來提高成功開發(fā)和部署 Ajax 技術的機會？

Ajax/REST 架構風格的新興給使用傳統(tǒng)服務器端 Web 應用程序風格的組織帶來了一些挑戰(zhàn)。盡管與傳統(tǒng)模型相比，Ajax具有許多引人注目的架構優(yōu)點，但立即全面轉換成純粹的 Ajax/REST 架構對于所有組織來說并不現(xiàn)實。那些缺乏 Ajax開發(fā)技巧的組織可向現(xiàn)有服務器端 Web 架構逐漸、增量式地添加 Ajax 功能，從而開始采用 Ajax 技術。隨著這些組織在 Ajax/REST使用方面的經驗逐步增加，他們就可以安心地嘗試更有趣、更有野心的項目。

您是否應該使用 Ajax？

Ajax是一種由一組技術構成的架構風格。這些技術本身并沒有好壞之分；它們都是中立的。只有在某些組織能夠應用某種技術來解決特定的問題或滿足特定的需求時，這種技術才會或多或少地有用。因此要回答 “我應該使用 Ajax 嗎？” 這個問題，您必須評估自己的組織正在嘗試解決的問題是什么，Ajax可以對您實現(xiàn)目標提供怎樣的幫助（還是根本就幫不上忙），以及您的組織是否具有項目成功所需要的恰當人員。

考慮采納選項的范圍

我們可能會納悶，“采納 Ajax” 到底是什么意思。要利用 Ajax，組織并不需要重新編寫使用純 Ajax/REST 架構的程序。我建議您從一些小程序入手，逐漸積累一些經驗和信心，而不是直接立即采用純粹的 Ajax/REST 架構。

采納 Ajax 可以意味著完成一些輕量和細微的任務 —— 可能是重新實現(xiàn) Web應用程序的一個小特性，以使其更酷、更具響應性。Netflix 電影反饋特性就是這種輕量級風格的一個例子。顧客可以通過點擊 1 到 5星來快速給電影評分。每次點擊會立即更新 它們的 Netflix 參數(shù)，并相應地調整推薦電影。

在采納的整個領域內，高端采納就是諸如 Google 的 Gmail 和 Maps 之類的應用程序，它們已經重新定義了 Web 應用程序開發(fā)的當前發(fā)展水平。這些應用程序因其眾多的直觀交互特性、可視化效果和根據(jù)用戶操作和數(shù)據(jù)不斷調節(jié)用戶界面方面的能力而知名。

設想一下，如果您為自己的行業(yè)開發(fā)一個像 Google Maps一樣精密的程序會接受到多少正面的反應，這非常有趣。但應該現(xiàn)實一點。Google 可能是世界上最出色的 Web 開發(fā)組織，因此以它為基準來衡量Ajax的能力是非常危險的。不要忘記，Google（明智地）只有為黃金時間做好準備后才會發(fā)布自己的新應用程序，因此我們只看到了成功?？梢酝茰y，即使是Google 的天才們偶爾也會在應用 Ajax 時失敗，我們只是不知道這些失敗而已。

純 Ajax/REST 是一種新的架構風格，相對于諸如 JSP（JavaServer? Page 技術）和 PHP 等較為成熟的Web 應用程序風格來說，它仍然很難實現(xiàn)。除非提供下一代的 Web 用戶經驗是主要需求，而且還有世界級的 Web 開發(fā)團隊，否則您的組織最好像Netflix 一樣最初 “小規(guī)模地采納 Ajax”，而不是像 Google 一樣 “大規(guī)模地采納 Ajax”。

評估 Ajax 能為您達成目標帶來怎樣的幫助

問問自己，Ajax 編程風格有哪些特征使它對于您的應用程序的需求具有吸引力。您的公司正在尋找響應性更高的 UI能提供的生產力增長點嗎？您希望部署一個高度動態(tài)和個性化，又具備可伸縮性的應用程序嗎？對于您的目標客戶群來說，“酷”會成為一種具有差異化優(yōu)勢的特性嗎？所有這一切都是合理的理由，還有些其他方面的理由。關鍵在于，您必須能夠找到一個合情合理的采納 Ajax的理由。下面是 Ajax 可以很好地實現(xiàn)的 3 種功能：

• 響應性更好的 UI。 在傳統(tǒng)的服務器端 Web 應用程序中，任何與服務器的交互都要求刷新頁面，這意味著這中間需要 2 到 5 秒的延時，還要刷新整個頁面。Ajax 使用戶可以與服務器通過 “fire and forget” 的交互方式來與服務器交互：用戶執(zhí)行一個操作，系統(tǒng)可以在后臺處理該任務，同時用戶可以繼續(xù)處理其他任務。UI 只需要更新有新信息要顯示的部分即可，而不用重畫整個頁面。如果一切順利，Ajax 風格的 UI 可以讓用戶實現(xiàn)并維護這種流程，從而提高用戶滿意度和生產力。
  
  
• 迷人。對于那些對外的應用程序和產品來說，只實現(xiàn)需要實現(xiàn)的功能已不足以使之成為一種好產品。您的客戶現(xiàn)在 有著太多的選擇。您需要一種產品來吸引用戶，并使他們?yōu)橹?。就像諺語所說的那樣，“性感就是一種特質”。這并不是說需要將開發(fā)人員可以想像到的所有鈴 聲和鐘聲都包含在其中 —— 看一下最低配置設計的 iPod 是如何擊敗那些具有 10 倍控制功能的便攜式音樂播放器就能明白這個道理。問題的關鍵是提供一種包含眾多細微特性的一流設計，幫助用戶以一種輕松愉快的方式來完成自己要做的事情。

  Gmail 是一個很好的例子。從外表上來說，Gmail 只不過是另外一個基于 Web 的 e-mail 應用程序，這種技術已經存在 10 年之久了。但是 Gmail 使用 Ajax 做了一些正確的事情。您之前曾經由于意外地關閉瀏覽器而丟失過未發(fā)送的 e-mail 消息嗎？Gmail 開發(fā)人員仔細考慮了這個問題，通過精心設計，差不多每分鐘都會將未發(fā)送的消息的一份副本保存到草稿文件夾中。每次都要查找隨時都會使用的 e-mail 地址是不是很煩呢？Gmail 開發(fā)人員仔細考慮了這個問題，基于以前發(fā)送的 e-mail 消息提供了一種精心設計的地址補全算法。

  “迷人” 對于外部及商業(yè)應用程序來說非常重要，但是對于內部業(yè)務應用程序來說則沒這么重要。一切取決于環(huán)境。

  
  
• 不犧牲可伸縮性的個性化。在過去的十五年中，隨著傳統(tǒng)服務器端應用程序朝著更加動態(tài)化和個性化的方向不斷發(fā)展，開發(fā)人員和中間件也越來越多地向在服務器端存儲大量的會話狀態(tài)而努力。這種方式會推動個性化的發(fā)展，但對于可伸縮性來說卻是個噩耗。正如在 第 1 部分 中所介紹的一樣，Ajax 應用程序通常都是將會話狀態(tài)保存到客戶機端，并通過無狀態(tài)的服務與服務器進行交互，這樣可以獲得動態(tài)性和個性化都非常好的 Web 應用程序，而不會犧牲可伸縮性。

決斷

這三方面的收益會幫助您的組織取得成功嗎？如果不行，那 Ajax又提供了哪些其他特別的優(yōu)勢來為您的組織的成功貢獻力量呢？如果您現(xiàn)在還找不到有說服力的具體理由來采用 Ajax，那么我建議您暫時先不要考慮Ajax 了，直到找到這樣一個理由為止。如果您的確有這樣的理由，那么請繼續(xù)閱讀本文。

回頁首

使用 Ajax 獲得成功

您已經確定 Ajax 可以為組織帶來一些獨特的價值，這可以證明為采用這種新興技術而冒的風險是值得的。本節(jié)將討論如何將 Ajax技術成功整合到我們的應用程序和軟件開發(fā)過程中。在下一節(jié)中，我們將討論在 “大規(guī)模采納 Ajax” 技術開發(fā)時所需考慮的一些特殊事項。

從小處入手，獲取經驗，建立信心

對于一種有用的新興技術，沒有什么打擊能比某個項目試圖使用這種技術但卻在眾人的矚目下失敗更嚴重了。這通常是由于尚不具備足夠的技能，卻一次過快地嘗試過多新東西而引起的。但是現(xiàn)在很難找到具有豐富 Ajax 開發(fā)經驗的開發(fā)人員；這種技術還太年輕。

為了解決這個問題，開發(fā)組織應該通過在真正的項目上實施 Ajax 來逐漸積累使用 Ajax的經驗，但是先不要在關鍵特性上嘗試這種技術。集中精力先將一些小特性部署到真實的世界中。從錯誤中不斷學習和調整。如果試圖過早地邁出一大步，那么就會給項目帶來太多風險。這一步邁得越大，經過一個完整的設計/開發(fā)/測試/部署周期所需要的時間也就越長，而這是獲取實踐經驗的關鍵。

這個建議更適用于那些希望 “小規(guī)模嘗試 Ajax” 的組織；不過對于那些希望 “大規(guī)模采納 Ajax” 技術的組織來說，他們也可以通過循環(huán)往復的開發(fā)方式從小處入手，正如我們在 “大規(guī)模采納 Ajax 技術”的特殊考慮事項 一節(jié)中討論的一樣。

找到適當?shù)娜藖碓O計 UI 和開發(fā)服務

設想一下，您的 Web 開發(fā)人員團隊中有些人在過去 10 年中已成功交付了很多 PHP、Java 或 .NET 服務器端 Web應用程序，如果他們可以順利成長為 Ajax 專家，那的確非常令人興奮，但是實際情況可能并非如此。盡管我們仍然在 Web 開發(fā)這個領域內工作，但是Ajax 架構風格和支持技術需要開發(fā)人員忘卻舊知識，重新學習新語言和新模式。這種轉型的確 是可能的，不過需要花費一些時間。

在傳統(tǒng)的服務器端 Web 開發(fā)中，您需要處理鏈接的點擊和表單的提交，并使用一個完整的 HTML頁面進行響應。通常一個工作流都會跨越很多頁面，因此服務器端應用程序邏輯必須維護與瀏覽器之間的會話。服務器必須記住整個應用程序一次次的點擊，這樣在用戶與 Web 應用程序進行交互時，才能提供無縫的工作流。在 Ajax 世界中，我們從這個 “綠色屏幕”模型轉換成了一個真正的客戶機-服務器模型，其中客戶機是有狀態(tài)的，而且是動態(tài)的，服務器只需要負責提供原子的無狀態(tài)服務即可。這種新編程風格要求具備客戶端和服務器端方面的不同技巧。

在客戶端，我們需要那些在長于 CSS、JavaScript 和文檔對象模型（DOM）編程的開發(fā)人員。問題是大部分開發(fā)組織都宣稱“我們具有使用 JavaScript 和 CSS 的經驗”，但那往往是一些微不足道的功能，例如修飾文本和在客戶端進行表單的驗證。認為具有這點JavaScript/CSS 經驗的服務器端 Web 開發(fā)人員可以勝任大規(guī)模 Ajax 應用程序的工作就像是認為會開車的人就有資格Daytona 500 賽事一樣荒唐。

這也是為什么從小處入手如此重要的另外一個原因。我們的 Web 開發(fā)人員現(xiàn)在可能還不具備創(chuàng)建 Gmail 這么重量級的 Ajax應用程序所需要的技能和經驗，不過他們應該可以在現(xiàn)有服務器端 Web 應用程序上實現(xiàn)一些小規(guī)模的改進。隨著時間和經驗的積累，他們逐漸就可以使用Ajax 來實現(xiàn)更加復雜的場景了。

在服務器端，Ajax代表了一種轉換，因為我們可以將一些不引人注目的會話管理和工作流狀態(tài)從服務器上移開了。一旦我們積累了足夠的經驗，Ajax 風格的“有狀態(tài)客戶機/無狀態(tài)服務器” 更容易理解和管理，但是這種架構風格的改變需要一些新的技能。我們的服務開發(fā)人員應該很好地理解 HTTP 協(xié)議，了解TEST 架構風格的知識，并且具備開發(fā)分布式服務的經驗，例如遠程方法調用（RMI）和遠程過程調用（RPC）。盡管 REST 架構風格與 RPC有一些根本性的區(qū)別，但是它們所涉及的一些非功能性的基本準則（邊界安全性、網絡延遲和非可靠性）都是通用的。

使用框架

DOM、CSS 和 XMLHttpRequest（XHR）“標準”與瀏覽器有很大的不同。那些不希望選擇現(xiàn)有框架來解決這些差異的開發(fā)人員可能會花費大量意料之外的時間來編寫自己的信息管道代碼，以便對瀏覽器間的不一致性進行規(guī)范化。您的信息管道代碼的品質在達到目前可用框架已達到的品質之前，需要有很長一段時間。一種可行的框架是開源的 Dojo 工具包（請參看 參考資料）。

學習和使用工具

開發(fā) Ajax 應用程序涉及兩種截然不同的行為：使用 HTML/JavaScript/CSS/DOM 實現(xiàn) UI和應用程序邏輯，以及使用早已建立的服務器端平臺（例如 PHP、J2EE 和.NET）來實現(xiàn)服務器邏輯。在服務器端，可以使用以前一直使用的工具。在客戶端，則需要學習使用一些新工具。對于希望支持的每個瀏覽器，都可能都需要一個不同的 Ajax 工具包。這里有一個通用工具功能的列表（請參看 參考資料 中支持兩種最流行的 Web 瀏覽器 —— Microsoft Internet Explorer 和 Mozilla Firefox 的工具的鏈接）：

• 編寫代碼：編輯器和 IDE。 在客戶機端 Ajax 開發(fā)中，我們需要編寫 HTML、CSS 和 JavaScript 文件的組合。代碼編輯器可以通過語法高亮顯示、語法錯誤檢查以及代碼補全功能來提高我們的生產效率。
  
  
• 檢查結構：DOM 檢查器。由于 Ajax Web 頁面的很多可視化結構都是在用戶與頁面進行交互時動態(tài)創(chuàng)建的，因此為了探索頁面實際的結構，僅僅查看源代碼并不能滿足要求。源代碼很可能與我們所看到的 UI 根本就沒有任何相似之處。我們需要在與頁面進行交互時對 DOM 結構進行檢查。DOM 查看器有一個很好的補足特性是 “實際源代碼” 檢查器，它能對 DOM 當前狀態(tài)的 HTML 源代碼進行反向工程，這樣就可以為那些習慣查看 HTML 源代碼的開發(fā)人員提供一種直觀的手段來了解頁面的內容。
  
  
• 檢查行為：JavaScript 調試器。在編寫一些小 JavaScript 腳本來驗證表單或提供少量交互能力時，大部分開發(fā)人員都可以使用簡單的 alert 語句來定位問題所在。但是當您開始進行大規(guī)模 Ajax 開發(fā)時，就需要為希望支持的每種 Web 瀏覽器來尋找并學習一種 JavaScript 調試器。
  
  
• 檢查客戶機-服務器交互：XHR 監(jiān)視器。 Ajax 工具包最后一個重要的工具是 XmlHttpRequest（XHR）監(jiān)視器。XHR 是一個 JavaScript 對象，它可以與服務器進行 Ajax 風格的遠程通信。XHR 監(jiān)視器使我們可以對請求/響應對進行監(jiān)視，包括它們的頭和內容。

在實際環(huán)境中進行測試

文檔中也明確提到，如果沒有開發(fā)人員的努力，Ajax 會破壞我們對 Web 站點的一些基本期望：例如，后退按鈕、書簽或瀏覽器的“加載” 控件都有可能無法正常工作。我所給出的 “從小處入手” 的建議在這里也能提供一些幫助。只要您只使用 Ajax來實現(xiàn)一些增量新特性，它們只會更新頁面狀態(tài)，而不會對導航或工作流造成影響，那么后退按鈕和書簽都不會有任何問題。但是加載時間可能會成為一個問題，尤其是當我們只在本地開發(fā)環(huán)境上進行測試時更是如此，此時網絡延時并不會成為太大的制約因素。

考慮一下：在傳統(tǒng)的 Web 應用程序中，當用戶點擊一個鏈接或提交一個表單時，即使后續(xù)頁面的加載花費了 10 秒鐘，它們也會從瀏覽器的“加載” 控件中看到即時反饋。在 Ajax 應用程序中，點擊一個可以觸發(fā) XHR 請求的控件并不會激活 “加載”控件。只在本地開發(fā)環(huán)境上進行測試的危險在于：HTTP 請求、響應和后續(xù)的 UI 更新看起來似乎都是即時發(fā)生的，這造成了缺乏瀏覽器 “加載”反饋機制貌似也不是什么問題的假象。但在產品環(huán)境中，用戶距離服務器可能會有成百上千里遠，缺乏這種反饋機制就可能會產生困擾并挫敗他們的信心。用戶可能會納悶：“我點中這個控件了嗎？讓我再點一下看看。仍然什么都沒有！”

遺憾的是，即使您在工程方面作出了最大的努力，網絡延遲依然會存在，因此我們必須接受這個事實。假設有時用戶點擊控件和服務器的響應到達之間存在一些時間的滯后。當用戶作出某種表示發(fā)起一個遠程調用時，瀏覽器會提供一條即時反饋，說明它已經看到了用戶的這個表示。臨時禁用控件或顯示一條消息說明正在發(fā)生什么，直到接收到服務器的響應并使用這些信息來更新 UI 之后才刪除這條消息。網絡調用是瓶頸所在；編寫需要執(zhí)行很長時間的JavaScript 代碼還比較困難。

問題的關鍵是我們需要在真實的環(huán)境中進行測試，此時這些可用性問題都很容易發(fā)現(xiàn)。問題發(fā)現(xiàn)得越早，相應進行響應的時間也就越早。

在真實環(huán)境中進行測試的另外一個方面是要確保在需要支持的每種瀏覽器的每個版本上進行所有的功能測試。例如，如果您聲稱要支持Firefox 1.5 和 2.0 以及 Internet Explorer 6 和7，那就需要在這些瀏覽器上持續(xù)進行測試?；蛟S這是顯而易見的道理，但開發(fā)人員卻很容易陷入一些懷習慣：只在自己喜歡的瀏覽器上進行開發(fā)和測試，以后在其他瀏覽器上發(fā)現(xiàn)問題時就會需要重新修整自己的代碼。

回頁首

“大規(guī)模采納 Ajax 技術” 的特殊考慮事項

盡管我們已經建議您不要去嘗試創(chuàng)建像 Gmail 或 Google Maps 那樣龐大的 Ajax應用程序，但是有些業(yè)務或者工程代理可能會迫使您那樣做。我們的第一反應是：不要這樣做 —— 從小處入手，不但積累經驗。但是如果立即就要構建一個純Ajax 應用程序，就請繼續(xù)閱讀本文。

關于人員

您的開發(fā)團隊現(xiàn)在就更加重要了，因為您不是簡單地使用新技術來擴展久經驗證的架構，而是要采用一個全新的架構。您的團隊雖然在 Ajax 方面的經驗很少，但需要作出一些重要的決策 —— 這些設計決策可能會導致可怕的錯誤后果。

您需要一些在 JavaScript/DOM 和 CSS 方面具有豐富經驗的成員。如果沒有豐富 JavaScript經驗的人，就要尋找一些在其他腳本編程語言（例如 Perl、Python 或 Ruby）方面具有豐富經驗的人。Lisp 或 Scheme等功能編程語言方面的經驗也會很有幫助，但經驗豐富的 Lisp/Scheme 程序員可能比熟練的 JavaScript 程序員還要稀少。

不要低估良好的 CSS 對應用程序品質的重要影響。缺乏對 CSS 的深入理解可能會導致一些原本不必那樣糟糕、難以維護的代碼，這會使得首次或再次重寫代碼更加困難。

重新編寫？你說什么？

規(guī)劃重新編寫 …… 至少兩次

每當您進行新領域的開發(fā)工作時，第一次就可以做出正確決策的可能性很小。您可能會腳步蹣跚地弄出一些難經推敲、滿是缺陷的設計，也可以先從小處著手，然后隨著不斷學習新知識并獲得哪些能做哪些不能做的經驗之后，再不斷更新設計。

Ajax 提出了一項獨特的挑戰(zhàn)，因為用戶經驗和底層架構模式與服務器端的對應部分有著很大的區(qū)別。在您的 UI中，可能會發(fā)現(xiàn)一些細微但有持續(xù)性影響的瑕疵：后退按鈕并不能像如期工作，當用戶調用遠程操作時沒有太多反饋，等等。遺憾的是，在具備這方面的經驗并明白必須修改設計中的哪些地方以便修復這些問題之前，您很難為這些問題設計解決方案。

希望重新編寫自己的應用程序的另一原因是在您獲得使用 JavaScript/DOM 和 CSS經驗的同時，您會發(fā)現(xiàn)一些新術語和模式，它們可以帶來更加簡明、可讀性和可維護性更好的代碼。另外，隨著您編寫的代碼越來越多，您就可以開始著手解決一些通用的問題，盡管這些問題的通用性還不足以進入第三方的框架，但卻足以放入我們自己的庫中，而不是到處散落于頂層的代碼中。重構原來的代碼從而使用新的庫代碼，這樣從長遠來看是值得的，不過需要花費一些時間，而且這種活動需要不斷進行下去。您會發(fā)現(xiàn)，自己逐漸進入了框架領域，這里又有一些自己的問題集。

謹慎進入框架領域

隨著您在大規(guī)模應用程序中取得不斷進展，就會發(fā)現(xiàn)，很多通用應用程序服務都不是由純粹的 JavaScript/DOM/CSS 或全新的Ajax 框架（例如 Dojo 和Prototype）提供的。您要嘗試創(chuàng)建自己的框架級的代碼來簡化新應用程序級功能的創(chuàng)建。這通常不是什么壞事；大部分最好的開發(fā)框架（例如 Rubyon Rails）都已經從具體的應用程序需求中提取出來了。但是務必謹慎；我已經警告過，在小范圍內采納 Ajax 是可行的，但是大規(guī)模采納Ajax 會非常困難 —— 難度可能會高出一個數(shù)量級。支持大規(guī)模采納 Ajax 的設計框架級技術的難度又會高出一個數(shù)量級，尤其是在您剛剛接觸Ajax 技術領域時更是如此。

框架代碼引入了更多層次的抽象和間接調用，這使得代碼路徑很難理解。經驗之一是盡可能在具體的應用程序層進行工作，只有在應用程序中至少有 3 個部分都可能會使用代碼所提供的功能時，才考慮將部分代碼移動到一個框架和可重用的庫中。

迭代，迭代，迭代

新領域開發(fā)中的一個主要的反模式就：在最初設計和實現(xiàn)一個真正的用戶可用并可提供反饋意見的小產品之間需要花費太多時間。因此，在您著手實現(xiàn)大型的新 Ajax 應用程序之前，應該先在幾周之內提供一個基本可以工作的展示模型，以便讓用戶開始提供反饋。UI可能還非常原始，代碼也許并不完美，但如果您在讓用戶體驗新應用程序之前先花費 6 個月的時間進行開發(fā)，結果也是這樣；惟一的區(qū)別就是，要丟棄的代碼和UI 都要多上 10 倍。

您需要在很長的設計周期中加速循環(huán)過程，使真正的用戶一直在一個仿真產品條件的環(huán)境中體驗產品。這種方法的最高境界是搭建一個測試服務器，開發(fā)人員每隔幾天就在上面更新代碼，這樣用戶和項目主管就可以體驗新產品并提供反饋了。

回頁首

結束語

采納 Ajax技術最大的風險是目前業(yè)界普遍缺乏實踐經驗。由于這個原因，我建議您從小處入手，讓開發(fā)團隊開始積累經驗并培養(yǎng)自信，這樣就不會給項目造成太大的風險。如果您決定，現(xiàn)在就集中精力投身于純 Ajax 設計，那么請現(xiàn)實一點，應該理解，這種方式的成功幾率很低。除非您擁有世界級的 Web開發(fā)團隊，以及可以支持迭代開發(fā)和實驗的開發(fā)組織，否則很可能要失敗。

不過隨著時間的推移，事情會變得越來越簡單，風險也會越來越低，因為越來越多的實踐者會不斷積累經驗，新的框架、工具和最佳實踐也會不斷涌現(xiàn)。Ajax 會變得更加安全，也會成為更普及的技術 ……. 不過這個階段可能不會在短時間內到來。

致謝

非常感謝 Rational 組的同事 Erich Gamma、Grady Booch、Josh Staiger、Pat Mueller 和 Scott Rich 與我分享他們的觀點并為本文提供反饋。

參考資料

學習

• “Ajax 和 REST, 第 1 部分”（Bill Higgins， developerWorks，2006 年 10 月）：學習 Ajax/REST 架構風格為 Web 應用程序所帶來的收益。
  
  
• “Debug JavaScript in Internet Explorer”：有關 Microsoft Script Editor 的 how-to 信息，這是隨 Microsoft Office 一起發(fā)行的一個附件。
  
  
• Ajax Design Patterns （Michael Mahemoff，O'Reilly， 2006）：Mahemoff 編寫的有關 Ajax 測試的一章內容很好地總結了 2006 年 Ajax 單元測試的狀況。
  
  
• 請訪問 作者的 blog。
  
  
• Ajax 資源中心：這是 developerWorks 所有關于 Ajax 的資源的中心。
  
  

獲得產品和技術

• Dojo Toolkit：Dojo 是一個開源的 Ajax 框架，它有一些庫來幫助實現(xiàn)模塊管理、事件處理和遠程通信。Dojo 的包管理系統(tǒng)讓我們可以簡化編譯和部署定制 Ajax 代碼以及所需 Dojo 部分的過程。
  
  
• Aptana：Aptana 是一個開源的以 JavaScript 為基礎的 IDE，它針對很多平臺具有很多不同的版本。
  
  
• Eclipse Ajax Toolkit Framework（ATF）：ATF 提供了一個集成的 Ajax 工具包，包括 DOM 檢查器，XHR 監(jiān)視器，以及 “查看實際源代碼” 的功能。
  
  
• FireBug：FireBug 與 Firefox 相集成，提供了錯誤控制臺、DOM 檢查器和 XHR 監(jiān)視器。它也包含 “查看實際源代碼” 的功能。
  
  
• Venkman Debugger：一個為 Firefox 編寫的 JavaScript 調試器。
  
  
• Internet Explorer Developer Toolbar：為 IE 設計的 DOM 監(jiān)視器和其他工具。
  
  
• LiveHTTPHeaders 和 TamperData：為 Firefox/Mozilla 設計的 XHR 監(jiān)視器。
  
  
• Fiddler 和 HTTP Analyzer：為 Internet Explorer 設計的 XHR 監(jiān)視器。
  
  

討論

• Ajax 論壇：如果有關于 Ajax 開發(fā)的問題，那么這個由 Jack Herrington 維護的論壇可給您提供幫助。