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

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

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

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

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

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

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

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

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

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

　　查看英文原文：Architectural Mirages

it知識庫：架構(gòu)妄想：AJAX + REST，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。