1）AJax是一個想法，而不僅僅是一個縮略詞
盡管AJax通常被拼寫為“異步JavaScript和XML”，但這個全稱不完全合適，因為它過分簡化了這門技術的歷史和實現核心。更確切地，Ajax包含了一種思想，這種思想認為網絡應用可以退出傳統的以服務器端為中心的重復發送-等待循環方式來建立。Ajax使網絡應用轉向更有影響的、連續的，而且漸進式的更新。AJax為用戶優先的體驗網絡應用提供了更豐富、更好的交互性。這個優勢也意味著需要網絡專家更多的網絡控制和安全監視，潛在地，服務器和網絡改造也是這樣。
2）這確實都與JavaScript有關
AJax的應用是用Javascript寫的，通常基於XMLHttpRequest對象來通信，這個XMLHttpRequest對象是通過萬維網協議過程進行的。由於像大多的網絡技術一樣，它現在只是一個特定的工業標准，因此在不同浏覽器中實現的顯著差別還是可以找到的。不管有沒有廣泛的工業支持，它也可能使用其它的數據傳輸機制，包括傳統的框架和image-cookIE方法，以及Flash或Java中二進制橋的使用。
無論開發者使用哪種傳輸方法，AJax都將Javascript在網絡應用中提升到了一個前所未有的重要地位。現在JavaScript對重要的數據收集、數據通信、消費機制都有影響，所以它不再被認為是沒有重大作用的二級網絡技術。
認為Javascript技術有毒的開發者們試圖使用工具或框架產生其它的語言如Java（如谷歌網絡工具）來避免使用這種語言，或者在組件或標簽後隱藏代碼（例如.Net和Ruby）。然而最終，Javascript仍會在應用中。最好是理解並學會直接使用它，因為只要你使用AJax，你就使用了很多的JavaScript。
AJax是內嵌在網絡中的，所以壞代碼對網絡管理員和開發者來說意味著大量的故障修理，底線是鼓勵好的、有網絡意識的編碼。用於其他語言的具有同樣組織的“規則和工具”——代碼規范、測試機制和源碼控制也必須應用於JavaScript，以此來確保AJax的可支持性和健壯性。
3）XML是不需要的
盡管縮略詞中有“x”，但是AJax並不需要XML。XMLHttpRequest對象可以傳輸任意的文本格式。對於很多AJax開發者來說，作為一種數據格式JavaScript對象符號甚至是純Javascript代碼段更有意義，因為JavaScript是消費環境。有的開發者喜歡以純文本或Html代碼段做為網頁的輸入，也有的使用像不太著名的YAML標記語言或逗號分隔值這樣的數據格式。
當然，使用XML是可能的也是應當的，只是不是必需的。XMLHttpRequest對象不支持使用二進制格式上傳文件，但是考慮到Flash使用一種叫做活動消息格式（Action Message Format）的二機制格式，所以在AJax應用中也可能很快地找到類似的性質。你應該知道網絡中的哪種機制正在被網絡淘汰，因為淘汰的不總是XML，也要確保能夠分析出這些機制的性能和安全性。
4）為HTTP請求的增加做好准備
對網絡管理員來說，支持Ajax應用最明顯的問題是結構化編程方式使網絡應用的使用從只有幾百KB的某些不頻繁響應的程序組變為更多連續的小型HTTP請求交換。這意味著網絡綁定的網頁和應用服務器會發現他們比以前更繁忙。AJax將為服務器和網絡應用做些什麼取決於這些應用是如何建立的——開發者們一定要明白他們使用的應用間的網絡沖突。
5）仔細地優化AJax請求
網絡應用應該堅持發送更少的數據、更少的發送次數的網絡傳輸規則。但是這也不是說這種規則被開發者們廣泛地遵循。對網絡來說很幸運的是， Ajax響應的HTTP壓縮可以減少響應尺寸，並且在所有現代的浏覽器中都支持。但是由於動態壓縮的額外開銷，如果響應相對較小速度也不會改變太多。這也就是說，對網絡管理員來說在服務器端打開壓縮機制是明智的，但是需要明白的是，使用AJax應用不會比使用傳統的網絡應用獲得的更多。
我們一般使用緩存來減少發送數據的次數。但是，盡管由浏覽器提供的特定假設不會在同一段時間裡再次獲取URL，大多數的Ajax實現還是公開敵視緩存。許多AJax開發人員不是使用緩存，而是通過頭設置或URL的唯一性來積極地戰勝緩存。
用JavaScript寫的客戶端Ajax緩存使得對付緩存成為可能，但是大多數的Ajax庫不執行這樣的功能。網絡專家應該為開發者們展示緩存的好處，因為AJax使用緩存的好處要比使用壓縮多得多。
6）認識到兩個連接限制
Ajax應用向同一個URL發送兩個同步的連接是受HTTP限制的。這是HTTP協議的設計方式，不是什麼浏覽器問題或浏覽器限制。好消息是，它使許多Ajax開發者遠離了服務器的突然崩潰，盡管微軟的Internet Explorer 8被認為在這種限制之外運行得很好。非正式的AJax應用可能是麻煩的，隨著浏覽器不斷地改變規則，網絡管理員們應該隨時關注提出請求的數量，跟應用開發者們一起避免像快速投票（fast polling）或長期持有連接這樣的設計模式。
7）小心響應順序
在傳統的網絡應用中，TCP/IP通信協議的網絡影響——如HTTP響應接收的缺乏秩序，通常不被開發者和使用者所注意。基礎單元、Html文件在其他對象之前被接收，接著就觸發請求。任何接下來的請求都觸發整個新的基礎文件，從而保證順序。Ajax將這種固有的順序摒除了，但是，由於這樣，基於一定順序的應用需要一個響應隊列。但Ajax框架並不始終理解這個相關網絡。因此，再一次地確認AJax應用的開發者們了解這些相關的網絡級別。
8）理解“層8”糾錯的影響
多年來，用戶們一直都是通過重載頁面或按“後退按鈕”來糾正網絡傳輸質量。簡而言之，用戶這樣做有助於減輕網絡問題，因為錯誤一般發生在預期的頁面繪制之間。但是，通過AJax應用錯誤不再那麼明顯。可糟糕的是，由於簡單的、動畫的GIF旋轉循環提供的正確的請求狀態信息很少，用戶經常將錯誤誤傳。
開發者們很煩惱，因為許多庫在認識到發生了超時時不再響應，一定發生重試，而且服務器錯誤和數據錯誤會突然出現。因為JavaScript檢測顯示的通信和代碼錯誤很少出現在客戶端，所以（使用戶）無憂的無知是一種規范。為了使管理員正確地使用AJax，更多的應用級監控是必需的。
9）舊的安全威脅被二次曝光
如果你聽信專家的，Ajax可能會顯現得產生更多的攻擊頁面，但是事實是它不會比傳統的網絡應用開發環境更不安全，因為傳送給可信任的服務器的HTTP輸入——頭消息、檢索字符串和消息體是一樣的。如果在你的網絡開發組可信任的客戶端代碼和輸入數據不被暗地裡禁止，那麼AJax將會使事情朝著那個方向推進。
跨站點腳本（XSS）不是在AJax中的一個新的脆弱點，它只是在JavaScript中更常見，尤其當應用允許使用規定（state）數據時。
跨站點請求偽造物也不是在Ajax中的新現象，但是如果應用開發者們不適當地檢查在AJax應用中的HTTP 引用（原文如此）頭和管理session，將是為偽造物們開了門，盡管可能現在更糟糕了。
黑客，像開發者們一樣，現在更感興趣於使用和濫用增加了潛在漏洞的JavaScript。網絡專家們應該確定開發者們意識到了即使客戶端代碼在適當的位置混亂也可能被利用，所以不管是不是AJax數據輸入始終都要被過濾和殺毒。
10） 遵守相同的起始地址做為保護
在安全的積極方面，JavaScript的SOP（同一起始地址策略）被完全地強迫應用在基於XMLHttpRequest的Ajax應用中。這個策略確保了腳本不能跟自己發行的以外的域進行通話。從開發者的觀點，這也是讓人非常煩惱的，因為這意味著來自ajaxref.com的網頁服務不能跟來自www.AJaxref.com的URL進行通話，盡管這是同一台服務器上的，但它們不是同一個域。DNS匹配跟這個沒關系，這是用於SOP的字符串檢查。
SOP也會嚴重的束縛開發者在客戶端努力進行網絡服務的能力。顯然，最好的方法是在服務器端使用代理來響應發送給其他服務器的請求並將這些結果組合起來。但是許多AJax開發者們試圖打破這個同一起始地址的限制。使用《script》標簽來代替XMLHttpRequest對象作為傳輸引入了危險的信任假設，而且導致了關注整個AJax安全的開始。
現在，隨著像Firefox3和IE8這樣使用自己的跨域請求工具的浏覽器的出現，更多的麻煩肯定即將來臨。像Java的安全砂箱概念的情況似的，SOP限制被引進只是避免開發者們破壞安全。繞過這些安全措施要極為謹慎。
最後，請明確你的需求，注意你想要的是什麼。
通過Ajax，豐富的應用界面工具集將贏得一個項目，但是壞的配管系統可能會搞垮它。如果一個豐富的Ajax應用的約定在偶爾很脆弱的網絡環境中傳輸，那麼用戶會對察覺到應用的不穩定感到很失望，盡管它有華而不實的界面。為了實現桌面式的品質，網絡專家們必須關於特定的網絡和安全原理對AJax開發者們進行培訓，並且提供一個固定且連續的監控傳輸平台，這個平台包含JavaScript機能和來自用戶感覺的網絡性能的客戶端檢測。用戶們看到的豐富的網絡應用通常使用正常——例如像那些來自Google的網絡應用，如果不這樣將是冒險的努力。