restful是一種風格，這個風格是需要在一個空無的條件下形成一系列約束形成的。
全名是representational state transfer:表現層狀態轉換
restful出現是為了保證在大型或者分布式的架構上保證每個組件都能獨自的運行或者修改進化。
restful的約束：
1.客戶端和服務器的分離
2.無狀態，消除session會話，所以在每次交互的時候會有大量的數據在請求中，客戶端也需要維護自己的狀態，這樣就節省很多資源。
3.統一的資源接口/界面：web之間的交互意味着客戶端和服務器和他們之間的中介程序都依賴於接口的統一性
①資源的標識，這里指的是uri
②統過表述對資源進行操縱：這個一般是crud
例子：當獲取到某個api時可以同過修改uri進行修改或刪除這個api的內容
③帶着自我描述性的信息
④超媒體作為應用的程序狀態引擎
例子：用戶通過點擊跳轉頁面時會導致客戶端發生變化，這些變化是超文本的修改，超媒體就是超文本泛化說法，超媒體是告訴客戶端如何使用api。
4.多層架構
5.可緩存
6.按需編碼（可選約束）
Richardson成熟的模型
評價restfulapi的成熟度。理查德森評估模型
level0：POX（plain old xml）
例子：
post(查詢數據)：http://host/myapi
psst（創建數據）：http://host/myapi
這是只是使用http協議，糟糕的的設計，uri只有一個，這種很難維護，而且動詞也使用錯了
level1:Resources
例子：
post： http://host/api/author
post：http://host/api/authors/{id}
使用了不同的uri，相當於資源的定位是正確的，但是請求的動詞不正確，
level2:Http verbs
get：http://host/api/authors 200 ok (authors)
post：(author respresentation) http://host/api/authors 201 created(author)
這里動詞使用正確，並且有統一的uri，這已經是一個不錯的api，但是還打不到真正的restful
level3:Hypermedia Controls
get：http://host/api/authors 200 ok(返回了authors和驅動的應用程序的超鏈接)
API對外合約
api的消費者需要使用三個概念
1.資源標識
2.http方法
3.有效載荷（可選）
資源的命名，使用名詞，而不是動詞
需求：獲取用戶系統里的用戶常見的錯誤做法是：api/getusers.
分析：這句話主要動詞是獲取，而想要獲取資源的是用戶
正確做法：GET api/users
能夠一眼就明白
需求：獲取用戶
可以吧uri設計成api/u或者api/ur
建議是用api/users
體現出資源的結構性
假設api系統有很多資源，而用戶資源與其他資源沒有直接的關系，這樣的話獲取資源的uri應該是api/uers,而不是api/products/users，也不是api/catalogs/products/users
因為user和product或者catalogs都沒直接關系
通過id獲取單個用戶的uri應該：api/users/{userID}，而不是api/userID/users
這樣寫的好處是讓API具有很好的資源預測性和一置性。
例子：
需求：系統有兩類資源，公司和員工心在回去某個公司下所有員工信息
分析：使用GET動詞，API的uri在設計的時候需要體現公司和員工包含關系
常見錯誤做法：api/employess,api/employess/{companyID}
正確做法：GET api/companies/{companyID}/employess
例子：
需求：獲取某個公司的某個員工信息
常見的錯誤做法：api/employess/{employeeID},或者api/companies/{employeeID}
正確做法：api/companies/{companyID}/employees/{employeeID}
例子：
需求：獲取素有用戶，並且結果按照年齡的從小到大排序
常見的錯誤做法：api/users/orderby/age
正確做法：api/users?orderby=name
例子：
需求：獲取用戶的數量
總有一些需求，沒法滿足restful的約束，如果users取出在計算就很浪費資源
妥協做法：api/users/totalamountofuser