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

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

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

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

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

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

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

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

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

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

　　查看英文原文：Architectural Mirages

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

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