擔心未來的 REST 怪物正在形成 (2007.8.28)

REST 的最大價值，在於它的簡約；只要遵循上回帖子中提到的幾個基本原則，便可直接充分利用 HTTP 和 Web 伺服器先天具備的架構優勢，包括 GET 的請求會被 Web 伺服器有效地快取，和因不需要維繫各別的會話狀態，而達到非常高的伸縮性。Google 和 Amazon 等所提供的 Web services，是最好的明證。這是 REST 的擁護者津津樂道的論點。

但如果照目前的氣氛繼續發展下去，過分炒作“REST 是比 SOAP 更適合於 SOA 的技術實現手段”、“SOA 未來的希望在 REST”這類危險的觀念（上回談的主題），其最終的結果，可能是既傷害了 REST，又對 SOA 沒好處的雙輸局面。

此話怎講？

目前一般認定的（企業級） SOA 服務，必須具備讓有興趣想呼叫該服務的消費者，自動發掘確切的服務端點、介面、和 XML 的 schema 結構的能力。在經常被引述、由Thomas Erl 所列的 SOA 八大原則中，便包括了 Discoverability 這條。此外，InfoQ 的 SOA 十大原?中的第三和第七個原則，也都與此相關（附帶一提，關於這個“十大原則”，我認為它愈到後面，愈有畫蛇添足的感覺，尤其是最後三條）。

不同於 SOAP，RESTful 形式的 Web services 是沒有信封機制，只有赤裸裸的 payload，而 payload 的內容，往往是 POX (Plain-Old XML)，當然也有人使用 JavaScript. 物件表述 JSON。僅單就 XML而言，如果光是一個 instance，是無法確定其確切的 schema 結構到底是什麼樣子的。RESTful 的 Web services 先天上既缺乏像 SOAP 那樣的一套信封 header 機制，可以用來註明相關的後設資料，如 XML schema，又不像 SOAP 還有一個WSDL 搭檔，來描述各種和服務相關的後設資料，因此無法滿足上述的 discoverability 原則（有些嘴硬的 REST 擁護者說可以通過 MIME type 來表述服務的後設資料，但此說實在過於牽強）。當然，只要服務供應者通過網站釋出清楚的服務 API 描述，通過事先的設定，RESTful 的 Web services 同樣可以圓滿達成任務，這樣的例子在Web 2.0 的世界太多了，只是說，這樣的服務，缺乏一套讓消費者自動探索的機制，藉此利用自動化的工具，方便服務的組裝和開發。

不意外地，隨著 REST 的發燒，愈來愈多人探討 REST 是否也像 SOAP 一樣，需要描述語的問題（例如這裡和這裡）。WADL 正是為滿足 discoverability 需求下的產物。Sun 更已經把它納入新的 JAX-RS 的一部分（關於 WADL，這兒有篇不錯的簡介）。有人批評 JAX-RS，指出它是想像 JAX-WS 之於 SOAP 那樣，把根源於 CORBA IDL 和 Java interface那套物件導向的程式設計機制和架構，硬套到 REST 上。但如上次帖子裡談到的，REST 的應用設計理念和這樣的作法，將格格不入。換句話說，它將不當地鼓勵開發人員把 REST 當作“只不過是另一種 SOAP”來看待，而完全忽視 REST 的設計理念。REST 原始的精神和價值，將因而蕩然無存。

除了 WADL 之外，如果 RESTful服務需要註明各種需要強制的服務戰略 (policy)，像服務水平、安全（身分認證、加密、簽名...），另外像可靠性、交易等屬性，是不是也需要有一個像 header 的地方，來放這些屬性？按照這個趨勢繼續發展下去，有什麼可以阻擋支援 REST 的大廠們，把它變成另一個 SOAP的？

還記得 SOAP 的誕生，最早可追溯到 Dave Winer 和 Don Box 等最早發展 XML-RPC 的那段歷史嗎（可參考 Wikipedia 的記載）？自從 SOAP 的發展從 RPC 導向轉成檔案導向，複雜度升高後，XML-RPC 的創始人 Dave Winer 因種種因素，遂轉而去發展 RSS。我還記得約九年、十年前，RSS 還在 1.0 版本時，一般認定 RSS 的全名為 "Rich Site Summary" 或 "RDF Site Summary"。但自 Winer 氏積極參與 RSS 2.0 的制定後，開始將 "RSS" 用來代表 "Really Simple Syndication"。從他對 "RSS" 三個字母所代表的意涵詮釋上，便明確顯示出其對“簡約”的強調。

隨著將 REST 用於企業級 SOA 應用的聲浪，REST 看來將承受愈來愈重的包袱，WADL 規範的推出，只不過是冰山的一角。我們必須好好問問，讓 REST 重演當初從 XML-RPC 一路到 SOAP 1.2 的複雜化歷史，是否具備充分的正面意義？ 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16186206/viewspace-548721/，如需轉載，請註明出處，否則將追究法律責任。