爲啥REST如此重要？

摘要：REST——表徵狀態轉移，因爲REST模式的Web服務更加簡潔，愈來愈多的Web服務開始採用REST風格設計和實現。例如，Amazon.com提供接近REST風格的Web服務進行圖書查找；雅虎提供的Web服務也是REST風格的。

本文咱們將討論REST，它定義了一組體系架構原則，您能夠根據這些原則設計以系統資源爲中心的Web服務，這是一個很是容易讓人誤解的概念。本文主要是寫給那些想設計WebService API但卻對REST沒有十分清晰認識的開發者們。在本文最後會附上一些資源供你們學習，這些資源講解很是詳細。

什麼是REST？

表徵狀態轉移（Representional State Transfer），是Roy Fielding（ HTTP規範的主要編寫者之一）博士在2000年他的博士論文中提出來的一種軟件架構風格。它並非一個標準，而是經過表徵（Representional ）來描述傳輸狀態的一種原則。其宗旨是從資源的角度來觀察整個網絡，分佈在各處的資源由URI肯定，而客戶端的應用經過URI來獲取資源的表徵。得到這些表徵導致這些應用程序轉變了其狀態。隨着不斷獲取資源的表徵，客戶端應用不斷地在轉變着其狀態。

目前在三種主流的Web服務實現方案中，由於REST模式的Web服務與複雜的SOAP和XML-RPC相對比，更加簡潔，愈來愈多的Web服務開始採用REST風格設計和實現。例如，Amazon.com提供接近REST風格的Web服務進行圖書查找；雅虎提供的Web服務也是REST風格的。

讓咱們來思考一下：

Marcus是一個農民，他有4頭牛，12只雞和3頭奶牛。他如今模擬一個REST API，而我是客戶端。若是我想用REST來請求當前的農場狀態，我僅會問：「State？」Marcus會回答：「4頭豬、12只雞、3頭奶牛」。

這是REST最簡單的一個例子。Marcus使用表徵來傳輸農場狀態。表徵的句子很簡單：「4頭豬、12只雞、3頭奶牛」。

再往下看，看我如何讓Marcus用REST方式添加2頭奶牛？

按照常理，能夠會這樣說：Marcus，請在農場你再添加2頭奶牛。難道這就是REST方式嗎？難道就是經過這樣的表徵來傳輸狀態的嗎？不是的！這是一個遠程過程調用，過程是給農場添加2頭奶牛。

Marcus很憤怒地響應到：「400，Bad Request」，你究竟是什麼意思？

因此，讓咱們從新來一次。咱們怎樣作到REST方式呢？該怎樣從新表徵呢？它應該是4頭豬、12只雞、3頭奶牛。好，讓咱們再次從新表徵……

我：「Marcus，……4頭豬、12只雞、5頭奶牛！」

Marcus：「好的」。

我：「Marcus，如今是什麼狀態？」

Marcus：「4頭豬、12只雞、5頭奶牛」。

我：「好！」

看到了嗎？就這樣簡單。

爲何RPC也不夠好？

從邏輯角度來看，爲何會更加青睞REST而不是RPC（Remote Procedure Call，遠程過程調用 ），由於它極大的下降了咱們溝通的複雜度，經過把表徵做爲惟一的溝通的方式。無需去討論過程（添加一頭牛？增長一種動物類型？給雞的數量翻倍仍是賣掉全部豬？）咱們只需討論表徵，而且使用這個表徵來達到咱們想要的目標，很簡單，不是嗎？我不但願和Marcus的溝通失敗，由於咱們彼此的理解過程會不同，因此只須要知道最後的狀態就行。但這僅僅是建立RPC會產生許多問題之一。若是你使用RPC，你須要設計一些程序嵌入到某種結構中。這種結構須要存儲參數、錯誤的代碼、返回值等。我已經看到許多公司這樣作，他們設計本身的RPC-結構來實現客戶端與服務器端的交互，但卻產生許多問題。你爲何要這麼作？爲何要建立本身的RPC-結構？這樣作的好處是？假若我想要讓應用程序使用許多WebService，而且這些WebService帶有多個RPC-格式屬性？那麼我不得不去開發一些相似這樣的東西：

若是大家真的須要RPC，至少要選擇一個相似SOAP的標準。

但SOAP也很糟糕

即便RPC的標準真的很使人痛苦，但我不得不認可ACID事務，一個完整的標準化服務描述性語言SOAP（Simple Object Access Protocol，簡單對象訪問協議）在某些環境下表現的還不錯。儘管如此，SOAP產品的性能開銷很大，它是一個巨大的性能殺手。雖然REST不是一個標準，但在實現RESTful Web服務時可使用其餘各類標準（好比HTTP、URL、XML、PNG等）。

Session更邪惡

你無需Session！但有人會說：「我想要保存用戶購物車裏的商品，因此我必需要Session！」不，這樣想是錯誤的！即便沒有Session，你也能夠作你任何你想作的事情。你能夠只需在URL裏封裝購物車信息，或者爲購物車建立另外一個資源，好比「/carts/5235」。

不須要與客戶端進行會話，經過這些操做（指在URL裏封裝購物車信息，或者爲購物車建立另外一個資源，好比「/carts/5235」）後，客戶端向服務器發出請求後，哪怕你在服務器上執行卸載平臺和操做系統、拆除服務器硬件、從新組裝服務器、從新安裝操做系統、平臺、應用程序備份恢復操做，也不會影響客戶端。

不要強迫客戶端保存狀態，這樣作不只複雜，並且還會帶來許多問題，你應該從你的Web應用程序裏刪除有狀態的東西。

不要重造超媒體

目前，超媒體已經至關普及，我提醒你們，不要再去從新造輪子。這裏已經有許多，足夠你使用了：

 

• 採用原子連接規範的超媒體，相似spring-hateoas和spring-data-rest。
• JSON-HAL
• JSON-LD
• ……

 

其餘資源

這裏還有一些更加深刻的資源供你參考使用：

 

• Fowlers Article on the Richardson Maturity Model
• A great slide on Hypermedia
• A talk by David Zuelke on RESTful Webservices
• Intro to REST (short video of GoogleDevelopers)
• A talk of Lez Hazlewood (Stormpath)
• A Cookbook for RESTful WebServices
• Great German Book about REST

（編譯：張紅月 責編：王果）

來自： Why REST is so important