Restful API設計規範

2021-02-19 IT大咖說

RESTFUL是一種網絡應用程式的設計風格和開發方式,基於HTTP,可以使用XML格式定義或JSON格式定義。RESTFUL適用於移動網際網路廠商作為業務使能接口的場景,實現第三方OTT調用行動網路資源的功能,動作類型為新增、變更、刪除所調用資源。

RESTFUL特點包括:

1、每一個URI代表1種資源;

2、客戶端使用GET、POST、PUT、DELETE4個表示操作方式的動詞對服務端資源進行操作:GET用來獲取資源,POST用來新建資源(也可以用於更新資源),PUT用來更新資源,DELETE用來刪除資源;

3、通過操作資源的表現形式來操作資源;

4、資源的表現形式是XML或者HTML;

5、客戶端與服務端之間的交互在請求之間是無狀態的,從客戶端到服務端的每個請求都必須包含理解請求所必需的信息。

在當前流行的前後端分離架構,人們發現原來這套用於超文本傳輸的協議是如此適合用於設計基於網際網路的api接口,基於http動詞以及標準的http status返回信息,能夠非常好地描述api的特性,並且可讀性非常好。更重要的是,由於http是事實上的網際網路通訊標準協議,基於rest設計的api接口,就好像你出國用英語和別人交流,完全不存在溝通障礙。
REST架構,從個人角度理解,核心做了兩件事情

其實從REST的定義中就能看出來,表述層對應的就是描述資源的位置(資源定位),狀態轉移就是對資源的狀態進行變更操作(增刪改查)
下面舉個實際的例子:
假設我們資料庫裡有一張User表,我們根據表建好了領域對象模型User,按照restful規範設計的接口應該是這樣的:

[POST] /users

[PUT] /users/{id}

[DELETE] /users/{id}

[GET] /users

從這裡也能看出接口命名為對應表名的複數形式,並且[method] 是對應到如下

HTTP Method

rest的定義,第一條叫做資源定位,如果還不理解,那讓我們再想想URL的定義,叫做統一資源定位符,也就是說url是用來表示資源在網際網路上的位置的,所以說在url中不應該包含動詞,只能包含名詞。對資源的操作應該體現在http method上面,如果這樣理解還比較抽象的話,這裡不妨再打一個比方,比如在jane的網站有一張小汽車的圖片,地址是http://jane.com/img/car.jpg,現在jane想設計一個api接口,實現對這張圖片的刪除操作,這個api應該怎麼設計?根據rest的設計規範,很容易得出是

[DELETE] http://jane.com/img/car

嚴格地說,有些網址最後的".html"後綴名是不必要的,因為這個後綴名表示格式,屬於"表現層"範疇,而URI應該只代表"資源"的位置。它的具體表現形式,應該在HTTP請求的頭信息中用Accept和Content-Type欄位指定,這兩個欄位才是對"表現層"的描述。

除了HTTP METHOD,rest另外一套重要的規範就是HTTP STATUS,這套狀態碼規範定義了常規的api操作所可能產生的各種可能結果的描述,遵循這套規範,會使得你的api變得更加可讀,同時也便於各種網絡、基礎設施進行交易狀態監控。經常會用到的status code整理如下:

200 OK - [GET]:伺服器成功返回用戶請求的數據,該操作是冪等的(Idempotent)。
201 CREATED - [POST/PUT/PATCH]:用戶新建或修改數據成功。
202 Accepted - [*]:表示一個請求已經進入後臺排隊(異步任務)
204 NO CONTENT - [DELETE]:用戶刪除數據成功。
400 INVALID REQUEST - [POST/PUT/PATCH]:用戶發出的請求有錯誤,伺服器沒有進行新建或修改數據的操作,該操作是冪等的。
401 Unauthorized - [*]:表示用戶沒有權限(令牌、用戶名、密碼錯誤)。
403 Forbidden - [*] 表示用戶得到授權(與401錯誤相對),但是訪問是被禁止的。
404 NOT FOUND - [*]:用戶發出的請求針對的是不存在的記錄,伺服器沒有進行操作,該操作是冪等的。
406 Not Acceptable - [GET]:用戶請求的格式不可得(比如用戶請求JSON格式,但是只有XML格式)。
410 Gone -[GET]:用戶請求的資源被永久刪除,且不會再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 當創建一個對象時,發生一個驗證錯誤。
500 INTERNAL SERVER ERROR - [*]:伺服器發生錯誤,用戶將無法判斷發出的請求是否成功。

最後推薦大家github的api文檔:

完畢!!!

來源:

https://www.toutiao.com/i6895160206846755339/

「IT大咖說」歡迎廣大技術人員投稿,投稿郵箱:aliang@itdks.com


 IT大咖說  |  關於版權 

由「IT大咖說(ID:itdakashuo)」原創的文章,轉載時請註明作者、出處及微信公眾號。投稿、約稿、轉載請加微信:ITDKS10(備註:投稿),茉莉小姐姐會及時與您聯繫!

感謝您對IT大咖說的熱心支持!

相關焦點

  • 我是如何根據豆瓣api來理解Restful API設計的
    REST本身沒有創造新的技術、組件或服務,它的理念就是在現有的技術之上,更好的使用現有的 web規範。用REST規範的web伺服器,能夠更好的展現資源,客戶端能夠更好的使用資源。每個資源都由URI/ID標識。REST本身跟http無關,但是目前http是與它相關的唯一實例。REST有著優雅、簡潔的特性,本文是根據豆瓣api來談談自己對restful的一些理解。
  • RESTful API 設計規範
    設計。為了更好的討論規範帶來的爭議及問題,現已把該文檔整理並開源到 github (https://github.com/godruoyi/restful-api-specification),關於大家補充及提 issue。
  • 理解 RESTful API 設計規範
    它是基於HTTP、URI、XML、JSON等標準和協議,支持輕量級、跨平臺、跨語言的架構設計。一、理解為什麼要使用RESTful API設計規範?因此為了解決這個問題慢慢就出現了前後端分離的思想: 即後端負責數據接口, 前端負責數據渲染, 前端只需要請求下api接口拿到數據,然後再將數據顯示出來。因此後端開發人員需要設計api接口,因此為了統一規範: 社區就出現了 RESTful API 規範,其實該規範很早就有的,只是最近慢慢流行起來,RESTful API 可以通過一套統一的接口為所有web相關提供服務,實現前後端分離。
  • 如何理解RESTful API設計規範?
    它是基於HTTP、URI、XML、JSON等標準和協議,支持輕量級、跨平臺、跨語言的架構設計。為什麼使用RESTful API設計規範?因此為了解決這個問題慢慢就出現了前後端分離的思想: 即後端負責數據接口, 前端負責數據渲染, 前端只需要請求下api接口拿到數據,然後再將數據顯示出來。因此後端開發人員需要設計api接口,因此為了統一規範: 社區就出現了 RESTful API 規範。
  • RESTful API 設計指南
    這導致API構架的流行,甚至出現」API First」的設計思想。RESTful API是目前比較成熟的一套網際網路應用程式的API設計理論。我以前寫過一篇《理解RESTful架構》,探討如何理解這個概念。今天,我將介紹RESTful API的設計細節,探討如何設計一套合理、好用的API。我的主要參考了兩篇文章(1,2)。
  • API 接口規範
    舉例來說,有一個API提供動物園(zoo)的信息,還包括各種動物和僱員的信息,則它的路徑應該設計成下面這樣。producy_type=1:指定篩選條件API 傳入參數傳入參數分為4種類型:地址欄參數restful地址欄參數 /api/v1/product/122。
  • RESTful API 介紹及設計
    RESTful是一種設計風格。四:RESTful API實踐API設計RESTful API 是基於REST架構設計理念之下利用http協議來描述接口操作接口。這種API設計主要描述幾個部分:URL的設計,URL裡面當然包含了資源定位符。
  • 理解RESTful API 架構設計規範與實踐
    如果把網站,移動應用從伺服器到前端,從整體上看作是一個軟體,它就是一個層次清楚,功能強,擴展方便,適宜通信的架構規範。在通常的 API 設計中,直接使用 URL 來標示應用系統中的資源。https://www.sample.com/api/shops/10083 - 編號10083店鋪的基本信息https://www.sample.com/api/users/2372/orders - 編號2372用戶的所有訂單信息在標準的 REST 規範觀點中,通常會要求將資源 shop 加上複數形式 s 表示多個資源。
  • PHP:API 接口規範完整版本
    一般來說,資料庫中的表都是同種記錄的"集合"(collection),所以API中的名詞也應該使用複數。舉例來說,有一個API提供動物園(zoo)的信息,還包括各種動物和僱員的信息,則它的路徑應該設計成下面這樣。
  • Laravel 開發 RESTful API 的一些心得
    大方面,會涉及到給別人用的使用OAuth,自己使用的用token就足夠了設計最初,最好在路由加個版本號,方便以後擴展。laravel用的是中劃線(-),因為谷歌收錄時,按中劃線劃分關鍵字,國內的是按下劃線(_)收錄,具體看自己了,我是喜歡下劃線 >_<更多看這裡: 路由命名規範(https://laravel-china.org/courses/laravel-specification/502/router)表單驗證可以使用控制器自帶的表單驗證
  • php Restful設計思路與步驟
    是基於資源的,面向資源架構風格(一個連結,一張圖、一個文本等等)2、restful的http協議   2.1 url:        2.1.1 port 服務埠,默認為802.1.2 path 訪問資源的路徑        2.1.3 query-string  發送給http伺服器的數據
  • Java springMVC] Restful風格API接口設計
    Restful風格API接口開發springMVC篇 Restful風格的API是一種軟體架構風格,設計風格而不是標準,只是提供了一組設計原則和約束條件
  • RESTful API 編寫指南
    因此,在設計和編寫URL時,要符合一些規範。Url rules 可以單獨寫一篇博客來詳細闡述,本文只列出一些關鍵點。6.1 Version your API規範的API應該包含版本信息,在RESTful API中,最簡單的包含版本的方法是將版本信息放到url中,如: /api1/posts//api1/drafts//api2/posts//api2/drafts/ 另一種優雅的做法是,使用HTTP header
  • RESTful架構和RESTful API設計總結
    作者:智明書連結:https://www.jianshu.com/p/955eb2faa354REST這個詞是2000年Roy Fielding在他的博士論文中提出的,Fielding參與了http協議的設計
  • 教你 10 分鐘構建一套 RESTful API 服務( 中 )
    if __name__ == '__main__':    app.run()從 flask_restful 文件中導入 Api、Resource 兩個類,使用上面的 app 對象,構建一個 api 對象,接著準備一個列表數據from flask_restful import Api,Resourceapp
  • 深入理解 RESTful Api 架構
    RESTful Api 與 SOAP Web API 在 URL 形式上的對比從設計一個刪除評論的 api 說起 我們可以這樣設計成類似於:http://mengkang.net/?關於這些功能上有交集的地方,可能後面會有一些更加標準的規範或者協議吧。最後說下HEAD和OPTIONS,HEAD請求的是資源的元數據,比如一張照片,的元數據則可能包含了,照片拍攝的設備,地點,時間等。伺服器一般將對應資源的元數據置於響應的報頭集合返回給客戶端,這樣的響應一般不具有主體部分。
  • axios中restful api的使用
    1引子在前端發送網絡請求的時候,現在最經常使用的是axios, 而axios的api中我們(確切說是我)最常用的就是post,而其他api很少有用到的場景。最近在做一個簡單需求(增刪改查)的時候,後端給的接口是restful風格的。看看吧:嗯,看到上圖我還沒感覺到什麼,接著看:
  • RESTful API 設計學習筆記
    作者 : 韓子遲|原文:閱讀原文本文主要參考阮一峰的 RESTful API 設計指南
  • 良好的 API 設計指南-RESTful API
    比如:http://api.qc.com/v1/newsfeed: 獲取某人的新鮮;http://api.qc.com/v1/friends: 獲取某人關系列表;http://api.qc.com/v1/profile: 獲取某人的詳細信息;URL是對資源描述的抽象,資源的描述一定是名詞,如果引入了動詞,那這個URL就表示了一個動作,而非一個資源
  • 深入淺出RESTful API設計,小白也能看懂!
    關於RESTful API編寫指南、設計規範的文章很多,但大部分文章都沒有說清楚在RESTful API設計過程中,每種HTTP請求方法適用於何種場景,使用了這些請求方法後會對客戶端和服務端產生何種影響。而有的文章寫的太過專業化,讓初學者很難理解。