2020-12-21 RESTful API

https://www.cnblogs.com/softidea/p/10158703.html
https://sscms.com/docs/v6/api/guide

用一句話來概括RESTful API(具有REST風(fēng)格的API):
用URL定位資源猎荠,
用HTTP動詞(GET,HEAD,POST,PUT,PATCH,DELETE)描述操作椅贱,用響應(yīng)狀態(tài)碼表示操作結(jié)果降狠。

HTTP動詞 說明
GET 安全锭硼、冪等翩剪; 用于獲取資源腕柜;getUserById getUserList
HEAD 安全膀篮、冪等毯焕; 與get方法類似衍腥,但不返回message body內(nèi)容,僅僅是獲得獲取資源的部分信息(content-type纳猫、content-length)restful框架中較少使用
POST 非安全婆咸、非冪等; 用于創(chuàng)建子資源addUser addUserList
PUT 非安全芜辕、冪等尚骄; 用于創(chuàng)建、更新資源侵续;(客戶端改變后的完整資源) updateUser
DELETE 非安全倔丈、冪等憨闰; 刪除資源;delUser
OPTIONS 安全需五、冪等鹉动; 用于url驗(yàn)證,驗(yàn)證接口服務(wù)是否正常宏邮;
TRACE 安全泽示、冪等; “回顯服務(wù)器收到的請求蜜氨,這樣客戶端可以看到(如果有)哪一些改變或者添加已經(jīng)被中間服務(wù)器實(shí)現(xiàn)械筛。”restful框架中較少使用
PATCH 非安全飒炎、冪等埋哟; 用于創(chuàng)建、更新資源厌丑,于PUT類似定欧,區(qū)別在于PATCH代表部分更新渔呵;updateUserList

GET(SELECT):從服務(wù)器獲取資源(一個資源或資源集合)怒竿。

POST(CREATE):在服務(wù)器新建一個資源(也可以用于更新資源)。

PUT(UPDATE):在服務(wù)器更新資源(客戶端提供改變后的完整資源)扩氢。

PATCH(UPDATE):在服務(wù)器更新資源(客戶端提供改變的部分)耕驰。

DELETE(DELETE):從服務(wù)器刪除資源。

HEAD:獲取資源的元數(shù)據(jù)录豺。

OPTIONS:獲取信息朦肘,關(guān)于資源的哪些屬性是客戶端可以改變的。

GET双饥、HEAD媒抠、PUT、DELETE方法是冪等方法(對于同一個內(nèi)容的請求咏花,發(fā)出n次的效果與發(fā)出1次的效果相同)趴生。

GET、HEAD方法是安全方法(不會造成服務(wù)器上資源的改變)昏翰。

PATCH不一定是冪等的苍匆。PATCH的實(shí)現(xiàn)方式有可能是"提供一個用來替換的數(shù)據(jù)",也有可能是"提供一個更新數(shù)據(jù)的方法"(比如data++)棚菊。如果是后者浸踩,那么PATCH不是冪等的。

URI

可以用一個URI(統(tǒng)一資源定位符)指向資源统求,即每個URI都對應(yīng)一個特定的資源检碗。要獲取這個資源据块,訪問它的URI就可以,因此URI就成了每一個資源的地址或識別符后裸。

一般的瑰钮,每個資源至少有一個URI與之對應(yīng),最典型的URI即URL微驶。

RESTful API 設(shè)計(jì)指南

作者: 阮一峰

網(wǎng)絡(luò)應(yīng)用程序浪谴,分為前端和后端兩個部分。當(dāng)前的發(fā)展趨勢因苹,就是前端設(shè)備層出不窮(手機(jī)苟耻、平板、桌面電腦扶檐、其他專用設(shè)備......)凶杖。

因此,必須有一種統(tǒng)一的機(jī)制款筑,方便不同的前端設(shè)備與后端進(jìn)行通信智蝠。這導(dǎo)致API構(gòu)架的流行,甚至出現(xiàn)"API First"的設(shè)計(jì)思想奈梳。RESTful API是目前比較成熟的一套互聯(lián)網(wǎng)應(yīng)用程序的API設(shè)計(jì)理論杈湾。我以前寫過一篇《理解RESTful架構(gòu)》,探討如何理解這個概念攘须。

今天漆撞,我將介紹RESTful API的設(shè)計(jì)細(xì)節(jié),探討如何設(shè)計(jì)一套合理于宙、好用的API浮驳。我的主要參考了兩篇文章(12)捞魁。

一至会、協(xié)議

API與用戶的通信協(xié)議,總是使用HTTPs協(xié)議谱俭。

二奉件、域名

應(yīng)該盡量將API部署在專用域名之下。


https://api.example.com

如果確定API很簡單旺上,不會有進(jìn)一步擴(kuò)展瓶蚂,可以考慮放在主域名下。


https://example.org/api/

三宣吱、版本(Versioning)

應(yīng)該將API的版本號放入URL窃这。


https://api.example.com/v1/

另一種做法是,將版本號放在HTTP頭信息中,但不如放入URL方便和直觀杭攻。Github采用這種做法祟敛。

四、路徑(Endpoint)

路徑又稱"終點(diǎn)"(endpoint)兆解,表示API的具體網(wǎng)址馆铁。

在RESTful架構(gòu)中,每個網(wǎng)址代表一種資源(resource)锅睛,所以網(wǎng)址中不能有動詞埠巨,只能有名詞,而且所用的名詞往往與數(shù)據(jù)庫的表格名對應(yīng)现拒。一般來說辣垒,數(shù)據(jù)庫中的表都是同種記錄的"集合"(collection),所以API中的名詞也應(yīng)該使用復(fù)數(shù)印蔬。

舉例來說勋桶,有一個API提供動物園(zoo)的信息,還包括各種動物和雇員的信息侥猬,則它的路徑應(yīng)該設(shè)計(jì)成下面這樣例驹。

五、HTTP動詞

對于資源的具體操作類型退唠,由HTTP動詞表示鹃锈。

常用的HTTP動詞有下面五個(括號里是對應(yīng)的SQL命令)。

  • GET(SELECT):從服務(wù)器取出資源(一項(xiàng)或多項(xiàng))铜邮。
  • POST(CREATE):在服務(wù)器新建一個資源仪召。
  • PUT(UPDATE):在服務(wù)器更新資源(客戶端提供改變后的完整資源)寨蹋。
  • PATCH(UPDATE):在服務(wù)器更新資源(客戶端提供改變的屬性)松蒜。
  • DELETE(DELETE):從服務(wù)器刪除資源。

還有兩個不常用的HTTP動詞已旧。

  • HEAD:獲取資源的元數(shù)據(jù)秸苗。
  • OPTIONS:獲取信息,關(guān)于資源的哪些屬性是客戶端可以改變的运褪。

下面是一些例子惊楼。

  • 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:刪除某個指定動物園的指定動物

六、過濾信息(Filtering)

如果記錄數(shù)量很多秸讹,服務(wù)器不可能都將它們返回給用戶檀咙。API應(yīng)該提供參數(shù),過濾返回結(jié)果璃诀。

下面是一些常見的參數(shù)弧可。

  • ?limit=10:指定返回記錄的數(shù)量
  • ?offset=10:指定返回記錄的開始位置。
  • ?page=2&per_page=100:指定第幾頁劣欢,以及每頁的記錄數(shù)棕诵。
  • ?sortby=name&order=asc:指定返回結(jié)果按照哪個屬性排序裁良,以及排序順序。
  • ?animal_type_id=1:指定篩選條件

參數(shù)的設(shè)計(jì)允許存在冗余校套,即允許API路徑和URL參數(shù)偶爾有重復(fù)价脾。比如,GET /zoo/ID/animals 與 GET /animals?zoo_id=ID 的含義是相同的笛匙。

七侨把、狀態(tài)碼(Status Codes)

服務(wù)器向用戶返回的狀態(tài)碼和提示信息,常見的有以下一些(方括號中是該狀態(tài)碼對應(yīng)的HTTP動詞)妹孙。

  • 200 OK - [GET]:服務(wù)器成功返回用戶請求的數(shù)據(jù)座硕,該操作是冪等的(Idempotent)。
  • 201 CREATED - [POST/PUT/PATCH]:用戶新建或修改數(shù)據(jù)成功涕蜂。
  • 202 Accepted - [*]:表示一個請求已經(jīng)進(jìn)入后臺排隊(duì)(異步任務(wù))
  • 204 NO CONTENT - [DELETE]:用戶刪除數(shù)據(jù)成功华匾。
  • 400 INVALID REQUEST - [POST/PUT/PATCH]:用戶發(fā)出的請求有錯誤,服務(wù)器沒有進(jìn)行新建或修改數(shù)據(jù)的操作机隙,該操作是冪等的蜘拉。
  • 401 Unauthorized - [*]:表示用戶沒有權(quán)限(令牌、用戶名有鹿、密碼錯誤)旭旭。
  • 403 Forbidden - [*] 表示用戶得到授權(quán)(與401錯誤相對),但是訪問是被禁止的葱跋。
  • 404 NOT FOUND - [*]:用戶發(fā)出的請求針對的是不存在的記錄持寄,服務(wù)器沒有進(jìn)行操作,該操作是冪等的娱俺。
  • 406 Not Acceptable - [GET]:用戶請求的格式不可得(比如用戶請求JSON格式稍味,但是只有XML格式)。
  • 410 Gone -[GET]:用戶請求的資源被永久刪除荠卷,且不會再得到的模庐。
  • 422 Unprocesable entity - [POST/PUT/PATCH] 當(dāng)創(chuàng)建一個對象時,發(fā)生一個驗(yàn)證錯誤油宜。
  • 500 INTERNAL SERVER ERROR - [*]:服務(wù)器發(fā)生錯誤掂碱,用戶將無法判斷發(fā)出的請求是否成功。

狀態(tài)碼的完全列表參見這里慎冤。

八疼燥、錯誤處理(Error handling)

如果狀態(tài)碼是4xx,就應(yīng)該向用戶返回出錯信息蚁堤。一般來說醉者,返回的信息中將error作為鍵名,出錯信息作為鍵值即可。


{
    error: "Invalid API key"
}

九湃交、返回結(jié)果

針對不同操作熟空,服務(wù)器向用戶返回的結(jié)果應(yīng)該符合以下規(guī)范。

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

十搞莺、Hypermedia API

RESTful API最好做到Hypermedia息罗,即返回結(jié)果中提供鏈接,連向其他API方法才沧,使得用戶不查文檔迈喉,也知道下一步應(yīng)該做什么。

比如温圆,當(dāng)用戶向api.example.com的根目錄發(fā)出請求挨摸,會得到這樣一個文檔。


{"link": {
  "rel":   "collection https://www.example.com/zoos",
  "href":  "https://api.example.com/zoos",
  "title": "List of zoos",
  "type":  "application/vnd.yourformat+json"
}}

上面代碼表示岁歉,文檔中有一個link屬性得运,用戶讀取這個屬性就知道下一步該調(diào)用什么API了。rel表示這個API與當(dāng)前網(wǎng)址的關(guān)系(collection關(guān)系锅移,并給出該collection的網(wǎng)址)熔掺,href表示API的路徑,title表示API的標(biāo)題非剃,type表示返回類型置逻。

Hypermedia API的設(shè)計(jì)被稱為HATEOAS。Github的API就是這種設(shè)計(jì)备绽,訪問api.github.com會得到一個所有可用API的網(wǎng)址列表券坞。


{
  "current_user_url": "https://api.github.com/user",
  "authorizations_url": "https://api.github.com/authorizations",
  // ...
}

從上面可以看到,如果想獲取當(dāng)前用戶的信息肺素,應(yīng)該去訪問api.github.com/user恨锚,然后就得到了下面結(jié)果。


{
  "message": "Requires authentication",
  "documentation_url": "https://developer.github.com/v3"
}

上面代碼表示压怠,服務(wù)器給出了提示信息眠冈,以及文檔的網(wǎng)址飞苇。

十一菌瘫、其他

(1)API的身份認(rèn)證應(yīng)該使用OAuth 2.0框架。

(2)服務(wù)器返回的數(shù)據(jù)格式布卡,應(yīng)該盡量使用JSON雨让,避免使用XML。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末忿等,一起剝皮案震驚了整個濱河市栖忠,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖庵寞,帶你破解...
    沈念sama閱讀 219,427評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件狸相,死亡現(xiàn)場離奇詭異,居然都是意外死亡捐川,警方通過查閱死者的電腦和手機(jī)脓鹃,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,551評論 3 395
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來古沥,“玉大人瘸右,你說我怎么就攤上這事⊙页荩” “怎么了太颤?”我有些...
    開封第一講書人閱讀 165,747評論 0 356
  • 文/不壞的土叔 我叫張陵,是天一觀的道長盹沈。 經(jīng)常有香客問我龄章,道長,這世上最難降的妖魔是什么乞封? 我笑而不...
    開封第一講書人閱讀 58,939評論 1 295
  • 正文 為了忘掉前任瓦堵,我火速辦了婚禮,結(jié)果婚禮上歌亲,老公的妹妹穿的比我還像新娘菇用。我一直安慰自己,他們只是感情好陷揪,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,955評論 6 392
  • 文/花漫 我一把揭開白布惋鸥。 她就那樣靜靜地躺著,像睡著了一般悍缠。 火紅的嫁衣襯著肌膚如雪卦绣。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,737評論 1 305
  • 那天飞蚓,我揣著相機(jī)與錄音滤港,去河邊找鬼。 笑死趴拧,一個胖子當(dāng)著我的面吹牛溅漾,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播著榴,決...
    沈念sama閱讀 40,448評論 3 420
  • 文/蒼蘭香墨 我猛地睜開眼添履,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了脑又?” 一聲冷哼從身側(cè)響起暮胧,我...
    開封第一講書人閱讀 39,352評論 0 276
  • 序言:老撾萬榮一對情侶失蹤锐借,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后往衷,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體钞翔,經(jīng)...
    沈念sama閱讀 45,834評論 1 317
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,992評論 3 338
  • 正文 我和宋清朗相戀三年席舍,在試婚紗的時候發(fā)現(xiàn)自己被綠了嗅战。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 40,133評論 1 351
  • 序言:一個原本活蹦亂跳的男人離奇死亡俺亮,死狀恐怖驮捍,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情脚曾,我是刑警寧澤东且,帶...
    沈念sama閱讀 35,815評論 5 346
  • 正文 年R本政府宣布,位于F島的核電站本讥,受9級特大地震影響珊泳,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜拷沸,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,477評論 3 331
  • 文/蒙蒙 一色查、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧撞芍,春花似錦秧了、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,022評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至帝嗡,卻和暖如春晶通,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背哟玷。 一陣腳步聲響...
    開封第一講書人閱讀 33,147評論 1 272
  • 我被黑心中介騙來泰國打工狮辽, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人巢寡。 一個月前我還...
    沈念sama閱讀 48,398評論 3 373
  • 正文 我出身青樓喉脖,卻偏偏與公主長得像,于是被迫代替她去往敵國和親讼渊。 傳聞我的和親對象是個殘疾皇子动看,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,077評論 2 355

推薦閱讀更多精彩內(nèi)容

  • 目錄 定義(Definitions) 數(shù)據(jù)的設(shè)計(jì)與抽象化(Data Design and Abstraction)...
    55lover閱讀 2,088評論 0 4
  • 一篇好的關(guān)于RESTFUL API的文章(對英文進(jìn)行了簡單的翻譯,方便英文閱讀困難的朋友)爪幻,共讀菱皆,閱讀時間約10分...
    CC先生之簡書閱讀 2,566評論 0 7
  • 文章導(dǎo)讀: 網(wǎng)絡(luò)應(yīng)用程序,分為前端和后端兩個部分挨稿。當(dāng)前的發(fā)展趨勢仇轻,就是前端設(shè)備層出不窮(手機(jī)、平板奶甘、桌面電腦篷店、其他...
    創(chuàng)造new_world閱讀 279評論 0 0
  • 網(wǎng)絡(luò)應(yīng)用程序,分為前端和后端兩個部分臭家。當(dāng)前的發(fā)展趨勢疲陕,就是前端設(shè)備層出不窮(手機(jī)、平板钉赁、桌面電腦蹄殃、其他專用設(shè)備……...
    涼薄少年yi冷閱讀 180評論 0 1
  • RESTful API 概述 參考地址 RESTful架構(gòu)是一種流行的互聯(lián)網(wǎng)軟件架構(gòu),它結(jié)構(gòu)清晰你踩,符合標(biāo)準(zhǔn)诅岩,易于理...
    BlockGeeks閱讀 21,861評論 4 22