架構妄想：AJAX + REST

標籤：blog   http   使用   java   ar   strong   檔案   資料   問題   

　　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

架構妄想：AJAX + REST