restful api接口设计
技術(shù)由來：
互聯(lián)網(wǎng)早期，頁面請求和并發(fā)量不高，且移動端未盛行時對接口要求不高，使用動態(tài)頁面(jsp)就能滿足絕大多數(shù)的使用需求。但是隨著互聯(lián)網(wǎng)和移動設備的發(fā)展，人們對Web應用的使用需求也增加，傳統(tǒng)的動態(tài)頁面由于低效率而漸漸被HTML+JavaScript(Ajax)的前后端分離所取代，并且安卓、IOS、小程序等形式客戶端層出不窮，客戶端的種類出現(xiàn)多元化，而客戶端和服務端就需要接口進行通信，但接口的規(guī)范性就又成了一個問題：
所以一套結(jié)構(gòu)清晰、符合標準、易于理解、擴展方便讓大部分人都能夠理解接受的接口風格就顯得越來越重要，而RESTful風格的接口(RESTful API)剛好有以上特點，就逐漸被實踐應用而變得流行起來。
使用resetful設計的接口特點：看Url就知道要什么資源數(shù)據(jù)，看http method就知道進行什么操作！
所以RESTful API就是一套接口設計風格，用來規(guī)范多種形式的前端和同一個后臺的交互方式。
?
使用場景：
前后端分離。前端拿到數(shù)據(jù)只負責展示和渲染，不對數(shù)據(jù)做任何處理。后端處理數(shù)據(jù)并以JSON格式傳輸出去，定義這樣一套統(tǒng)一的接口，在web，ios，android三端都可以用相同的接口，節(jié)約開發(fā)成本以及便于同一調(diào)試。
?
?
區(qū)分REST和RESTful ：
REST是幾個單詞縮寫 -- REpresentational State Transfer 直接翻譯：表現(xiàn)層狀態(tài)轉(zhuǎn)移。字面理解太復雜了，先簡單理解為：URL定位資源，用HTTP動詞（GET,POST,DELETE,DETC）描述操作。
REST描述的是在網(wǎng)絡中client和server的一種交互形式；REST并沒有一個明確的標準，而更像是一種設計的風格，滿足這種設計風格的程序或接口我們稱之為RESTful(從單詞字面來看就是一個形容詞)。所以RESTful API 就是滿足REST架構(gòu)特征的接口。
?
?
?
REST架構(gòu)特征和設計規(guī)范：
?
- URI指向資源：使用URI = Universal Resource Identifier 統(tǒng)一資源標志符，用來標識抽象或物理資源的一個緊湊字符串。URI包括URL和URN，在這里更多時候可能代指URL(統(tǒng)一資源定位符)。RESTful是面向資源的，每種資源可能由一個或多個URI對應，但一個URI只指向一種資源。注意：使用名詞的復數(shù)表示一個資源集合，如api.domain.com/users；使用斜線“/”用來表示資源之間的層次關(guān)系，如api.domain.com/users/1234/orders；URI 中應盡量使用小寫字母，不實用下劃線；URL末尾不應包含斜線“/”；
?
- 統(tǒng)一接口: 通過一定原則設計接口降低耦合，簡化系統(tǒng)架構(gòu)，這是RESTful設計的基本出發(fā)點。對資源的操作包括獲取、創(chuàng)建、修改和刪除，這些操作正好對應HTTP協(xié)議提供的GET、POST、PUT和DELETE方法。換言而知，使用RESTful風格的接口但從接口上你可能只能定位其資源，但是無法知曉它具體進行了什么操作，需要具體了解其發(fā)生了什么操作動作要從其HTTP請求方法類型上進行判斷。具體的HTTP方法和方法含義如下圖1，這樣就統(tǒng)一了數(shù)據(jù)操作的接口。
? ? ? ? 非RESTful風格的API中，我們通常使用GET請求和POST請求完成增刪改查以及其他操作，查詢和刪除一般使用GET方式請求，更新和插入一般使用POST請求。從請求方式上無法知道API具體是干嘛的，所有在URL上都會有操作的動詞來表示API進行的動? ? ? ? ?作，例如：query，add，update，delete等等。而RESTful風格的API則要求在URL上都以名詞（推薦用復數(shù)）的方式出現(xiàn)，從幾種請求方式上就可以看出想要進行的操作，這點與非RESTful風格的API形成鮮明對比。在談及GET,POST,PUT,DELETE的時候，就必須提一下接口的安全性和冪等性，其中安全性是指方法不會修改資源狀態(tài)，即讀的為安全的，寫的操作為非安全的。而冪等性的意思是操作一次和操作多次的最終效果相同，客戶端重復調(diào)用也只返回同一個結(jié)果。
? ? ? ?
? ? ? ?上述四個HTTP請求方法的安全性和冪等性如下：
? ? ??
?
? ? ? 舉例子：說了這么多，到底RESTful長什么樣子的呢？
- ? GET:http://www.xxx.com/source/id 獲取指定ID的某一類資源。
- ? 例如GET:http://www.xxx.com/friends/123表示獲取ID為123的會員的好友列表。如果不加id就表示獲取所有會員的好友列表。
- ? POST:http://www.xxx.com/friends/123表示為指定ID為123的會員新增好友。其他的操作類似就不舉例了。
? ? ?如果一個操作無法對應到資源的某個操作上，此時可以適當?shù)卦赨RI中包含動詞，但依然應該基于一個資源的標識符。例如：DELETE /users/1234/set-admin
?
- 無狀態(tài)。服務器不能保存客戶端的信息， 每一次從客戶端發(fā)送的請求中，要包含所有必須的狀態(tài)信息，會話信息由客戶端保存， 服務器端根據(jù)這些狀態(tài)信息來處理請求。 當客戶端可以切換到一個新狀態(tài)的時候發(fā)送請求信息， 當一個或者多個請求被發(fā)送之后, 客戶端就處于一個狀態(tài)變遷過程中。 每一個應用的狀態(tài)描述可以被客戶端用來初始化下一次的狀態(tài)變遷。
?
- 狀態(tài)碼和返回數(shù)據(jù)
? ? ? ?服務端處理完成后客戶端也可能不知道具體成功了還是失敗了，服務器響應時，包含狀態(tài)碼和返回數(shù)據(jù)兩個部分。
? ? ??
? ? ? ?
?
{ //響應格式status:0,data:{}||[],msg:’’ }? ?
- 過濾信息：可以使用過濾信息進行篩選、搜索或分頁查詢等
? ? ? ?
?
- 可緩存性（Cacheability）?：服務端需回復是否可以緩存以讓客戶端甄別是否緩存提高效率。
- 版本號：可以將API的版本號放入URL。GET:http://www.xxx.com/v1/friend/123。或者將版本號放在HTTP頭信息中。
?
?
總結(jié)：
RESTful風格的API 固然很好很規(guī)范，但大多數(shù)互聯(lián)網(wǎng)公司并沒有按照或者完全按照其規(guī)則來設計，因為REST是一種風格，而不是一種約束或規(guī)則，過于理想的RESTful API 會付出太多的成本。
比如RESTful API也有一些缺點
- 比如操作方式繁瑣，RESTful API通常根據(jù)GET、POST、PUT、DELETE 來區(qū)分操作資源的動作，而HTTP Method 本身不可直接見，是隱藏的，而如果將動作放到URL的path上反而清晰可見，更利于團隊的理解和交流。
- 并且有些瀏覽器對GET,POST之外的請求支持不太友好，還需要特殊額外的處理。
- 過分強調(diào)資源，而實際業(yè)務API可能有各種需求比較復雜，單單使用資源的增刪改查可能并不能有效滿足使用需求，強行使用RESTful風格API只會增加開發(fā)難度和成本。
所以，當你或你們的技術(shù)團隊在設計API的時候，如果使用場景和REST風格很匹配，那么你們可以采用RESTful 風格API。但是如果業(yè)務需求和RESTful風格API不太匹配或者很麻煩，那也可以不用RESTful風格API或者可以借鑒一下，畢竟無論那種風格的API都是為了方便團隊開發(fā)、協(xié)商以及管理，不能墨守成規(guī)。
?
參考學習文章：
https://www.toutiao.com/i6693727878158221836/
https://www.toutiao.com/a6902604637149692428/
?
總結(jié)
以上是生活随笔為你收集整理的restful api接口设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【数据竞赛】基于LSTM模型实现共享自行
- 下一篇： (视频+图文)机器学习入门系列-第9章