要點及標準
需要注意的是，REST是設計風格而不是標準。REST通常基於使用HTTP，URI，和XML以及HTML這些現有的廣泛流行的協定和標準。
•資源是由URI來指定。
•對資源的操作包括獲取、創建、修改和刪除資源，這些操作正好對應HTTP協定提供的GET、POST、PUT和DELETE方法。
•通過操作資源的表現形式來操作資源。
•資源的表現形式則是XML或者HTML，取決於讀者是機器還是人，是消費web服務的客戶軟體還是web瀏覽器。當然也可以是任何其他的格式。
可重新表達的狀態遷移的特徵
•統一接口(Uniform Interface)
1. 以資源為基礎
每個資源都可以通過URI訪問到。
也就是一個個可以認知的資源，比如文檔，音樂，視頻等信息，都可以通過獨立的URI確定
2. 通過重表達的客戶端可以管理原資源
就是我們通過客戶端可以修改原資源的狀態
3. 返回信息足夠描述自己
這樣重表達的客戶端可以知道如何處理
4. 超媒體是套用狀態的引擎
處理以超媒體為基礎的狀態變化
•Stateless
無狀態
•Cacheable
可快取
•Client-Server
客戶伺服器分離模式，任何一個客戶端與伺服器都是可替換的
•Layered System
分層的系統，客戶端不知道他聯繫的是不是最終伺服器
•Code on Demand (optional)
伺服器可以將能力擴展到客戶端，如果客戶端可以執行的話。這個功能是可選擇的。
具體說明
REST架構風格最重要的架構約束有6個：
•客戶-伺服器（Client-Server）
•通信只能由客戶端單方面發起，表現為請求-回響的形式。
•無狀態（Stateless）
•通信的會話狀態（Session State）應該全部由客戶端負責維護。
•快取（Cache）
•回響內容可以在通信鏈的某處被快取，以改善網路效率。
•統一接口（Uniform Interface）
•通信鏈的組件之間通過統一的接口相互通信，以提高互動的可見性。
•分層系統（Layered System）
•通過限制組件的行為（即每個組件只能“看到”與其互動的緊鄰層），將架構分解為若干等級的層。
•按需代碼（Code-On-Demand，可選）
•支持通過下載並執行一些代碼（例如Java Applet、Flash或JavaScript），對客戶端的功能進行擴展。
關於狀態
應該注意區別套用的狀態和連線協定的狀態。HTTP連線是無狀態的（也就是不記錄每個連線的信息），而REST傳輸會包含套用的所有狀態信息，因此可以大幅降低對HTTP連線的重複請求資源消耗。
套用於Web服務
匹配REST設計風格的Web API稱為 RESTful API。它從以下三個方面資源進行定義：
•直觀簡短的資源地址：URI，比如：http://example.com/resources/。
•傳輸的資源：Web服務接受與返回的網際網路媒體類型，比如：JSON，XML，YAML等。
•對資源的操作：Web服務在該資源上所支持的一系列請求方法（比如：POST，GET，PUT或DELETE）。
圖一列出了在實現RESTful API時HTTP請求方法的典型用途。
圖一PUT和DELETE方法是冪等方法。GET方法是安全方法（不會對伺服器端有修改，因此當然也是冪等的）。
不像基於SOAP的Web服務，RESTful Web服務並沒有“正式”的標準。這是因為REST是一種架構，而SOAP只是一個協定。雖然REST不是一個標準，但大部分RESTful Web服務實現會使用HTTP、URI、JSON和XML等各種標準。
實現舉例
例如，一個簡單的網路商店套用，列舉所有商品，
呈現某一件商品，
下單購買，
REST的優點
•可更高效利用快取來提高回響速度
•通訊本身的無狀態性可以讓不同的伺服器的處理一系列請求中的不同請求，提高伺服器的擴展性
•瀏覽器即可作為客戶端，簡化軟體需求
•相對於其他疊加在HTTP協定之上的機制，REST的軟體依賴性更小
•不需要額外的資源發現機制
•在軟體技術演進中的長期的兼容性更好
