本頁使用了標題或全文手工轉換

表現層狀態轉換

維基百科,自由的百科全書
(重新導向自 REST)
跳至導覽 跳至搜尋

表現層狀態轉換(REST,英文:Representational State Transfer)是Roy Thomas Fielding英語Roy Thomas Fielding博士於2000年在他的博士論文[1] 中提出來的一種萬維網軟件架構風格,目的是便於不同軟件/程序在網絡(例如互聯網)中互相傳遞信息。表現層狀態轉換(REST,英文:Representational State Transfer)是根基於超文本傳輸協定(HTTP)之上而確定的一組約束和屬性,是一種設計提供全球資訊網絡服務的軟體構建風格。符合或相容於這種架構風格(簡稱為 REST 或 RESTful)的網絡服務,允許用戶端發出以統一資源標識符存取和操作網絡資源的請求,而與預先定義好的無狀態操作集一致化。因此表現層狀態轉換提供了在互聯網絡的計算系統之間,彼此資源可交互使用的協作性質(interoperability)。相對於其它種類的網絡服務,例如 SOAP服務則是以本身所定義的操作集,來存取網絡上的資源。

目前在三種主流的Web服務實現方案中,因為REST模式與複雜的SOAPXML-RPC相比更加簡潔,越來越多的web服務開始採用REST風格設計和實現。例如,Amazon.com提供接近REST風格的Web服務執行圖書查詢;雅虎提供的Web服務也是REST風格的。

要點及標準[編輯]

需要注意的是,REST是設計風格而不是標準。REST通常基於使用HTTPURI,和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個[2]

  • 客戶-服務器(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服務接受與返回的互聯網媒體類型,比如:JSONXMLYAML等。
  • 對資源的操作:Web服務在該資源上所支持的一系列請求方法(比如:POST,GET,PUT或DELETE)。

下表列出了在實現RESTful API時HTTP請求方法的典型用途。

HTTP請求方法在RESTful API中的典型應用[3]
資源 GET PUT POST DELETE
一組資源的URI,比如https://example.com/resources/ 列出URI,以及該資源組中每個資源的詳細資訊(後者可選)。 使用給定的一組資源替換當前整組資源。 在本組資源中創建/追加一個新的資源。該操作往往返回新資源的URL。 刪除整組資源。
單個資源的URI,比如https://example.com/resources/142 獲取指定的資源的詳細資訊,格式可以自選一個合適的網絡媒體類型(比如:XML、JSON等) 替換/創建指定的資源。並將其追加到相應的資源組中。 把指定的資源當做一個資源組,並在其下創建/追加一個新的元素,使其隸屬於當前資源。 刪除指定的元素。

PUT和DELETE方法是冪等方法。GET方法是安全方法(不會對服務器端有修改,因此當然也是冪等的)。

不像基於SOAP的Web服務,RESTful Web服務並沒有「正式」的標準[4]。這是因為REST是一種架構,而SOAP只是一個協議。雖然REST不是一個標準,但大部分RESTful Web服務實現會使用HTTPURIJSONXML等各種標準。

實現舉例[編輯]

例如,一個簡單的網絡商店應用,列舉所有商品,

GET http://www.store.com/products

呈現某一件商品,

GET http://www.store.com/products/12345

下單購買,

POST http://www.store.com/orders
<purchase-order>
  <item> ... </item>
</purchase-order>

REST的優點[編輯]

  • 可更高效利用快取來提高響應速度
  • 通訊本身的無狀態性可以讓不同的服務器的處理一系列請求中的不同請求,提高服務器的擴展性
  • 瀏覽器即可作為客戶端,簡化軟體需求
  • 相對於其他疊加在HTTP協議之上的機制,REST的軟體相依性更小
  • 不需要額外的資源發現機制
  • 在軟體技術演進中的長期的相容性更好

實現[編輯]

參考文獻[編輯]

引用[編輯]

  1. ^ Fielding, Roy Thomas. Chapter 5: Representational State Transfer (REST). Architectural Styles and the Design of Network-based Software Architectures (Ph.D.). University of California, Irvine. 2000. This chapter introduced the Representational State Transfer (REST) architectural style for distributed hypermedia systems. REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. 
  2. ^ 理解RESTful. 
  3. ^ Richardson, Leonard; Ruby, Sam, RESTful Web Services, O'Reilly, 2007 ((May 8, 2007)), ISBN 0596529260 
  4. ^ Elkstein, M. What is REST?. Retrieved on 2009-07-04.

網頁[編輯]