William Vambenepe的最新文章，AJAX + REST是最新的架構妄想，讓我們回想起了一個具有15年歷史的架構，它曾被寄期望對Web產生革命性的影響。

在該架構里，Web服務器將返回包含全部數據的XML文件，與XML一道，還會返回一個XSLT文件（用于描述如何將XML轉換成HTML）。瀏覽器將依此處理XML數據，顯示最終的HTML。搞定！該方式將帶來很多好處，優于老式的“服務器生成HTML”模型。XML可以被其他應用方便地使用（不僅僅是人類），不同的XSLT可被用來將內容適配到各種客戶端平臺。

　　光陰飛逝，但這種理念其實從未真正實現。現在，我們又快速地轉向Ajax：

XML文檔還在，盡管它通常被稱為JSON。XSLT現在則是一大堆JavaScript。比起XSLT模型，這種模型有許多優勢……它更靈活，可以實現小規模更新，以及部分頁面刷新等等。但是，它是否也能夠讓架構保持清晰，使數據API與表現邏輯相分離呢？

　　Vambenepe解釋了原因，盡管它看上去優雅并包含了所有的架構優點，但該模型在大多數情況下并不實際：

相同服務的客戶端支持多種交互模型，若不無限制的蔓延開來，單個API很難滿足所有這些模型的需要（這里，所謂“單一API”，其實就是一塊遮羞布）。但若是想讓API保持外觀簡潔，你最終可能就會得到交互頻繁的應用。

　　但是在Vambenepe看來，這僅僅是該方法諸多問題中的一個。他指出的另一個大問題是該方法的事實：

……摒棄集成了瀏覽器代碼和服務器代碼的架構……不是所有Web開發者都認為他們的客戶端框架和服務器框架是兩套工具。將它們整體作為一個預先裝配好的工具使用或許不會得到最優的代碼，但可能還是可以最優利用你的開發資源。

　　盡管Vambenepe有強有力的論據，他的帖子還是遭到了質疑。什么才是正確之路？為現有UI（如GWT風格）創建/生成單獨的REST API？一方面，這種方法簡化了UI實現；另一方面，每個UI都要有一個新API。這種方法的伸縮性更好嗎？哪個代價更高？實現UI集成，還是后端API？由這個帖子還產生了另一個更嚴肅的問題：什么是正確的設計方法？先實現后端API，然后設計多個使用它的UI；還是開始從UI開始設計，然后再定義支撐它的API？傳統來看，API實現的代價似乎更高，但API本身要比UI更穩定。

　　因此，沒錯，滿足各種需求的單一API看起來是架構妄想。但是，一組設計良好、輕巧可重用的API可被用來作為許多UI（Ajax）實現的基礎。

　　查看英文原文：Architectural Mirages