技術(shù)由來：

互聯(lián)網(wǎng)早期，頁面請求和并發(fā)量不高，且移動端未盛行時對接口要求不高，使用動態(tài)頁面(jsp)就能滿足絕大多數(shù)的使用需求。但是隨著互聯(lián)網(wǎng)和移動設(shè)備的發(fā)展，人們對Web應(yīng)用的使用需求也增加，傳統(tǒng)的動態(tài)頁面由于低效率而漸漸被HTML+JavaScript(Ajax)的前后端分離所取代，并且安卓、IOS、小程序等形式客戶端層出不窮，客戶端的種類出現(xiàn)多元化，而客戶端和服務(wù)端就需要接口進(jìn)行通信，但接口的規(guī)范性就又成了一個問題：

所以一套結(jié)構(gòu)清晰、符合標(biāo)準(zhǔn)、易于理解、擴展方便讓大部分人都能夠理解接受的接口風(fēng)格就顯得越來越重要，而RESTful風(fēng)格的接口(RESTful API)剛好有以上特點，就逐漸被實踐應(yīng)用而變得流行起來。

使用resetful設(shè)計的接口特點：看Url就知道要什么資源數(shù)據(jù)，看http method就知道進(jìn)行什么操作！

所以RESTful API就是一套接口設(shè)計風(fēng)格，用來規(guī)范多種形式的前端和同一個后臺的交互方式。

?

使用場景：

前后端分離。前端拿到數(shù)據(jù)只負(fù)責(zé)展示和渲染，不對數(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)移。字面理解太復(fù)雜了，先簡單理解為：URL定位資源，用HTTP動詞（GET,POST,DELETE,DETC）描述操作。

REST描述的是在網(wǎng)絡(luò)中client和server的一種交互形式；REST并沒有一個明確的標(biāo)準(zhǔn)，而更像是一種設(shè)計的風(fēng)格，滿足這種設(shè)計風(fēng)格的程序或接口我們稱之為RESTful(從單詞字面來看就是一個形容詞)。所以RESTful API 就是滿足REST架構(gòu)特征的接口。

?

?

?

REST架構(gòu)特征和設(shè)計規(guī)范：

?

• URI指向資源：使用URI = Universal Resource Identifier 統(tǒng)一資源標(biāo)志符，用來標(biāo)識抽象或物理資源的一個緊湊字符串。URI包括URL和URN，在這里更多時候可能代指URL(統(tǒng)一資源定位符)。RESTful是面向資源的，每種資源可能由一個或多個URI對應(yīng)，但一個URI只指向一種資源。注意：使用名詞的復(fù)數(shù)表示一個資源集合，如api.domain.com/users；使用斜線“/”用來表示資源之間的層次關(guān)系，如api.domain.com/users/1234/orders；URI 中應(yīng)盡量使用小寫字母，不實用下劃線；URL末尾不應(yīng)包含斜線“/”；

?

• 統(tǒng)一接口: 通過一定原則設(shè)計接口降低耦合，簡化系統(tǒng)架構(gòu)，這是RESTful設(shè)計的基本出發(fā)點。對資源的操作包括獲取、創(chuàng)建、修改和刪除，這些操作正好對應(yīng)HTTP協(xié)議提供的GET、POST、PUT和DELETE方法。換言而知，使用RESTful風(fēng)格的接口但從接口上你可能只能定位其資源，但是無法知曉它具體進(jìn)行了什么操作，需要具體了解其發(fā)生了什么操作動作要從其HTTP請求方法類型上進(jìn)行判斷。具體的HTTP方法和方法含義如下圖1，這樣就統(tǒng)一了數(shù)據(jù)操作的接口。

? ? ? ? 非RESTful風(fēng)格的API中，我們通常使用GET請求和POST請求完成增刪改查以及其他操作，查詢和刪除一般使用GET方式請求，更新和插入一般使用POST請求。從請求方式上無法知道API具體是干嘛的，所有在URL上都會有操作的動詞來表示API進(jìn)行的動? ? ? ? ?作，例如：query，add，update，delete等等。而RESTful風(fēng)格的API則要求在URL上都以名詞（推薦用復(fù)數(shù)）的方式出現(xiàn)，從幾種請求方式上就可以看出想要進(jìn)行的操作，這點與非RESTful風(fēng)格的API形成鮮明對比。在談及GET,POST,PUT,DELETE的時候，就必須提一下接口的安全性和冪等性，其中安全性是指方法不會修改資源狀態(tài)，即讀的為安全的，寫的操作為非安全的。而冪等性的意思是操作一次和操作多次的最終效果相同，客戶端重復(fù)調(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的會員新增好友。其他的操作類似就不舉例了。

? ? ?如果一個操作無法對應(yīng)到資源的某個操作上，此時可以適當(dāng)?shù)卦赨RI中包含動詞，但依然應(yīng)該基于一個資源的標(biāo)識符。例如：DELETE /users/1234/set-admin

?

• 無狀態(tài)。服務(wù)器不能保存客戶端的信息， 每一次從客戶端發(fā)送的請求中，要包含所有必須的狀態(tài)信息，會話信息由客戶端保存， 服務(wù)器端根據(jù)這些狀態(tài)信息來處理請求。 當(dāng)客戶端可以切換到一個新狀態(tài)的時候發(fā)送請求信息， 當(dāng)一個或者多個請求被發(fā)送之后, 客戶端就處于一個狀態(tài)變遷過程中。 每一個應(yīng)用的狀態(tài)描述可以被客戶端用來初始化下一次的狀態(tài)變遷。

?

• 狀態(tài)碼和返回數(shù)據(jù)

? ? ? ?服務(wù)端處理完成后客戶端也可能不知道具體成功了還是失敗了，服務(wù)器響應(yīng)時，包含狀態(tài)碼和返回數(shù)據(jù)兩個部分。

? ? ??

? ? ? ?

?

{ //響應(yīng)格式status:0,data:{}||[],msg:’’ }

? ?

• 過濾信息：可以使用過濾信息進(jìn)行篩選、搜索或分頁查詢等

? ? ? ?

?

• 可緩存性（Cacheability）?：服務(wù)端需回復(fù)是否可以緩存以讓客戶端甄別是否緩存提高效率。
• 版本號：可以將API的版本號放入URL。GET:http://www.xxx.com/v1/friend/123。或者將版本號放在HTTP頭信息中。

?

?

總結(jié)：

RESTful風(fēng)格的API 固然很好很規(guī)范，但大多數(shù)互聯(lián)網(wǎng)公司并沒有按照或者完全按照其規(guī)則來設(shè)計，因為REST是一種風(fēng)格，而不是一種約束或規(guī)則，過于理想的RESTful API 會付出太多的成本。

比如RESTful API也有一些缺點

• 比如操作方式繁瑣，RESTful API通常根據(jù)GET、POST、PUT、DELETE 來區(qū)分操作資源的動作，而HTTP Method 本身不可直接見，是隱藏的，而如果將動作放到URL的path上反而清晰可見，更利于團隊的理解和交流。
• 并且有些瀏覽器對GET,POST之外的請求支持不太友好，還需要特殊額外的處理。
• 過分強調(diào)資源，而實際業(yè)務(wù)API可能有各種需求比較復(fù)雜，單單使用資源的增刪改查可能并不能有效滿足使用需求，強行使用RESTful風(fēng)格API只會增加開發(fā)難度和成本。

所以，當(dāng)你或你們的技術(shù)團隊在設(shè)計API的時候，如果使用場景和REST風(fēng)格很匹配，那么你們可以采用RESTful 風(fēng)格API。但是如果業(yè)務(wù)需求和RESTful風(fēng)格API不太匹配或者很麻煩，那也可以不用RESTful風(fēng)格API或者可以借鑒一下，畢竟無論那種風(fēng)格的API都是為了方便團隊開發(fā)、協(xié)商以及管理，不能墨守成規(guī)。

?

參考學(xué)習(xí)文章：

https://www.toutiao.com/i6693727878158221836/

https://www.toutiao.com/a6902604637149692428/

?

總結(jié)

以上是生活随笔為你收集整理的restful api接口设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。