在進行api介面設計時,不同的開發人員可能有不同的設計風格,風格迥異。
那是否存在一種統一的介面設計方式,被廣大開發人員所接受呢?
答: 這就是被普遍採用的restful api設計風格。
路徑又稱"終點"(endpoint),表示api的具體**,每個**代表一種資源(resource)。
(1)url位址盡量使用名詞,不使用動詞。
舉例來說,以下是不好的例子:
/getproducts /listorders
對於乙個簡潔結構,應該始終用名詞。
get /products:將返回所有產品資訊
post /products:將新建產品資訊
get /products/4:將獲取產品4
put /products/4:將更新產品4
(2)api中的名詞應該使用複數,無論單個資源或者所有資源。
舉例來說,獲取產品的api可以這樣定義:
獲取單個產品:
獲取所有產品:
訪問同乙個url位址,採用不同的請求方式,代表要執行不同的操作。
常用的http請求方式有下面四個:
請求方式
說明get
獲取資源資料(單個或多個)
post
新增資源資料
put修改資源資料
delete
刪除資源資料
例如:
get /zoos:列出所有動物園
post /zoos:新建乙個動物園(上傳檔案)
get /zoos/id:獲取某個指定動物園的資訊
put /zoos/id:更新某個指定動物園的資訊
delete /zoos/id:刪除某個動物園
過濾引數可以放在查詢字串中。
在訪問api介面獲取資料時,可能需要對資料進行過濾。
下面是一些常見的引數:
?limit=10:指定返回記錄的數量
?offset=10:指定返回記錄的開始位置。
?page=2&per_page=100:指定第幾頁,以及每頁的記錄數。
?sortby=name&order=asc:指定返回結果按照哪個屬性排序,以及排序順序。
針對不同操作,伺服器向使用者返回的響應資料應該符合以下規範:
get /collection:返回資源物件的列表資料。
get /collection/resource:返回單個資源物件資料。
post /collection:返回新建立的資源物件資料。
put /collection/resource:返回完整的資源物件資料。
delete /collection/resource:返回空。
伺服器返回的響應資料格式,應該盡量使用json。
伺服器向客戶端返回的狀態碼和提示資訊,常見的狀態碼如下:
200 ok - [get/put]:伺服器成功返回使用者請求的資料
201 created - [post]:使用者新建資料成功。
204 no content - [delete]:使用者刪除資料成功。
400 invalid request - [post/put]:使用者發出的請求有錯誤,伺服器沒有進行新建或修改資料的操作
401 unauthorized - [*]:表示使用者沒有許可權(令牌、使用者名稱、密碼錯誤)。
403 forbidden - [*] 表示使用者得到授權(與401錯誤相對),但是訪問是被禁止的。
404 not found - [*]:使用者發出的請求針對的是不存在的記錄,伺服器沒有進行操作,該操作是冪等的。。
500 internal server error - [*]:伺服器發生錯誤,使用者將無法判斷發出的請求是否成功。
狀態碼的完全列表參見這裡或這裡。
應該盡量將api部署在專用網域名稱之下。
如果確定api很簡單,不會有進一步擴充套件,可以考慮放在主網域名稱下。
應該將api的版本號放入url。
另一種做法是,將版本號放在http頭資訊中,但不如放入url方便和直觀。github採用這種做法。
如果狀態碼是4xx,伺服器就應該向使用者返回出錯資訊。
比如,github的api就是這種設計,訪問api.github.com會得到乙個所有可用api的**列表。
從上面可以看到,如果想獲取當前使用者的資訊,應該去訪問api.github.com/user,然後就得到了下面結果。
上面**表示,伺服器給出了提示資訊,以及文件的**。
分析一下上節的案例,可以發現,在開發rest api介面時,檢視中做的最主要有三件事:
在以上操作中,涉及到兩個概念:序列化和反序列化。
將程式中的乙個資料結構型別轉換為其他格式(字典、json、xml等),例如將django中的模型類物件轉換為json字串,這個轉換過程我們稱為序列化。
如:
queryset = bookinfo.objects.all()
book_list =
# 序列化
for book in queryset:
'id': book.id,
'btitle': book.btitle,
'bpub_date': book.bpub_date,
'bread': book.bread,
'bcomment': book.bcomment,
'image': book.image.url if book.image else ''
})return jsonresponse(book_list, safe=false)
將其他格式(字典、json、xml等)轉換為程式中的資料,例如將json字串轉換為django中的模型類物件,這個過程我們稱為反序列化。
如:
json_bytes = request.body
json_str = json_bytes.decode()
# 反序列化
book_dict = json.loads(json_str)
book = bookinfo.objects.create(
btitle=book_dict.get('btitle'),
bpub_date=book_dict.get('bpub_date')
)
通過上節課的例子可以看到,在開發rest api時,檢視中要頻繁的進行序列化與反序列化的操作。
注:維基百科中對於序列化的定義。
在開發rest api介面時,我們在檢視中在做的最核心的事是:
設計風格 Restful
rest是設計風格而不是標準,只提供了一組設計原則和約束條件 資源由uri來指定 uri 統一資源識別符號 對資源的包括包括獲取 建立 修改 和刪除資源 這些操作正好對應http協議提供的get post put和delete方法 通過操作資源的表現形式來操作資源 非rest風格url http q...
RESTful 風格 API 設計規範
建議將api部署到專用網域名稱下,如 如果不需要考慮擴充套件可以將api當做乙個模組來開發 建議將版本放入url位址中,如 v1.1 get 獲取資源 post 新建資源 delete 刪除資源 put 更新資源api應該提供引數,比如分頁,在pc端和移動端可能是不一樣的 比如pc端一頁 30 條資...
restful風格概述
利用http協議的四種操作get put delete post實現對伺服器資源的增刪改查 get 用於查詢,post用於新增,put用於修改,delete用於刪除 restful風格程式設計。restful 更強調是資源 webservice,rml等訪問技術更強調過程。restful的重點體現在...