十萬個為什麼之什麼是resultful規範
起源
越來越多的人開始意識到,網站即軟體,而且是一種新型的軟體。這種"網際網路軟體"採用客戶端/伺服器模式,建立在分散式體系上,通過網際網路通訊,具有高延時(high latency)、高併發等特點。
RESTful架構,就是目前最流行的一種網際網路軟體架構。它結構清晰、符合標準、易於理解、擴充套件方便,所以正得到越來越多網站的採用。
什麼是resultful
REST與技術無關,代表的是一種軟體架構風格,REST是Representational State Transfer的簡稱,中文翻譯為“表徵狀態轉移”
REST從資源的角度類審視整個網路,它將分佈在網路中某個節點的資源通過URL進行標識,客戶端應用通過URL來獲取資源的表徵,獲得這些表徵致使這些應用轉變狀態
所有的資料,不過是通過網路獲取的還是操作(增刪改查)的資料,都是資源,將一切資料視為資源是REST區別與其他架構風格的最本質屬性。
對於REST這種面向資源的架構風格,有人提出一種全新的結構理念,即:面向資源架構(ROA:Resource Oriented Architecture)
resultful API規範
- 根據method的不同,做不同的操作
示例:
@app.route('/order',methods=['GET','POST','PUT','DELETE']) def order(): if request.method == 'GET': return '獲取資料' elif request.method == 'POST': return '建立資料' elif request.method == 'PUT': return '更新資料' elif request.method == 'DELETE': return '刪除資料'
method還有patch
put 是在伺服器更新全部資源
patch 是在伺服器上更新區域性資源
- API與使用者的通訊協議,總是使用HTTPs協議。
- 域名
子域名方式(解決跨域問題):
如
www.huangyongpeng.com
api.huangyongpeng.com(存在跨域問題)
url方式:
如
www.huangyongpeng.com
www.huangyongpeng.com/api/
這樣別人一看到這種url就知道這是一個介面。
- 版本
url:
www.huangyongpeng.com/api/v1/
也可以寫在請求頭裡面(不太明白, 有些是規定要寫在請求頭裡 ,但實際使用卻是在url中, 活學活用吧大概是);
- 面向資源程式設計
網路上任何東西都是資源,均使用名詞表示
如一開始用的order
www.huangyongpeng.com/api/v1/order/
- 過濾,通過在url上傳參的形式傳遞搜尋條件
如:
www.huangyongpeng/api/v1/order?page=2翻到第二頁
- 狀態碼
常用的有以下幾個:
200 OK - [GET]:伺服器成功返回使用者請求的資料,該操作是冪等的(Idempotent)。
201 CREATED - [POST/PUT/PATCH]:使用者新建或修改資料成功。
202 Accepted - [*]:表示一個請求已經進入後臺排隊(非同步任務)
204 NO CONTENT - [DELETE]:使用者刪除資料成功。
400 INVALID REQUEST - [POST/PUT/PATCH]:使用者發出的請求有錯誤,伺服器沒有進行新建或修改資料的操作,該操作是冪等的。
401 Unauthorized - [*]:表示使用者沒有許可權(令牌、使用者名稱、密碼錯誤)。
403 Forbidden - [*] 表示使用者得到授權(與401錯誤相對),但是訪問是被禁止的。
404 NOT FOUND - [*]:使用者發出的請求針對的是不存在的記錄,伺服器沒有進行操作,該操作是冪等的。
406 Not Acceptable - [GET]:使用者請求的格式不可得(比如使用者請求JSON格式,但是隻有XML格式)。
410 Gone -[GET]:使用者請求的資源被永久刪除,且不會再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 當建立一個物件時,發生一個驗證錯誤。
500 INTERNAL SERVER ERROR - [*]:伺服器發生錯誤,使用者將無法判斷髮出的請求是否成功。
一般可以這樣看
200系列是成功
300系列是重定向問題
400系列客服端錯誤
500系列服務端錯誤
但是僅僅靠狀態碼是不能全部表示資料的狀態的,所以在返回時用code和狀態碼結合。
- 錯誤處理,返回錯誤資訊
返回body內容中, 可提示對應msg資訊
- 返回結果,針對不同操作
伺服器向用戶返回的結果應該符合以下規範
GET /order/
返回資源物件的列表(陣列)
GET /order/1/
返回單個資源物件
POST /order/
返回新生成的資源物件
PUT /order/1/
返回完整的資源物件
PATCH /order/1/
返回完整的資源物件
DELETE /order/1/
返回一個空文件
- Hypermedia API
RESTful API最好做到Hypermedia,即返回結果中提供連結,連向其他API方法,使得使用者不查文件,也知道下一步應該做什麼
resultful其實本質上就是一個規範,定義一些規範讓我們寫API的時候更好作區分,讓後臺更好作處理,讓我們的前臺更好的記住這些url,說白了就是在這個url體現出對這個API的操作。遵循這個規範,就是讓大家在協同開發的時候,相互之間更加統一了。
原來我們沒用API之前,我們用的是get,post…全都能實現,但只不過url得儲存好多個,學了resultful API之後,才漸漸的去使用,但使用的過程中,也會發現有的能適用,有的不能適用。