轉載:關於對REST的基本認識和理解

1.什麼是 REST?

REST 是屬於 WEB 自身的一種架構風格，是在 HTTP 1.1 規範下實現的。Representational State Transfer 全稱翻譯爲表現層狀態轉化。Resource：資源。好比 newsfeed；Representational：表現形式，好比用JSON，富文本等；State Transfer：狀態變化。經過HTTP 動做實現。

REST是全部Web應用都應該遵照的架構設計指導原則。固然，REST並非法律，違反了REST的指導原則，仍然可以實現應用的功能。可是違反了REST的指導原則，會付出不少代價，特別是對於大流量的網站而言。

 

2.REST架構風格最重要的架構約束有6個：

• 客戶-服務器（Client-Server）

通訊只能由客戶端單方面發起，表現爲請求-響應的形式。

• 無狀態（Stateless）

通訊的會話狀態（Session State）應該所有由客戶端負責維護。

• 緩存（Cache）

響應內容能夠在通訊鏈的某處被緩存，以改善網絡效率。

• 統一接口（Uniform Interface）

通訊鏈的組件之間經過統一的接口相互通訊，以提升交互的可見性。

• 分層系統（Layered System）

經過限制組件的行爲（即，每一個組件只能「看到」與其交互的緊鄰層），將架構分解爲若干等級的層。

• 按需代碼（Code-On-Demand，可選）

支持經過下載並執行一些代碼（例如Java Applet、Flash或JavaScript），對客戶端的功能進行擴展。

 

3.要深刻理解REST，須要理解REST的五個關鍵詞：

1. 資源（Resource）
2. 資源的表述（Representation）
3. 狀態轉移（State Transfer）
4. 統一接口（Uniform Interface）
5. 超文本驅動（Hypertext Driven）

6. 什麼是資源？

   資源是一種看待服務器的方式，即，將服務器看做是由不少離散的資源組成。每一個資源是服務器上一個可命名的抽象概念。由於資源是一個抽象的概念，因此它不只僅能表明服務器文件系統中的一個文件、數據庫中的一張表等等具體的東西，能夠將資源設計的要多抽象有多抽象，只要想象力容許並且客戶端應用開發者可以理解。與面向對象設計相似，資源是以名詞爲核心來組織的，首先關注的是名詞。一個資源能夠由一個或多個URI來標識。URI既是資源的名稱，也是資源在Web上的地址。對某個資源感興趣的客戶端應用，能夠經過資源的URI與其進行交互。

   什麼是資源的表述？

   資源的表述是一段對於資源在某個特定時刻的狀態的描述。能夠在客戶端-服務器端之間轉移（交換）。資源的表述能夠有多種格式，例如HTML/XML/JSON/純文本/圖片/視頻/音頻等等。資源的表述格式能夠經過協商機制來肯定。請求-響應方向的表述一般使用不一樣的格式。

   什麼是狀態轉移？

   狀態轉移（state transfer）與狀態機中的狀態遷移（state transition）的含義是不一樣的。狀態轉移說的是：在客戶端和服務器端之間轉移（transfer）表明資源狀態的表述。經過轉移和操做資源的表述，來間接實現操做資源的目的。

   什麼是統一接口？

   REST要求，必須經過統一的接口來對資源執行各類操做。對於每一個資源只能執行一組有限的操做。以HTTP/1.1協議爲例，HTTP/1.1協議定義了一個操做資源的統一接口，主要包括如下內容：

   • 7個HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS

   • HTTP頭信息（可自定義）

   • HTTP響應狀態代碼（可自定義）

   • 一套標準的內容協商機制

   • 一套標準的緩存機制

   • 一套標準的客戶端身份認證機制

   REST還要求，對於資源執行的操做，其操做語義必須由HTTP消息體以前的部分徹底表達，不能將操做語義封裝在HTTP消息體內部。這樣作是爲了提升交互的可見性，以便於通訊鏈的中間組件實現緩存、安全審計等等功能。

   什麼是超文本驅動？

   「超文本驅動」又名「將超媒體做爲應用狀態的引擎」（Hypermedia As The Engine Of Application State，來自Fielding博士論文中的一句話，縮寫爲HATEOAS）。將Web應用看做是一個由不少狀態（應用狀態）組成的有限狀態機。資源之間經過超連接相互關聯，超連接既表明資源之間的關係，也表明可執行的狀態遷移。在超媒體之中不只僅包含數據，還包含了狀態遷移的語義。以超媒體做爲引擎，驅動Web應用的狀態遷移。經過超媒體暴露出服務器所提供的資源，服務器提供了哪些資源是在運行時經過解析超媒體發現的，而不是事先定義的。從面向服務的角度看，超媒體定義了服務器所提供服務的協議。客戶端應該依賴的是超媒體的狀態遷移語義，而不該該對因而否存在某個URI或URI的某種特殊構造方式做出假設。一切都有可能變化，只有超媒體的狀態遷移語義可以長期保持穩定。

 

1. 從架構風格的抽象高度來看，常見的分佈式應用架構風格有三種：

2. • 分佈式對象（Distributed Objects，簡稱DO）

   架構實例有CORBA/RMI/EJB/DCOM/.NET Remoting等等

   • 遠程過程調用（Remote Procedure Call，簡稱RPC）

   架構實例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等

• 表述性狀態轉移（Representational State Transfer，簡稱REST）

3. 架構實例有HTTP/WebDAV

   DO和RPC這兩種架構風格在企業應用中很是廣泛，而REST則是Web應用的架構風格，它們之間有很是大的差異。

   REST與DO的差異在於：

   • REST支持抽象（即建模）的工具是資源，DO支持抽象的工具是對象。在不一樣的編程語言中，對象的定義有很大差異，因此DO風格的架構一般都是與某種編程語言綁定的。跨語言交互即便能實現，實現起來也會很是複雜。而REST中的資源，則徹底中立於開發平臺和編程語言，可使用任何編程語言來實現。

   • DO中沒有統一接口的概念。不一樣的API，接口設計風格能夠徹底不一樣。DO也不支持操做語義對於中間組件的可見性。

   • DO中沒有使用超文本，響應的內容中只包含對象自己。REST使用了超文本，能夠實現更大粒度的交互，交互的效率比DO更高。

   • REST支持數據流和管道，DO不支持數據流和管道。

   • DO風格一般會帶來客戶端與服務器端的緊耦合。在三種架構風格之中，DO風格的耦合度是最大的，而REST的風格耦合度是最小的。REST鬆耦合的源泉來自於統一接口+超文本驅動。

   REST與RPC的差異在於：

   • REST支持抽象的工具是資源，RPC支持抽象的工具是過程。REST風格的架構建模是以名詞爲核心的，RPC風格的架構建模是以動詞爲核心的。簡單類比一下，REST是面向對象編程，RPC則是面向過程編程。

   • RPC中沒有統一接口的概念。不一樣的API，接口設計風格能夠徹底不一樣。RPC也不支持操做語義對於中間組件的可見性。

   • RPC中沒有使用超文本，響應的內容中只包含消息自己。REST使用了超文本，能夠實現更大粒度的交互，交互的效率比RPC更高。

   • REST支持數據流和管道，RPC不支持數據流和管道。

   • 由於使用了平臺中立的消息，RPC風格的耦合度比DO風格要小一些，可是RPC風格也經常會帶來客戶端與服務器端的緊耦合。支持統一接口+超文本驅動的REST風格，能夠達到最小的耦合度。

   比較了三種架構風格之間的差異以後，從面向實用的角度來看，REST架構風格能夠爲Web開發者帶來三方面的利益：

   • 簡單性

   採用REST架構風格，對於開發、測試、運維人員來講，都會更簡單。能夠充分利用大量HTTP服務器端和客戶端開發庫、Web功能測試/性能測試工具、HTTP緩存、HTTP代理服務器、防火牆。這些開發庫和基礎設施早已成爲了平常用品，不須要什麼火箭科技（例如神奇昂貴的應用服務器、中間件）就能解決大多數可伸縮性方面的問題。

   • 可伸縮性

   充分利用好通訊鏈各個位置的HTTP緩存組件，能夠帶來更好的可伸縮性。其實不少時候，在Web前端作性能優化，產生的效果不亞於僅僅在服務器端作性能優化，可是HTTP協議層面的緩存經常被一些資深的架構師徹底忽略掉。

   • 鬆耦合

   統一接口+超文本驅動，帶來了最大限度的鬆耦合。容許服務器端和客戶端程序在很大範圍內，相對獨立地進化。對於設計面向企業內網的API來講，鬆耦合並非一個很重要的設計關注點。可是對於設計面向互聯網的API來講，鬆耦合變成了一個必選項，不只在設計時應該關注，並且應該放在最優先位置。

4. 轉載自：http://www.infoq.com/cn/articles/understanding-restful-style