REST 是好東西，但受到兩個問題的拖累。
之前已經寫過一些對 REST 的簡介和看法。不久前恰好又在中文版的 infoQ 網站上看到一篇剛翻譯成中文的文章，發現一些問題，於是又把整個 REST vs. SOAP 的論戰再仔細看過一遍，刀光劍影，娛樂性十足。好訊息是，最近這幾個月，比較聳動或炒作性的 REST 話題似乎開始從網站、雜誌頭版消失。就來回顧和總結一下，事情其實很簡單，REST 是被兩個問題給害了。
一是對 REST 技術本質的混淆，許多實作方式，號稱是 REST，但其實不夠格。這個比較容易解決。舉例而言，infoQ 中文站今年一月剛發佈一篇翻譯自這篇 2006 年 5 月的文章（不推薦）。但不幸的是，作者選擇將 POX (Plain Old XML) over HTTP 的實作方式，冠上 REST 和 RESTful 的封號。但看看作者天氣查詢的例子，最諷刺的是，如果看它採用的 XML 輸入、輸出格式，和用 HTTP POST 的互動方式，活像是個 SOAP-based 的 Web services － 只差沒用 SOAP 信封格式將輸入、輸出檔案包裝起來。至於該 Web services 採用諸如 http://x.com/weather/WeatherQuery/2.0
這種統一 end-point URI 網址的設計，更是犯了 REST 的大忌。真正合格的 REST 設計，就拿相同的天氣查詢做例子，服務呼叫（消費）端應該可以直接 GET 一個像
http://x.com/weather/city/chicago
或
http://x.com/weather/zip/60661
這樣的獨特網址，無需另外將參數透過輸入檔案，就能夠獲取查詢結果。
我們真正需要的，是更多像 Stefan Tilkov 這篇正視聽的 REST 教學（中文版：深入淺出REST）。另外，我發現 Wikipedia 中對 REST 和 RPC 所作的比較，也非常有幫助，能夠讓習慣 OO 的開發人員快速體認到 REST 的設計哲學。在另一篇 infoQ 的文章中（同樣推薦，但沒看到有中譯），作者探討 REST 的 URI 超鏈結設計原則，並指出連 Flickr 等大站的 REST API，都看得到關於這個原則的錯誤示範。
大量似是而非、自封為 REST/RESTful 範例的充斥，混淆了視聽；令人擔心的是，它們會引發「POX+HTTP 是 REST，因此 POX+HTTP 自然具備了 REST 優勢」 的錯誤推論。
來看過去一年 REST 熱潮的第二大問題。這個問題比較棘手。根源在於某些激進派選擇以 REST 單挑 SOAP+WS-*，且帶著漢賊不兩立的互斥、排他心態，來宣揚 REST 理念，彼得雷西 (Pete Lacey) 是其中的急先鋒。正因為對上了 SOAP，企業運算和 SOA 的課題也不免被扯了進來。在 consumer Web 2.0 領域中，用戶量巨大，資訊相對公開，往往不需要如企業領域做到很細微的安控，REST 式的 Web services，過去幾年在效能方面發揮得很出色；此外，簡單易用，讓想開發 mashup 等組合式應用的廣大開發人員，能快速上手。這些都是有目共睹的。但 REST 的成功，邏輯上無法直接引申成 SOAP 的失敗。此外，REST 狂熱者往往以 HTTP 正統自居，認為不遵循 REST 原則和風格，便是對 HTTP 的「濫用」，例如在《深入淺出REST》一文最後，作者就表達了這樣的態度。一位網友 Alex Xu 評得好：
為什麼要把REST跟SOAP對立起來？
JSP,ASP,PHP難道不也是對HTTP的「濫用」嗎？（按照REST的原則）
電話線原本是給電話用的，但是後來人們用它來發傳真，又用調製解調器[modem]上網，再後來ADSL，現在ADSL+.在這種途徑上人們不斷地挖掘潛力.為什麼HTTP就不行呢？
但正因為抱持了基本對立的立場，彼得雷西在這篇專訪中，幾近全盤否定地，一一數落 SOAP、WSDL、UDDI、WS-*，甚至 XSD 的不是。過分膨脹的論點，自然也招來了許多反證。例如 Paul Fremantle 表示據他所知，eBay 的 SOAP 服務每天要處理四千萬的requests，而 Yahoo Mail 基本上也是基於 SOAP，而requests量也不會小。其他像是 SOA 專家 Steve Jones 駁斥了雷西關於解析 XSD 和 XML 檔案格式彈性方面的抱怨。
事實上，將 REST 和 SOAP+WS-* 看作有非此即彼的替代性，不如把它們看作是互補，讓負責實作 Web service 的開發人員自行選擇實作的方式。SOA 的原則本來自當如此 — 由業務分析師和 IT 架構師先識別出服務，以契約（合約）的方式加以規範，而服務契約應該是獨立於任何技術平台或實作手段之上的。接著下來才是討論binding方式、服務介面設計，和實作手段。同樣的一套業務邏輯原始碼，可以根據為滿足契約的實際情況，以多種方式封裝、binding。契約、介面、原始碼實作，乃至於團隊分工方式，都應該是鬆散耦合的。
正如 Steve Jones 在多篇批判 REST 的部落格中指出，更重要的是 IT 要如何更緊密地配合業務的變化，更快地去實作業務能力，這是 SOA 自始至終的目標。至於如何將一個檔案從甲地運送到乙地，方式很多，REST 只不過是 SOAP、REST、JMS、RMI、MQ… 等眾多選擇之一而已，不該本末倒置。
SOAP、WSDL 和幾個主要的 WS-* 標準，多年發展下來，廠商和工具支援已相對成熟。REST 雖然在先天結構上較為簡單，但就像彼得雷西自己在這篇部落格回應中舉的例子，選擇 REST 的開發人員必須評估，在工具、框架支援相對不成熟的情況下，coding 的代價高不高？另外我想到一個普遍的企業應用情境 — 當有安全私密性要求時，REST 應用可以很輕易地搭配 SSL/TLS。但內容一旦加密，許多被 REST 支援者津津樂道，包括能直接利用 Web 現有快取 (caching) 機制的高延展性，便不復存在。有時候，甚至在內容沒有必要加密時，因為必須根據用戶身份權限對內容做過濾、個人化，此時如果採用 REST 和 HTTP GET，還必須確定告訴用戶端和伺服器之間所有行經的 Web 基礎設施不許快取，以免內容讓不該看的人看到（不同於過去清一色 HTTP POST 的request回應，預設的行為本來就不會快取，許多開發人員早已視為理所當然）。在這類情況下，其他剩下來的 REST 優勢（如簡易），是否仍超越採用其他的技術手段？是企業開發人員必須面對的。
有的科技大廠眼見 consumer Web 2.0 地盤長期以來被 LAMP 和 PHP、Ruby、JavaScript、Python 等佔據，除了實驗性地扶植 Groovy、Grails 之類外，現在冒出了這群 REST 激進派信徒，製造出非常戲劇性的衝突，大火既已點燃，豈可不好好利用一下 － 管他是否過分炒作或自我膨脹，先趁勢而上，運用市場機器，加入炒作行列；同時推出一些支援 REST 的理論架構、開發框架、規範、或工具，藉機讓 Java 和 C# 的影響力能擴大到 Web 2.0 領域（包括消費和企業 Web 2.0）。我感覺這是廠商宣佈對 REST 大力支援背後的主要動機（之一）。