REST風格的原則

標籤：http   io   os   使用   on   問題   代碼   html   ad   

一個好的RESTful API，應該具備以下特徵：

1. 這個API應該是對瀏覽器友好的，能夠很好地融入Web，而不是與Web格格不入。

   瀏覽器是最常見和最通用的REST用戶端。好的RESTful API應該能夠使用瀏覽器+HTML完成所有的測試（不需要使用程式設計語言）。這樣的API還可以很方便地使用各種自動化的Web功能測試、效能測試工具來 做測試。Web前端應用（基於瀏覽器的RIA應用、移動App等等）也可以很方便地將多個RESTful API的功能組合起來，建造Mashup類的應用。

2. 這個API中所包含的資源和對於資源的操作，應該是直觀和容易理解的，並且符合HTTP協議的要求。

   REST開發又被稱作“面向資源的開發”，這說明對於資源的抽象，是設計RESTful API的核心內容。RESTful API建模的過程與物件導向建模類似，是以名詞為核心的。這些名詞就是資源，任何可命名的抽象概念都可以定義為一個資源。而HTTP協議並不是一種傳輸協 議，它實際提供了一個操作資源的統一介面。對於資源的任何操作，都應該映射到HTTP的幾個有限的方法（常用的有GET/POST/PUT/DELETE 四個方法，還有不常用的PATCH/HEAD/OPTIONS方法）上面。所以RESTful API建模的過程，可以看作是具有統一介面約束的物件導向建模過程。

   按照HTTP協議的規定，GET方法是安全且等冪的，POST方法是既不安全也不等冪的（可以用來作為所有寫操作的通配方法），PUT、 DELETE方法都是不安全但等冪的。將對資源的操作合理映射到這四個方法上面，既不過度使用某個方法（例如過度使用GET方法或POST方法），也不添 加過多的操作以至於HTTP的四個方法不夠用。

   如果發現資源上的操作過多，以至於HTTP的方法不夠用，應該考慮設計出更多的資源。設計出更多資源（以及相應的URI）對於RESTful API來說並沒有什麼害處。

3. 這個API應該是松耦合的。

   RESTful API的設計包括了三個循序漸進、由低到高的層次：資源抽象、統一介面、超文本驅動。正是這三個層次確保了RESTful API的松耦合性。

   當設計面向互連網的API時，松耦合變成了一種“必須有”的強需求。緊耦合的API非常脆弱，一旦公布出去，伺服器端和用戶端都無法持續進 化。尤其是伺服器端，公布出去的介面根本不敢改，改了之後，幾乎所有用戶端應用立即無法正常工作。REST這種架構風格就是緊耦合API的解毒劑，這個話 題可以談的很深，這裡就不展開了。感興趣的讀者可以參考《REST實戰》。

4. 這個API中所使用的表述格式應該是常見的通用格式

   在RESTful API中，對於資源的操作，是通過在伺服器端-用戶端之間傳遞資源的表述來間接完成的。資源的表述可以有很多種格式，並且在響應和請求中的資源表述格式也 會有所不同。GET/POST響應中的資源表述格式，常見的有HTML、XML、JSON；POST/PUT請求中的資源表述格式，常見的有標準的 HTML表單參數、XML、JSON。

   這些常見表述格式，處理起來非常容易，有大量的架構和庫提供支援。所以除非有很合理的要求，通常不需要使用自訂的私人格式。

5. 使用HTTP響應狀態碼來表達各種出錯情況

   HTTP響應狀態碼，是HTTP協議這個統一介面中用來表達出錯情況的標準機制。響應狀態碼分成兩部分：status code和reason phase。兩部分都是可定製的，也可以使用標準的status code，只定製reason phase。

   如果一個所謂的“RESTful API”對於任何請求都返回200 OK響應，在響應的訊息體中返回出錯情況資訊，這種做法顯然不符合“確保操作語義的可見度”這個REST架構風格的基本要求。

6. 這個API應該對於HTTP緩衝是友好的

   充分利用好HTTP緩衝是RESTful API延展性的根本。HTTP協議是一個分層的架構，從兩端的user agent到origin server之間，可以插入很多中間組件。而在整個HTTP通訊鏈條的很多位置，都可以設定緩衝。HTTP協議內建有很好的緩衝機制，可以分成到期模型和 驗證模型兩套緩衝機制。如果API設計者完全沒有考慮過如何利用HTTP緩衝，那麼這個API的延展性會有很多問題。

REST風格的原則