RESTfull 介面規範理解

阿新 • • 發佈：2019-01-21

RESTfull介面規範理解

RESTfull = Representational State Transfer 即表現層狀態轉移加 ful (即形容詞字尾) 則表示是形容詞性的

而要理解RESTful架構，最好的方法就是去理解Representational State Transfer這個片語，直譯過來就是「表現層狀態轉化」，其實它省略了主語。「表現層」其實指的是「資源」的「表現層」，所以通俗來講就是：資源在網路中以某種表現形式進行狀態轉移。分解開來：

Resource：資源，即資料。比如usenames/users/friends/menu/order等；
Representational：某種表現形式，比如用JSON，XML，JPEG等；

State Transfer：狀態變化。通過HTTP動詞實現。

然後再來理解一個具體的RESTful架構——面向資源的架構（Resource-Oriented Architecture，ROA）：

資源是由URI來指定。所謂「上網」，就是與網際網路上一系列的「資源」互動，呼叫它的URI。
對資源的操作包括獲取、建立、修改和刪除資源，這些操作正好對應HTTP協議提供的
get(獲取網路中某個地址的資源),
- post（建立資源也叫更新資源）,
- put（更新資源）,
- patch（更新網路資源）,
- delete（刪除網路資源）
- 最常見的就是get和post請求
- 通過操作資源的表現形式來操作資源。具體表現形式，應該在HTTP請求的頭資訊中用Accept和Content-Type欄位指定。

資源的表現形式則是XML或者HTML，取決於讀者是機器還是人，是消費web服務的客戶軟體還是web瀏覽器。當然也可以是任何其他的格式。

應用於Web服務，符合REST設計風格的Web API稱為RESTful API。它從以下三個方面資源進行定義：

直觀簡短的資源地址：URI，比如：http://example.com/resources/；每一個URI代表一種資源；
傳輸的資源：Web服務接受與返回的網際網路媒體型別，比如：JSON，XML，YAML等。
對資源的操作：Web服務在該資源上所支援的一系列請求方法（比如：POST，GET，PUT或DELETE）。

HTTP請求方法在RESTful API中的典型應用：

資源	GET	PUT	POST	DELETE
一組資源的URI，比如`http://example.com/resources/`	列出URI，以及該資源組中每個資源的詳細資訊（後者可選）。	使用給定的一組資源替換當前整組資源。	在本組資源中建立/追加一個新的資源。該操作往往返回新資源的URL。	刪除整組資源。
單個資源的URI，比如`http://example.com/resources/142`	獲取指定的資源的詳細資訊，格式可以自選一個合適的網路媒體型別（比如：XML、JSON等）	替換/建立指定的資源。並將其追加到相應的資源組中。	把指定的資源當做一個資源組，並在其下建立/追加一個新的元素，使其隸屬於當前資源。	刪除指定的元素。

REST的誤解

現在看來，REST在2000年那個時代，確實是超前於時代的。Web開發者社群對於HTTP的設計意圖存在著大量的誤解，由此導致了對於HTTP的大量低效率的誤用。這個情況持續一直到2005年Web 2.0的崛起。那個時候，DCOM、EJB、SOAP/WSDL這些DO風格的架構由於難以滿足網際網路環境對分散式應用架構設計的約束，與Web自身的架構風格REST相沖突，很難融入到Web之中。所謂的「Web Services」，其實除了將HTTP作為底層的傳輸協議外，跟（網際網路環境中的）真正的Web沒有什麼關係。

而隨著Ruby on Rails這個著名的Web開發框架開始大力支援REST開發之後，一線的Web開發者才真正接觸到了REST。然而Rails所支援的REST開發將對資源的操作侷限於CRUD（建立、獲取、修改、刪除）的語義（即，將對資源的CRUD操作對映到 GET/POST/PUT/DELETE四個HTTP方法），這其實是收窄了REST的適用範圍。其他程式語言的Web開發框架（例如Java語言的 Struts、Spring MVC等等）也緊接著模仿了Rails的方式開始支援REST開發，然而這更加導致了一線的Web開發者誤以為：REST開發就是通過GET/POST/PUT/DELETE四個HTTP方法對資源執行CRUD操作。甚至還有很多僅僅使用了HTTP，而沒有使用SOAP的Web服務API，都自稱是REST風格（RESTful）的API。

對於什麼才是真正的REST風格的誤解是如此之多，而將REST作為一個便於營銷的 buzzword的掛羊頭賣狗肉者也是如此之多，以至於REST的創造者Fielding終於忍無可忍了。2008年10月Fielding寫了一篇博客，做出了一個非常明確的斷言：REST APIs must be hypertext-driven!（REST API必須是超文字驅動的！）超文字驅動這個理念變成了一個縮寫詞HATEOAS，這個縮寫詞來自於當初Fielding博士論文中的一句話： hypermedia as the engine of application state（將超媒體作為應用狀態的引擎）。其實超文字驅動（Hypertext Driven）的理念才是REST架構風格最核心的理念，也是REST風格的架構達到鬆耦合目標的根本原因。

REST設計進階

當談及REST成熟度時，一些人常常會引用Richardson所提出來的REST成熟度模型（Maturity Model），並視之為正確的度量方法。

1.在架構中引入資源（Resource）的概念。

大多數WS-*服務和POX都只是使用一個URI作為一個服務埠，也只使用一個HTTP方法傳輸資料。這種做法相當於把HTTP這個應用層協議降級為傳輸層協議用，《REST實戰》也一再強調HTTP是一種應用協議而不是傳輸協議。再好一點就是使用多個URI，然而不同的URI只是作為不同的呼叫入口，與此同時只使用同一個HTTP方法傳輸資料。最常見的錯誤就是在URI中包含動詞，比如URI http://example.com/getOrder?orderId=1234，其實「資源」表示一種實體，所以應該是名詞，動詞應該放在HTTP協議中。而與此同時URI也有可能破壞HTTP GET的安全性和幕等性，比如某個客戶端在http://example.com/updateOrder?id=1234&coffee=latte上執行GET（而不是POST），就能建立一筆新的咖啡訂單（一個資源），按理來說GET請求不能改變服務的任何狀態。

2.每一個URI代表一種資源，支援HTTP動詞（即get，post，put，delete）。

此時使用多個URI的話，需要讓不同的URI代表不同的資源（注意多個URI可能指向同一個Resource，而一個URI不能指向不同Resource。），同時使用多個HTTP方法操作這些資源，例如使用POST/GET/PUT/DELET分別進行CRUD操作。這時候HTTP頭和有效載荷都包含業務邏輯，例如HTTP方法對應CRUD操作，HTTP狀態碼對應操作結果的狀態。我們現在看到的大多數所謂RESTful API做到的也就是這個級別。《REST實戰》的譯者也談到：悟性差的人，理解到CRUD式Web服務就滿足了。而悟性好的人，可以徹底理解超文字驅動，甚至是與REST關係密切的語義網，最終達到 REST開發的最高境界。

RESTfull 介面規範理解