網路應用程式，分為前端和後端兩個部分。當前的發展趨勢，就是前端裝置層出不窮（手機、平板、桌面電腦、其他專用裝置......）。因此，必須有一種統一的機制，方便不同的前端裝置與後端進行通訊。這導致api構架的流行，甚至出現"apifirst"的設計思想。restful api是目前比較成熟的一套網際網路應用程式的api設計理論。
rest（representational state transfer）表述性狀態轉換，rest指的是一組架構約束條件和原則。 如果乙個架構符合rest的約束條件和原則，我們就稱它為restful架構。rest本身並沒有創造新的技術、元件或服務，而隱藏在restful背後的理念就是使用web的現有特徵和能力， 更好地使用現有web標準中的一些準則和約束。雖然rest本身受web技術的影響很深， 但是理論上rest架構風格並不是繫結在http上，只不過目前http是唯一與rest相關的例項。
2.1、推薦格式
1）url格式：
這裡，代表api的版本資訊。是乙個你可以用來定義任何技術的區域(例如：安全-允許指定的使用者可以訪問這個區域。)或者業務上的區域(例如：同樣的功能在同乙個字首之下。)。 代表這個域(domain)下，約定的rest介面集合。
2）引數格式：
get採用兩種常見格式:
②路徑引數，如：
post採用兩種常見格式:
①json格式包裝引數提交
②form表單引數提交
3）返回體格式：
}}
2.2、協議
考慮到服務的安全性，建議使用https作為api的通訊協議，當然http也是可以的。
2.3、網域名稱
建議將api部署在專有網域名稱下，以此遮蔽消費者對服務提供方的部署細節（可借助於平台的反向**+路由閘道器），在服務地圖豐富起來之後可以考慮多級網域名稱。
2.4、版本
考慮到微服務的平滑公升級，可以將api的版本號放入url，也可以將版本號放在http頭資訊中，但不如放入url方便和直觀。github採用這種做法。
2.5、複數名詞路徑
在restful架構中，每個**代表一種資源（resource），所以**中不能有動詞，只能有名詞，而且所用的名詞往往與資料庫的**名對應。一般來說，資料庫中的表都是同種記錄的"集合"（collection），所以api中的名詞也應該使用複數。
2.6、http協議型別表達資源操作
http協議裡的8種方法，及其他衍生方法，常用的get、post可以間接的實現其餘所有的操作，根據框架和瀏覽器的相容性選擇性使用。
1) get（select）：從伺服器取出資源（一項或多項）。
2) post（create）：在伺服器新建乙個資源。
3) put（update）：在伺服器更新資源（客戶端提供改變後的完整資源）。
4) patch（update）：在伺服器更新資源（客戶端提供改變的屬性）。
5) delete（delete）：從伺服器刪除資源
6) head：獲取資源的元資料。
7) options：獲取資訊，關於資源的哪些屬性是客戶端可以改變的。
8) trace：回顯伺服器收到的請求，主要用於測試或診斷。
9) connect：http/1.1協議中預留給能夠將連線改為管道方式的**伺服器。
15) extension-mothed：在不改動協議的前提下，可增加另外的方法。
api.example.com/v1/employees/ 獲取所有雇員
2.7、過濾資訊
請求資訊應該為集合提供過濾、排序、選擇和分頁等功能
1）filtering過濾:
使用唯一的查詢引數進行過濾：
get /cars?color=red 返回紅色的cars
2）sorting排序:
允許針對多個字段排序
get /cars?sort=-manufactorer,+model
這是返回根據生產者降序和模型公升序排列的car集合
3）fieldselection
移動端能夠顯示其中一些字段，它們其實不需要乙個資源的所有字段，給api消費者乙個選擇欄位的能力，這會降低網路流量，提高api可用性。
get /cars?fields=manufacturer,model,id,color
4）paging分頁
使用 limit 和offset.實現分頁，預設limit=20 和offset=0；
get /cars?offset=10&limit=5
為了將總數發給客戶端，使用訂製的http頭：x-total-count.
2.8、返回結果為統一的json格式
一方面，出於平台標準化的api管理，另一方面，遵循微服務的寬進嚴出設計理念，建議restful採用標準的json格式。
返回結構體
}
objectimplements
serializable;
jsonobject.fromobject(json);
jsonobject.parseobject(text)
2.9、返回結果應該包含狀態碼
常見狀態碼
1) 200 ok - [get]：伺服器成功返回使用者請求的資料，該操作是冪等的（idempotent）。
2) 201 created -[post/put/patch]：使用者新建或修改資料成功。
3) 202 accepted - [*]：表示乙個請求已經進入後台排隊（非同步任務）
4) 204 no content - [delete]：使用者刪除資料成功。
5) 400 invalid request -[post/put/patch]：使用者發出的請求有錯誤，伺服器沒有進行新建或修改資料的操作，該操作是冪等的。
6) 401 unauthorized - [*]：表示使用者沒有許可權（令牌、使用者名稱、密碼錯誤）。
7) 403 forbidden - [*] 表示使用者得到授權（與401錯誤相對），但是訪問是被禁止的。
8) 404 not found - [*]：使用者發出的請求針對的是不存在的記錄，伺服器沒有進行操作，該操作是冪等的。
9) 406 not acceptable - [get]：使用者請求的格式不可得（比如使用者請求json格式，但是只有xml格式）。
10) 410gone -[get]：使用者請求的資源被永久刪除，且不會再得到的。
11) 422unprocesable entity - [post/put/patch] 當建立乙個物件時，發生乙個驗證錯誤。
12) 500internal server error - [*]：伺服器發生錯誤，使用者將無法判斷發出的請求是否成功。
返回體結構
2.11、api擴充套件事項
1）restful api依託paas平台治理，需要對api進行認證、授權、引數加密等操作，可考慮在http頭部加認證token、呼叫鏈指令、狀態資訊等系列資訊。
2）如ppt所言，api分層，會有內部api和外部api之分，兩種api的設計或有不同（甚至是不同協議）。
3）對於api設計的狀態選擇，建議為無狀態、n次冪等，但後續或存在效能優化問題，http2.0待評測。
微服務RESTful 介面設計規範
網路應用程式，分為前端和後端兩個部分。當前的發展趨勢，就是前端裝置層出不窮 手機 平板 桌面電腦 其他專用裝置.因此，必須有一種統一的機制，方便不同的前端裝置與後端進行通訊。這導致api構架的流行，甚至出現 apifirst 的設計思想。restful api是目前比較成熟的一套網際網路應用程式的a...
Restful介面設計
rest是英文representational state transfer 表象性狀態轉變 或者表述性狀態轉移 rest是web服務的一種架構風格 使用http,uri,xml,json,html等廣泛流行的標準和協議 輕量級,跨平台,跨語言的架構設計 它是一種設計風格,不是一種標準,是一種思想 ...
RESTFUL介面設計規範
rest 是representational state transfer的縮寫，意思是表述性狀態轉移，我個人理解就是資源資料的變化。api與使用者的通訊協議，總是使用https協議。協議網域名稱 應該盡量將api部署在專用網域名稱之下。如果確定api很簡單，不會有進一步擴充套件，可以考慮放在主網域...