十萬個爲何之什麼是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以後，才漸漸的去使用，但使用的過程當中，也會發現有的能適用，有的不能適用。