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

表現層狀態轉換

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

表現層狀態轉換英語Representational State Transfer縮寫REST)是Roy Thomas Fielding英語Roy Thomas Fielding博士於2000年在他的博士論文[1]中提出來的一種全球資訊網軟體架構風格,目的是便於不同軟體/程式在網路(例如網際網路)中互相傳遞資訊。表現層狀態轉換是根基於超文字傳輸協定(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瀏覽器。當然也可以是任何其他的格式,例如JSON。

表示狀態傳送的特徵[編輯]

  • 統一介面(Uniform Interface)

1. 以資源為基礎

每個資源都可以通過URI存取到。

也就是一個個可以認知的資源,比如文件,音樂,影片等資訊,都可以通過唯一的URI確定

2. 通過重表達的用戶端可以管理原資源

就是我們通過用戶端可以修改原資源的狀態

3. 返回資訊足夠描述自己

這樣重表達的用戶端可以知道如何處理

4. 超媒體是應用狀態的引擎

處理以超媒體為基礎的狀態變化

  • Stateless

無狀態

  • Cacheable

可快取

  • Client-Server

客戶伺服器分離模式,任何一個用戶端與伺服器都是可替換的

  • Layered System

分層的系統,用戶端不知道他聯絡的是不是最終伺服器

  • Code on Demand (optional)

伺服器可以將能力擴充到用戶端,如果用戶端可以執行的話。這個功能是可選擇的。

REST架構的約束條件[編輯]

REST架構風格最重要的架構約束有6個[2]

  • 用戶端-伺服器(Client-Server)

用戶端-伺服器結構約束的目的是將用戶端和伺服器端的關注點分離. 將使用者介面所關注的邏輯和資料儲存所關注的邏輯分離開來有助於提高使用者介面的跨平台的可移植性.通過簡化伺服器模組也有助於伺服器模組的可延伸性.

  • 無狀態(Stateless)

伺服器不能儲存用戶端的資訊, 每一次從用戶端傳送的請求中, 要包含所有的必須的狀態資訊, 對談資訊由用戶端儲存, 伺服器端根據這些狀態資訊來處理請求. 伺服器可以將對談狀態資訊傳遞給其他服務, 比如資料庫服務, 這樣可以保持一段時間的狀態資訊, 從而實現認證功能. 當用戶端可以切換到一個新狀態的時候傳送請求資訊. 當一個或者多個請求被傳送之後, 用戶端就處於一個狀態變遷過程中. 每一個應用的狀態描述可以被用戶端用來初始化下一次的狀態變遷.

  • 快取(Cacheability)

如同全球資訊網一樣, 用戶端和中間的通訊傳遞者可以將回應快取起來. 回應必須明確的或者間接的表明本身是否可以進行快取,這可以預防用戶端在將來進行請求的時候得到陳舊的或者不恰當的資料. 管理良好的快取機制可以 減少用戶端-伺服器之間的互動, 甚至完全避免用戶端-伺服器互動, 這進一步提了高效能和可延伸性。

  • 統一介面(Uniform Interface)

統一介面是 RESTful 系統設計的基本出發點. 它簡化了系統的架構, 減少了耦合性, 可以讓所有模組各自獨立的進行改進. 對於統一介面的四個約束是:

  • 請求中包含資源的 ID (Resource identification in requests )
請求中包含了各種獨立資源的標識, 例如, 在 Web 服務中的 URIs. 資源本身和傳送給用戶端的標識是獨立. 例如, 伺服器可以將自身的資料庫資訊以 HTML XML 或者 JSON 的方式傳送給用戶端, 但是這些可能都不是伺服器的內部記錄方式.
  • 資源通過標識來操作(Resource manipulation through representations)
當用戶端擁有一個資源的標識, 包括附帶的元資料, 則它就有足夠的資訊來刪除這個資源.
  • 訊息的自我描述性(Self-descriptive messages)
每一個訊息都包含足夠的資訊來描述如何來處理這個資訊. 例如, 媒體類型 (midia-type) 就可以確定需要什麼樣的分析器來分析媒體資料.
  • 用超媒體驅動應用狀態 ( Hypermedia as the engine of application state (HATEOAS))
同用戶存取 Web 伺服器的 Home 頁面相似,當一個 REST 用戶端存取了最初的 REST 應用的 URI 之後, REST 用戶端應該可以使用伺服器端提供的連結,動態的發現所有的可用的資源和可執行的操作.隨著存取的進行, 伺服器在回應中提供文字超連結, 以便用戶端可以得到目前可用的操作. 用戶端無需用確定的編碼的方式記錄下伺服器端所提供的動態應用的結構資訊.


  • 分層系統(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.

來源[編輯]