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

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

這個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來說并沒有什么害處。

這個API應該是松耦合的。

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

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

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

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

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

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

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

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

這個API應該對于HTTP緩存是友好的

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