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

表現層狀態轉換

維基百科,自由的百科全書
(重新導向自 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.

網頁[編輯]