RESTful學習及應用

原文轉自前端路上,轉載請註明出處:http://refined-x.com/2017/09/22/RESTful學習及應用/前端

RESTful是什麼

RESTful是一種API架構,符合REST設計原則的API均可以被稱爲RESTful,REST的全稱是Representational State Transferios

REST的核心原則是後端將資源發佈爲URI,前端經過URI訪問資源,並經過HTTP動詞表示要對資源進行的操做,典型的RESTful API長這樣:web

POST /artical           //增長一篇文章
DELETE /artical/1       //刪除id爲1的文章
PUT /artical/1          //修改id爲1的文章
GET /articals/1         //查詢id爲1的文章

 

這裏須要明確一個概念:資源,後端提供的全部內容均可以被定義爲資源,前端用戶的一切行爲,本質都是與一系列後端資源互動的結果。從這個角度來說,前端的意義就是鏈接用戶與資源,使用戶能以最簡單的方式調度後端資源,並將調度結果以用戶最容易接受的方式呈現出來。npm

爲何使用RESTful

先後端分離的本質是先後端以API爲界限進行開發解耦,因此先後端分離的副產品是大量的API,採用RESTful架構可讓API的表現力更強,更易於被理解;對於接口開發來講,RESTful風格也更易於擴展,這對於大型項目很是重要。axios

RESTful是無狀態的,所以不管前端是什麼設備,前端是什麼狀態,均可以無差異的請求資源,有利於後端實現分佈式。後端

RESTful容許前端索取指定格式的信息,所以能夠實現一套統一的API服務於不一樣的前端設備。數組

如何構建RESTful API

1、每一個網址表明一種資源,網址中只能有名詞

網址僅用來表示資源的名稱,而不包括操做,所以只能由名詞組成;但有些資源可能自帶操做屬性,好比轉帳,這時候咱們應該將轉帳當作一種服務(名詞),將轉帳的其餘信息做爲參數傳遞服務器

2、對於資源的操做類型由HTTP動詞表示

經常使用的四種HTTP動詞以及對應的SQL操做。架構

GET(SELECT):從服務器取出資源(一項或多項)。
POST(CREATE):在服務器新建一個資源。
PUT(UPDATE):在服務器更新資源(客戶端提供改變後的完整資源)
DELETE(DELETE):從服務器刪除資源。

 

3、統一的返回結果

針對不一樣操做,服務器向用戶返回的結果應該符合如下規範。前後端分離

GET /collection:返回資源對象的列表(數組)
GET /collection/resource:返回單個資源對象
POST /collection:返回新生成的資源對象
PUT /collection/resource:返回完整的資源對象
PATCH /collection/resource:返回完整的資源對象
DELETE /collection/resource:返回一個空文檔

 

4、返回正確的狀態碼

經常使用狀態碼

200 :服務器成功返回用戶請求的數據
400 :用戶發出的請求有錯誤
401 :表示用戶沒有權限
403 : 表示用戶獲得受權(與401錯誤相對),但訪問被禁止的
404 :用戶發出的請求針對的是不存在的記錄
500 :服務器發生錯誤,用戶沒法判斷髮出的請求是否成功

 

5、容許經過HTTP內容協商

客戶端能夠經過Accept頭請求一種特定格式的表述,服務端則經過Content-Type告訴客戶端資源的表述形式。若服務器不支持,它應該返回一個HTTP 406響應,表示拒絕處理該請求。

一般項目中最經常使用的仍是直接預約爲JSON格式。

web端的應用

目前最流行的web端AJAX類庫當屬axios,axios與RESTful完美兼容,主要體如今如下幾個方面。

axios將HTTP動詞直接封裝爲方法,正好對應RESTful的API風格,在RESTful架構中使用起來很是方便

axios.post(`/artical`, params)
axios.delete(`/artical/1`, params)
axios.put(`/artical/1`, params)
axios.get(`/artical/1`, params)

 

並且axios的返回數據包括響應正文和狀態碼等信息,配合攔截器很容易實現對RESTful API錯誤碼的統一處理。

//錯誤處理
axios.interceptors.response.use(function(response) {
  return response;
}, function(error) {
  if (error.response) {
    switch (error.response.status) {
      case 400:
        
        break;
      case 401:
        
        break;
      case 403:
        
        break;
      ...
    }
  }
});

 

更多axios內容參考這裏

最後

其實RESTful的絕大多數內容都是規範推薦的作法,沒有什麼新東西,只不過前幾年後端MVC盛行的時期,沒有這麼重的API開發需求,在這方面就一切從簡了,近來遇上先後端分離的東風,API設計又被你們重視起來了,重回規範的RESTful至關於讓你們見識了一下當年規範制定者們的遠見卓識,就像小時候不聽話的孩子在長大的某一天裏忽然想起來長輩曾經的教誨同樣。

相關文章
相關標籤/搜索