REST風格的原則

一個好的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。