RESTful Web 服務使用標準的 HTTP 方法 (GET/PUT/POST/DELETE) 來抽象所有 Web 系統的服務能力，而不同的是，SOAP 應用都通過定義自己個性化的接口方法來抽象 Web 服務，這更像我們經常談到的 RPC。例如本例中的 getUserList 與 getUserByName 方法。
RESTful Web 服務使用標準的 HTTP 方法優勢，從大的方面來講：標準化的 HTTP 操作方法，結合其他的標準化技術，如 URI，HTML，XML 等，將會極大提高系統與系統之間整合的互操作能力。尤其在 Web 應用領域，RESTful Web 服務所表達的這種抽象能力更加貼近 Web 本身的工作方式，也更加自然。
同時，使用標準 HTTP 方法實現的 RRESTful Web 服務也帶來了 HTTP 方法本身的一些優勢：
無狀態性（Stateless）
HTTP 協議從本質上說是一種無狀態的協議，客戶端發出的 HTTP 請求之間可以相互隔離，不存在相互的狀態依賴。基於 HTTP 的 ROA，以非常自然的方式來實現無狀態服務請求處理邏輯。對於分佈式的應用而言，任意給定的兩個服務請求 Request 1 與 Request 2, 由於它們之間並沒有相互之間的狀態依賴，就不需要對它們進行相互協作處理，其結果是：Request 1 與 Request 2 可以在任何的服務器上執行，這樣的應用很容易在服務器端支持負載平衡 (load-balance)。
安全操作與冪指相等特性（Safety /Idempotence）
HTTP 的 GET、HEAD 請求本質上應該是安全的調用，即：GET、HEAD 調用不會有任何的副作用，不會造成服務器端狀態的改變。對於服務器來說，客戶端對某一 URI 做 n 次的 GET、HAED 調用，其狀態與沒有做調用是一樣的，不會發生任何的改變。
HTTP 的 PUT、DELTE 調用，具有冪指相等特性 , 即：客戶端對某一 URI 做 n 次的 PUT、DELTE 調用，其效果與做一次的調用是一樣的。HTTP 的 GET、HEAD 方法也具有冪指相等特性。
HTTP 這些標準方法在原則上保證你的分佈式系統具有這些特性，以幫助構建更加健壯的分佈式系統。
爲了說明問題，基於上面的在線用戶管理系統，我們給定以下場景：
參考一開始我們給出的用例圖，對於客戶端 Client2，我們只希望它能以只讀的方式訪問 User 和 User List 資源，而 Client1 具有訪問所有資源的所有權限。
如何做這樣的安全控制？
通行的做法是：所有從客戶端 Client2 發出的 HTTP 請求都經過代理服務器 (Proxy Server)。代理服務器制定安全策略：所有經過該代理的訪問 User 和 User List 資源的請求只具有讀取權限，即：允許 GET/HEAD 操作，而像具有寫權限的 PUT/DELTE 是不被允許的。
如果對於 REST，我們看看這樣的安全策略是如何部署的。如下圖所示：
圖 4. REST 與代理服務器 (Proxy Servers)
一般代理服務器的實現根據 (URI, HTTP Method) 兩元組來決定 HTTP 請求的安全合法性。
當發現類似於（http://localhost:8182/v1/users/{username}，DELETE）這樣的請求時，予以拒絕。
對於 SOAP，如果我們想藉助於既有的代理服務器進行安全控制，會比較尷尬，如下圖：
圖 5. SOAP 與代理服務器 (Proxy Servers)
所有的 SOAP 消息經過代理服務器，只能看到（http://localhost:8182/v1/soap/servlet/messagerouter, HTTP POST）這樣的信息，如果代理服務器想知道當前的 HTTP 請求具體做的是什麼，必須對 SOAP 的消息體解碼，這樣的話，意味着要求第三方的代理服務器需要理解當前的 SOAP 消息語義，而這種 SOAP 應用與代理服務器之間的緊耦合關係是不合理的。
衆所周知，對於基於網絡的分佈式應用，網絡傳輸是一個影響應用性能的重要因素。如何使用緩存來節省網絡傳輸帶來的開銷，這是每一個構建分佈式網絡應用的開發人員必須考慮的問題。
HTTP 協議帶條件的 HTTP GET 請求 (Conditional GET) 被設計用來節省客戶端與服務器之間網絡傳輸帶來的開銷，這也給客戶端實現 Cache 機制 ( 包括在客戶端與服務器之間的任何代理 ) 提供了可能。HTTP 協議通過 HTTP HEADER 域：If-Modified-Since/Last- Modified，If-None-Match/ETag 實現帶條件的 GET 請求。
REST 的應用可以充分地挖掘 HTTP 協議對緩存支持的能力。當客戶端第一次發送 HTTP GET 請求給服務器獲得內容後，該內容可能被緩存服務器 (Cache Server) 緩存。當下一次客戶端請求同樣的資源時，緩存可以直接給出響應，而不需要請求遠程的服務器獲得。而這一切對客戶端來說都是透明的。
圖 6. REST 與緩存服務器 (Cache Server)
而對於 SOAP，情況又是怎樣的呢？
使用 HTTP 協議的 SOAP，由於其設計原則上並不像 REST 那樣強調與 Web 的工作方式相一致，所以，基於 SOAP 應用很難充分發揮 HTTP 本身的緩存能力。
圖 7. SOAP 與緩存服務器 (Cache Server)
兩個因素決定了基於 SOAP 應用的緩存機制要遠比 REST 複雜：
其一、所有經過緩存服務器的 SOAP 消息總是 HTTP POST，緩存服務器如果不解碼 SOAP 消息體，沒法知道該 HTTP 請求是否是想從服務器獲得數據。
其二、SOAP 消息所使用的 URI 總是指向 SOAP 的服務器，如本文例子中的 http://localhost:8182/v1/soap/servlet/messagerouter，這並沒有表達真實的資源 URI，其結果是緩存服務器根本不知道那個資源正在被請求，更不用談進行緩存處理。
在一個純的 SOAP 應用中，URI 本質上除了用來指示 SOAP 服務器外，本身沒有任何意義。與 REST 的不同的是，無法通過 URI 驅動 SOAP 方法調用。例如在我們的例子中，當我們通過
getUserList SOAP 消息獲得所有的用戶列表後，仍然無法通過既有的信息得到某個具體的用戶信息。唯一的方法只有通過 WSDL 的指示，通過調用 getUserByName 獲得，getUserList 與 getUserByName 是彼此孤立的。
而對於 REST，情況是完全不同的：通過 http://localhost:8182/v1/users URI 獲得用戶列表，然後再通過用戶列表中所提供的 LINK 屬性，例如<link>http://localhost:8182/v1/users/tester</link>獲得 tester 用戶的用戶信息。這樣的工作方式，非常類似於你在瀏覽器的某個頁面上點擊某個 hyperlink, 瀏覽器幫你自動定向到你想訪問的頁面，並不依賴任何第三方的信息。
典型的基於 SOAP 的 Web 服務以操作爲中心，每個操作接受 XML 文檔作爲輸入，提供 XML 文檔作爲輸出。在本質上講，它們是 RPC 風格的。而在遵循 REST 原則的 ROA 應用中，服務是以資源爲中心的，對每個資源的操作都是標準化的 HTTP 方法。
本文主要集中在以上的幾個方面，對 SOAP 與 REST 進行了對比，可以看到，基於 REST 構建的系統其系統的擴展能力要強於 SOAP，這可以體現在它的統一接口抽象、代理服務器支持、緩存服務器支持等諸多方面。並且，伴隨着 Web Site as Web Services 演進的趨勢，基於 REST 設計和實現的簡單性和強擴展性，有理由相信，REST 將會成爲 Web 服務的一個重要架構實踐領域。