REST是否會步SOAP的後塵?

\

看新聞很累？看技術新聞更累？試試下載InfoQ手機客戶端，每天上下班路上聽新聞，有趣還有料！

\

\\

大約在十年前，圍繞基於REST和SOAP的系統曾開展了一系列的討論。有人撰文分析了兩類技術的各自利弊所在，而另有人思考了其中哪類技術更為適用，或是都適用。隨著Web服務趨向於從基於SOAP轉移到REST和HTTP，關注此問題的爭論和討論大都偃旗息鼓了。目前，大多數SOAP從業者已採用REST（或普通的HTTP）作為分散式系統的基礎。然而，近期Pakal De Bonchamp在Medium上撰文“REST是新的SOAP”，將使用REST比喻為一種“精神類疾病測試”。

\\

這篇文章的篇幅很長，內容詳盡。複雜性是文中關注的一個關鍵問題。在作者Pakal看來，對於提供一個簡單的API，使用RPC機制可在“數小時”內完成，但如果使用REST，則可能需要更長的時間。為什麼會這樣？作者給出了一種解釋：

\\

\

（REST）並沒有給出更多的標準，也沒有給出更準確的規範，僅是給出了一種模稜兩可的“RESTful哲學”，趨向於陷入無休止的形而上辯論之中，並採用了大量醜陋的解決方法。

\

\\

REST方法並不能直接對映為CRUD操作。我們該如何確定是否不應重用已有的資源而是需要建立新的資源例項，並且何時可以開始建立？在Pakal看來，HTTP錯誤程式碼提供的資訊十分有限，而且無法表達更豐富的錯誤情況。他繼續列出了更多的問題，最終給出結論：

\\

\

你需要在重新造車輪上花費數個小時，甚至沒有量身定做的適用車輪。你只能使用一個殘缺脆弱的車輪，而且理解這樣的車輪還需要閱讀需要大量的檔案，很有可能在不知深淺的情況下違反了它的使用規範。

\

\\

Pakal在文中深入討論了部分HTTP動詞的細節，其中包括PUT，以及很少為人關注的PATCH的DELETE：

\\

\

你想使用PUT實現資源的更新？那好，但是在部分高高在上的規範中規定了，資料輸入必須與由GET接收的資料表示保持一致。那麼你應該如何處理由GET返回的大量只讀引數（例如建立時間、最後更新時間、伺服器生成的令牌等等）？如果你簡單忽略了這些引數，這是否會違反PUT的原則？無論如何，你應該考慮這些引數。但是如果引數與伺服器端的值並不匹配，是否應期望得到一個“HTTP 409衝突”（強制發出一個GET...）？如果對這些引數隨機賦值，是否應寄希望於伺服器會忽略它們（隱藏錯誤，樂在其中）？如果隨便選定一個引數，顯然REST對只讀屬性是毫無頭緒的，並且這個問題並不會很快得到修正。同時，GET會返回之前由POST或PUT傳送的密碼（甚至是信用卡號），這是很危險的。如果一定要處理這樣的只寫引數，那麼我只能祝你好運了。噢，我還忘了提及，PUT會帶來的一些危險的競爭條件。雖然多位客戶端只想各自更新一些不同的域，但可能會互相覆蓋對方的更改。

\

\\

文中對REST架構理念、錯誤處理及其它許多方面做了詳細的評估，結果差強人意。對於那些REST支持者和不願相信REST不足之處的人來說，這篇文章值得一讀。Pakal最後總結如下：

\\

\

近乎透明的RPC，這才是99%的人真正需要的。儘管現有的RPC協議不夠完善，但是完全夠用。大眾對Web和HTTP最小共同處的偏執喜好，大多導致了在時間和一些灰色地帶上的巨大浪費。REST承諾簡單性，但卻交付了複雜性；承諾穩健性，卻提供了脆弱性；承諾互操作性，卻實現為異構性。REST將步SOAP的後塵。

\

\\

對這篇文章得到了大量的評論。顯而易見，部分人同意Pakal的看法，但是絕大多數人持不同觀點，並指出了Pakal的論點中存在許多缺陷。例如，Filippos Vasilakis評論到：

\\

\

或許你應該看一下Roy的論文（譯者注：指Roy Thomas Fielding，他是REST架構的創立者，也是HTTP協議的主要編寫人。在他個人網頁上提供了博士論文全文）。你所攻擊的，正是一些對REST的常見誤解。正如Roy在論文中指出的，REST可能並不適合所有的情況，但是非常適合於客戶端無法控制的情況。所以，如果你知道任何有其它任何一個模型也是自描述性的、可演化的，請告訴我們。REST具備上述所有特性，可與我們無法控制或不能控制的裝置、客戶端、硬體進行對話。這類似於在Apple Store中的移動應用需要10天才能部署新更改。如果你對應用的更新沒有被Apple公司拒絕，你甚至不能訪問或更新感測器裝置等。類似情況下，我們可以使用REST，乃至最近推出的、依然有很多限制和問題的GraphQL。但如果你想出了另一個能解決可演化性問題的模型，請告訴我們。當然，RPC不算在內。

\

\\

另一個評論來自於Vlad Ko：

\\

\

哎喲，我剛剛讀了些什麼呀！你是在抱怨浪費了時間去架構適用的API嗎？我認為這正是你的責任所在，並且作為一名開發者，目標就是要確保提供適用的API。在光天化日之下，抱怨每一個與REST相關或“無關”的問題，這有意義嗎？太幼稚了～每種語言、協議、規範和概念都存在自身的問題和缺陷，諸如語法不合邏輯、虛擬機器緩慢、缺乏型別支援、過於嚴格、過於鬆散、過於實用、缺乏足夠的OOP，等等。希望你能進入軟體工程的世界看看。

\

\\

Christopher Patti評論道：

\\

\

這是一篇優秀的文章。內容頗具衝擊力，提供了大量有支撐的事實，給出了合理而詳盡的方式去闡明道理。但是，有一個因素在文中並未論及，就是工具。如果正如你在文章中所說，人們放棄了現在是或曾經是邏輯純粹典範的SOAP，這是因為一旦人們並非使用Java或者.NET做工作，這時工具真的是非常糟糕。有人告訴我，工具已經改進了。但是如果人們感到痛苦，那麼他們就會採用新的工具來應對這種痛苦。我認為，你的論點是想說明我們可能選擇了一條不幸的道路，並應該繼續前進，為什麼要這樣做？你引用了其它一些更現代的協議，但是我很好奇的是，你究竟能舉出哪些可直接替代SOAP或REST的具體例子。

\

\\

原文不僅引發了大量直接評論，也在各大社交媒體平臺掀起了軒然大波。最終，WeWork的平臺工程師Phil Sturgeon以“對REST將步SOAP後塵的迴應”為題目撰寫了一篇文章。顯然有很多人希望他能駁斥原文中的觀點。

\\

\

整篇文章充斥著對REST和HTTP的一些常見誤解。儘管我的事業就是通過教育使人們擺脫各種混淆之處，但這些誤解依然影響很深。顯然，這是由於我的聲音不夠響亮，寫得不夠好，或是做得不到位。這是讀者可能會在我的寫作中看到的沮喪感，但並非針對原文作者。

\

\\

和Pakal最初給出的文章一樣，Phil的迴應同樣是長篇大論。Phil詳細迴應了Pakal指出的REST問題。例如，對於Pakal提到建造“殘缺脆弱的車輪”，Phil這樣迴應道：

\\

\

好吧，這是令人沮喪的。REST API往往為人嘲笑，因為支持者解釋說人們不需要依賴於文件。REST API當然不需要文件，但是我用最近幾個月的時間，為我們的API生成文件，因為它們都是RPC API。當一個API表示自身的狀態、使用超媒體宣告其可供性並提供了一個合約時，你可以選擇去生成可讀的文件，但這只是針對那些將REST API作為RPC API看待的人…… REST API的確需要更少的文件，除非你和為數不少的人一樣，只是構建了一個未規範的RPC去冒充REST。

\

\\

Pakal還探討了PUT等HTTP動詞中存在的風險。“聽起來，這應該是由於不瞭解PUT的目的，進而產生的一種挫折感\"。Phil的剖析和迴應內容很長。實際上，即使沒有閱讀Pakal的原文，Phil的迴應也值得一讀。總而言之，文中的觀點是，Pakal對REST抱怨的絕大部分（即使不是全部的話）是由於他的誤解所致。Phil總結道：

\\

\

我知道REST十分複雜。太多的人誤以為自己理解了這個問題。一旦他們遇到了不瞭解的情況，就會給出錯誤的評判。世界各地的人們都在構建REST風格的API，這些API基本上只是“RPC+HTTP動詞+一些漂亮的URL”。這看起來並不是很有幫助，所以他們大書特書，解釋為什麼這樣做不是很有用……

\

\\

事實可能的確如此。但Phil和Pakal的爭鳴似乎還在繼續，因為我們看到Phil又進一步更新了討論情況。

\\

\

我依然在與作者進行著富有成效的對話，幫助他了解REST的工作機制。我想各位可能也會對此感興趣。

\

\\

歡迎各位有興趣的讀者圍觀，瞭解討論的進展情況。

\\

檢視英文原文： REST is the new SOAP?