REST 定義了一組體系架構原則，您可以根據這些，包括使用不同語言編寫的客戶端如何通過 HTTP 處理和傳輸資源狀態。所以在事實上，REST 對 Web的影響非常大，由於其使用相當方便，已經普遍地取代了基於 SOAP 和 WSDL 的介面設計。在多年以後的今天，REST的主要框架已經開始雨後春筍般的出現。  個人理解： （一）  首先REST只是一種風格，不是一種標準 （二）  REST是以資源為中心的 （三）  REST充分利用或者說極端依賴HTTP協議 一．對於今天正在吸引如此多注意力的最純粹形式的 REST Web 服務，其具體實現應該遵循以下基本設計原則： 1.1．顯式地使用不同的 HTTP 請求方法 1.2．無狀態 1.3．公開目錄結構式的 URI(通過邏輯URI定位資源)。 1.1．顯式地使用不同的 HTTP 請求方法     我們在 Web 應用中處理來自客戶端的請求時，通常只考慮 GET 和 POST 這兩種 HTTP 請求方法。實際上，HTTP 還有 HEAD、PUT、DELETE 等請求方法。而在 REST 架構中，用不同的 HTTP 請求方法來處理對資源的 CRUD（建立、讀取、更新和刪除）操作：     若要在伺服器上建立資源，應該使用 POST 方法。      若要檢索某個資源，應該使用 GET 方法。      若要更改資源狀態或對其進行更新，應該使用 PUT 方法。      若要刪除某個資源，應該使用 DELETE 方法。 經過這樣的一番擴充套件，我們對一個資源的 CRUD 操作就可以通過同一個 URI 完成了： 讀取） [GET] http://www.example.com/photo/logo 仍然保持為 [GET] http://www.example.com/photo/logo （建立）http://www.example.com/photo/logo/create 改為 [POST] http://www.example.com/photo/logo （更新）http://www.example.com/photo/logo/update 改為 [PUT] http://www.example.com/photo/logo （刪除）http://www.example.com/photo/logo/delete 改為 [DELETE]  http://www.example.com/photo/logo 從而進一步規範了資源標識的使用。 通過 REST 架構，Web 應用程式可以用一致的介面（URI）暴露資源給外部世界，並對資源提供語義一致的操作服務。這對於以資源為中心的 Web 應用來說非常重要。
1.2．無狀態 在 REST 的定義中，一個 Web 應用總是使用固定的 URI 向外部世界呈現一個資源。 它認為Web是由一系列的抽象資源組成，這些抽象的資源具有不同的具體表現形式。 譬如，定義一個資源為photo，含義是照片，它的表現形式可以是一個圖片，也可以是一個.xml的檔案，其中包含一些描述該照片的元素，或是一個html檔案。 並且這些具體的表現可以分佈在不同的物理位置上。 1.3．通過邏輯URI定位資源 實現這種級別的可用性的方法之一是定義目錄結構式的 URI。 此類 URI 具有層次結構，其根為單個路徑，從根開始分支的是公開服務的主要方面的子路徑。 根據此定義，URI 並不只是斜槓分隔的字串，而是具有在節點上連線在一起的下級和上級分支的樹。  例如，在一個收集photo的相簿中，您可能定義類似如下的結構化 URI 集合： http://www.example.com/photo/topics/{topic} 如：http://www.example.com/photo/topics/home 根 / photo之下有一個 /topics 節點。 該節點之下有一系列主題名稱，例如生日照片，聚會照片等等，每個主題名稱指向某個討論線。 在此結構中，只需在 {topic}輸入某個內容即可容易地收集討論執行緒。 在某些情況下，指向資源的路徑尤其適合於目錄式結構。 例如，以按日期進行組織的資源為例，這種資源非常適合於使用層次結構語法。  此示例非常直觀，因為它基於規則： http://www.example.com/photo/2010/02/22/{topic} 第一個路徑片段是四個數字的年份，第二個路徑片斷是兩個數字的月份，第三個片段是兩個數字的日期。這就是我們追求的簡單級別。 在語法的空隙中填入路徑部分就大功告成了，因為存在用於組合 URI 的明確模式： http://www.example.com/photo/{year}/{day}/{month}/{topic} 從而不需要我們去這樣去傳遞資訊：http://www.example.com/photo?year=xxxx&day=xxx$month=xxx&topic=xxxx 二．Restful web service的優點： 2.1 HTTP頭中可見的統一介面和資源地址 通過對於HTTP Head 的解析，我們便可以瞭解到當前所請求的資源和請求的方式。這樣做對於一些代理伺服器的設定，將帶來很高的處理效率。 REST 系統中所有的動作和要訪問的資源都可以從HTTP和URI中得到，這使得代理伺服器、快取伺服器和閘道器很好地協調工作。而RPC模型的SOAP 要訪問的資源僅從 URI無法得知，要呼叫的方法也無法從HTTP中得知，它們都隱藏在 SOAP 訊息中。 同樣的，在REST系統中的代理伺服器還可以通過 HTTP 的動作 (GET 、 POST)來進行控制。 2.2 返回一般的XML格式內容 一般情況下，一個RESTful Web Service將比一個傳統SOAP RPC Web Service佔用更少的傳輸頻寬。 2.3 安全機制 REST使用了簡單有效的安全模型。REST中很容易隱藏某個資源，只需不釋出它的URI；而在資源上也很容易使用一些安全策略，比如可以在每個 URI 針對 4個通用介面設定許可權；再者，以資源為中心的 Web服務是防火牆友好的，因為 GET的 意思就是GET， PUT 的意思就是PUT，管理員可以通過堵塞非GET請求把資源設定為只讀的，而現在的基於RPC 模型的 SOAP 一律工作在 HTTP 的 POST上。而使用 SOAP RPC模型，要訪問的物件名稱藏在方法的引數中，因此需要建立新的安全模型。 三．　使用REST架構 　　對於開發人員來說，關心的是如何使用REST架構，這裡我們來簡單談談這個問題。REST帶來的不僅僅是一種嶄新的架構，它更是帶來一種全新的Web開發過程中的思維方式：通過URL來設計系統結構。REST是一套簡單的設計原則、一種架構風格（或模式），不是一種具體的標準或架構。到今天REST有很多成功的使用案例，客戶端呼叫也極其方便。 下面是我通過Spring3.0來舉個例子：