摘要:它的理論比較抽象不太具體,理解它主要在于理解這些概念資源表現(xiàn)層狀態(tài)轉(zhuǎn)換。基于原則設(shè)計的,一般稱為,需要遵守以下這些原則。返回結(jié)果,結(jié)果應(yīng)該包括多種情況,異常錯誤信息正確結(jié)果目前而言最好使用格式傳輸數(shù)據(jù)。參考的理解,阮一峰
RESTful API
目前的異步加載橫行的時候,異步請求已經(jīng)遍地都是,而規(guī)定請求接口的時候,如果不能有很好的風(fēng)格的話,很多時候會讓開發(fā)者誤解,一個好的API接口 設(shè)計需要注意以下:
參數(shù)職責(zé)單一
意圖清晰,便于開發(fā)者調(diào)用
易于訪問者輸入
看是但是真的設(shè)計的時候經(jīng)常會設(shè)計出不規(guī)范 的接口,
REST原則REST 即Representational State Transfer的縮寫。它的理論比較抽象不太具體,理解它主要在于理解這些概念:資源、表現(xiàn)層、狀態(tài)轉(zhuǎn)換。
基于REST原則設(shè)計的API,一般稱為 RESTFul API,需要遵守以下這些原則。
URL描述的是一個特定資源。因此描述需要名詞,不能出現(xiàn)動詞。因為動詞描述的不再是資源本身,而是行為
利用HTTP請求的動詞表示對于資源操作的行為
同時,對于URL的設(shè)計一般還有約定俗成的以下補充。
對于資源的描述的名詞應(yīng)該是層級嵌套的方式,比如 /company/department/projects。通過這種對于信息層級描述的方式,更利于實體的抽象,以及增加客戶端與服務(wù)器端開發(fā)人員對于整個系統(tǒng)模塊認(rèn)知的一致性
路徑終點的命名考慮用復(fù)數(shù)形式,比如 /books。一般一個URL路徑表示的資源會映射為數(shù)據(jù)庫一系列表的記錄的集合,因此使用復(fù)數(shù)更直觀
實踐設(shè)計實際設(shè)計restful api時的注意點包括以下:
盡量使用https協(xié)議
如果接口是公用且會被擴展時,應(yīng)該考慮放在專有域名下,https://api.baidu.com
由于api會在業(yè)務(wù)中不斷地迭代,所以最好是帶上版本,https://api.baidu.com/v2/
最后接口路徑應(yīng)該盡量使用集合,也就是復(fù)數(shù)形式,https://api.baidu.com/v2/books
操作類接口應(yīng)該注意使用對應(yīng)的動詞來操作
GET /zoos:列出所有動物園 POST /zoos:新建一個動物園 GET /zoos/ID:獲取某個指定動物園的信息 PUT /zoos/ID:更新某個指定動物園的信息(提供該動物園的全部信息) PATCH /zoos/ID:更新某個指定動物園的信息(提供該動物園的部分信息) DELETE /zoos/ID:刪除某個動物園 GET /zoos/ID/animals:列出某個指定動物園的所有動物 DELETE /zoos/ID/animals/ID:刪除某個指定動物園的指定動物
參數(shù),使用參數(shù)來進(jìn)行篩選,?page=2&per_page=100:指定第幾頁,以及每頁的記錄數(shù)。
返回結(jié)果,結(jié)果應(yīng)該包括多種情況,異常、錯誤信息、正確結(jié)果{status:"ok",massage:"ok",data:{data:1}}
目前而言最好使用JSON格式傳輸數(shù)據(jù)。
參考:efe的restful理解,阮一峰restful api
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/89288.html
摘要:表形容詞,意為的具有的。指的是一組架構(gòu)約束條件和原則。協(xié)議要優(yōu)于協(xié)議。的操作方法在中有各自的語義,理解它們的語義至為重要。返回結(jié)果對于不同操作方法和操作對象集合或個體,服務(wù)器返回的結(jié)果應(yīng)該符合以下規(guī)范。附錄該文主要參考理解架構(gòu)設(shè)計指南 前言 近十年,前端高速發(fā)展,整個互聯(lián)網(wǎng)應(yīng)用經(jīng)歷了從輕客戶端到重客戶端的變化,隨著前端規(guī)模越來越大,交互越來越復(fù)雜,前后端分離的設(shè)計開始流行。 移動互聯(lián)網(wǎng)...
摘要:表形容詞,意為的具有的。指的是一組架構(gòu)約束條件和原則。協(xié)議要優(yōu)于協(xié)議。的操作方法在中有各自的語義,理解它們的語義至為重要。返回結(jié)果對于不同操作方法和操作對象集合或個體,服務(wù)器返回的結(jié)果應(yīng)該符合以下規(guī)范。附錄該文主要參考理解架構(gòu)設(shè)計指南 前言 近十年,前端高速發(fā)展,整個互聯(lián)網(wǎng)應(yīng)用經(jīng)歷了從輕客戶端到重客戶端的變化,隨著前端規(guī)模越來越大,交互越來越復(fù)雜,前后端分離的設(shè)計開始流行。 移動互聯(lián)網(wǎng)...
showImg(https://segmentfault.com/img/bV6aHV?w=1280&h=800); 社區(qū)優(yōu)秀文章 Laravel 5.5+passport 放棄 dingo 開發(fā) API 實戰(zhàn),讓 API 開發(fā)更省心 - 自造車輪。 API 文檔神器 Swagger 介紹及在 PHP 項目中使用 - API 文檔撰寫方案 推薦 Laravel API 項目必須使用的 8 個...
摘要:其他交互一般會遵循一些數(shù)據(jù)結(jié)構(gòu)協(xié)議或者狀態(tài)值,比如不同的操作結(jié)果對應(yīng)不同的狀態(tài)值,且出錯會返回指定的錯誤信息方便前端進(jìn)行提示等。 RESTful這種架構(gòu)已經(jīng)具有很長的時間和歷程了,但似乎最近restful這個詞出現(xiàn)的頻率特別高,目前不是很清楚是因為我自個兒現(xiàn)在是以restful風(fēng)格寫程序產(chǎn)生的孕婦效應(yīng),還是單頁面程序開發(fā)的流行造成的。 其實一開始我也是不想寫這篇文章的,因為網(wǎng)絡(luò)上與re...
摘要:互聯(lián)網(wǎng)通信協(xié)議協(xié)議,是一個無狀態(tài)協(xié)議。具體來說,就是協(xié)議里面,四個表示操作方式的動詞。版本號的版本號和客戶端的版本號是毫無關(guān)系的,不要讓將它們用于提交應(yīng)用市場的版本號傳遞到服務(wù)器,而是提供類似于之類的版本號。版本號拼接在中。 為什么要用 RESTful RESTful 給我的最大感覺就是規(guī)范、易懂和優(yōu)雅,一個結(jié)構(gòu)清晰、易于理解的 API 完全可以省去許多無意義的溝通和文檔。并且 RES...
閱讀 1996·2021-11-24 09:39
閱讀 989·2021-11-11 16:55
閱讀 1443·2021-10-09 09:43
閱讀 1431·2021-10-08 10:17
閱讀 1664·2021-08-25 09:41
閱讀 435·2019-08-30 13:02
閱讀 637·2019-08-29 15:14
閱讀 1014·2019-08-29 13:53