RFC一致性 Methods GET: 獲取某個資源，冪等且無副作用。 POST: 創建一個新的資源。 PUT: 替換某個已有的資源。冪等有副作用。 PATCH: 修改某個已有的資源。 DELETE：刪除某個資源。冪等有副作用。 Headers Accept：伺服器需要返回什麼樣的content。
RFC一致性
Methods
GET: 獲取某個資源，冪等且無副作用。
POST: 創建一個新的資源。
PUT: 替換某個已有的資源。冪等有副作用。
PATCH: 修改某個已有的資源。
DELETE：刪除某個資源。冪等有副作用。
Headers
Accept：伺服器需要返回什麼樣的content。
If-Modified-Since/If-None-Match：如果客戶端提供某個條件，那麼當這條件滿足時，才返回數據，否則返回304 not modified。
If-Match：在對某個資源做PUT/PATCH/DELETE操作時，伺服器應該要求客戶端提供If-Match頭，只有客戶端提供的Etag與伺服器對應資源的Etag一致，才進行操作，否則返回412 precondition failed。
返回恰當的Status Code
安全性
一致性，機密性，和可用性
請求數據驗證
Request headers是否合法：如果出現了某些不該有的頭，或者某些必須包含的頭沒有出現或者內容不合法，根據其錯誤類型一律返回4xx。
可以在HTTP頭中增加X-Request-ID標識調用者身份。
示例：
GET /photos/puppy.jpg HTTP/1.1
X-Request-ID: 1pvs6edg31p92bld853plok8b4
Request URI和Request body是否合法：如果請求帶有了不該有的數據，或者某些必須包含的數據沒有出現或內容不合法，一律返回4xx。
數據完整性驗證
數據完整性驗證的底線是：保證要修改的數據和伺服器里的數據是一致的 —— 這是通過Etag來完成。
Etag可以認為是某個資源的一個唯一的版本號。當客戶端請求某個資源時，該資源的Etag一同被返回，而當客戶端需要修改該資源時，需要通過"If-Match"頭來提供這個Etag。
伺服器檢查客戶端提供的Etag是否和伺服器同一資源的Etag相同，如果相同，才進行修改，否則返回412 precondition failed。
訪問控制
REST API需要清晰定義哪些操作能夠公開訪問，哪些操作需要授權訪問。
在HTTP協議之上處理授權有很多方法，如HTTP BASIC Auth，OAuth，HMAC Auth等，其核心思想都是驗證某個請求是由一個合法的請求者發起。
HMAC Auth保證一致性：請求的數據在傳輸過程中未被修改，因此可以安全地用於驗證請求的合法性。
HMAC主要在請求頭中使用兩個欄位：Authorization和Date（或X-Auth-Timestamp）。
Authorization欄位的內容由":"分隔成兩部分，":"前是access-key，":"後是HTTP請求的HMAC值。 在做HMAC的時候，request headers中的request method，request URI，Date/X-Auth-Timestamp等header會被計算在HMAC中。
示例：
GET /photos/puppy.jpg HTTP/1.1
X-Auth-Timestamp: Mon, 26 Mar 2007 19:37:58 +0000
Authorization: AKIAIOSFODNN7EXAMPLE:frJIUN8DYpKDtOLCwo//yllqDzg=
將時間戳計算在HMAC中的好處是可以防止replay攻擊。一個請求攜帶的時間戳，和該請求到達伺服器時伺服器的時間戳，中間差別太大，超過某個閾值（比如說120s），那麼可以認為是replay，伺服器主動丟棄該請求。
需要保證傳輸內容安全，使用HTTPS加密傳輸。
其他
rate limiting：訪問限制。
metrics：伺服器應該收集每個請求的訪問時間，到達時間，處理時間，latency，便於瞭解API的性能和客戶端的訪問分佈，以便更好地優化性能和應對突發請求。
docs：豐富的介面文檔 —— API的調用者需要詳盡的文檔來正確調用API，可以用swagger來實現。
hooks/event propogation：其他系統能夠比較方便地與該API集成。
參考文章：http://kb.cnblogs.com/page/521718/
作者: programmer_life
