欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

LOGO OA教程 ERP教程 模切知識交流 PMS教程 CRM教程 開發(fā)文檔 其他文檔  
 
網(wǎng)站管理員

[點(diǎn)晴永久免費(fèi)OA]RESTful API設(shè)計(jì)規(guī)范

admin
2022年4月18日 18:7 本文熱度 1818

該倉庫整理了目前比較流行的 RESTful api 設(shè)計(jì)規(guī)范,為了方便討論規(guī)范帶來的問題及爭議,現(xiàn)把該文檔托管于 Github,歡迎大家補(bǔ)充!!

Table of Contents

關(guān)于「能愿動詞」的使用

為了避免歧義,文檔大量使用了「能愿動詞」,對應(yīng)的解釋如下:

  • 必須 (MUST):絕對,嚴(yán)格遵循,請照做,無條件遵守;
  • 一定不可 (MUST NOT):禁令,嚴(yán)令禁止;
  • 應(yīng)該 (SHOULD) :強(qiáng)烈建議這樣做,但是不強(qiáng)求;
  • 不該 (SHOULD NOT):強(qiáng)烈不建議這樣做,但是不強(qiáng)求;
  • 可以 (MAY) 和 可選 (OPTIONAL) :選擇性高一點(diǎn),在這個(gè)文檔內(nèi),此詞語使用較少;
參見:RFC 2119

Protocol

客戶端在通過 API 與后端服務(wù)通信的過程中,應(yīng)該 使用 HTTPS 協(xié)議。

API Root URL

API 的根入口點(diǎn)應(yīng)盡可能保持足夠簡單,這里有兩個(gè)常見的 URL 根例子:

  • api.example.com/*
  • example.com/api/*
如果你的應(yīng)用很龐大或者你預(yù)計(jì)它將會變的很龐大,那 應(yīng)該 將 API 放到子域下(api.example.com)。這種做法可以保持某些規(guī)模化上的靈活性。

Versioning

所有的 API 必須保持向后兼容,你 必須 在引入新版本 API 的同時(shí)確保舊版本 API 仍然可用。所以 應(yīng)該 為其提供版本支持。

目前比較常見的兩種版本號形式:

在 URL 中嵌入版本編號

api.example.com/v1/*

這種做法是版本號直觀、易于調(diào)試;另一種做法是,將版本號放在 HTTP Header 頭中:

通過媒體類型來指定版本信息

Accept: application/vnd.example.com.v1+json

其中 vnd 表示 Standards Tree 標(biāo)準(zhǔn)樹類型,有三個(gè)不同的樹: xprs 和 vnd。你使用的標(biāo)準(zhǔn)樹需要取決于你開發(fā)的項(xiàng)目

  • 未注冊的樹(x)主要表示本地和私有環(huán)境
  • 私有樹(prs)主要表示沒有商業(yè)發(fā)布的項(xiàng)目
  • 供應(yīng)商樹(vnd)主要表示公開發(fā)布的項(xiàng)目
后面幾個(gè)參數(shù)依次為應(yīng)用名稱(一般為應(yīng)用域名)、版本號、期望的返回格式。

至于具體把版本號放在什么地方,這個(gè)問題一直存在很大的爭議,但由于我們大多數(shù)時(shí)間都在使用 Laravel 開發(fā),應(yīng)該 使用 dingo/api 來快速構(gòu)建應(yīng)用,它采用第二種方式來管理 API 版本,并且已集成了標(biāo)準(zhǔn)的 HTTP Response

Endpoints

端點(diǎn)就是指向特定資源或資源集合的 URL。在端點(diǎn)的設(shè)計(jì)中,你 必須 遵守下列約定:

  • URL 的命名 必須 全部小寫
  • URL 中資源(resource)的命名 必須 是名詞,并且 必須 是復(fù)數(shù)形式
  • 必須 優(yōu)先使用 Restful 類型的 URL
  • URL 必須 是易讀的
  • URL 一定不可 暴露服務(wù)器架構(gòu)
至于 URL 是否必須使用連字符(-) 或下劃線(_),不做硬性規(guī)定,但 必須 根據(jù)團(tuán)隊(duì)情況統(tǒng)一一種風(fēng)格。

來看一個(gè)反例

再來看一個(gè)正列

HTTP 動詞

對于資源的具體操作類型,由 HTTP 動詞表示。常用的 HTTP 動詞有下面五個(gè)(括號里是對應(yīng)的 SQL 命令)。

  • GET(select):從服務(wù)器取出資源(一項(xiàng)或多項(xiàng))。
  • POST(create):在服務(wù)器新建一個(gè)資源。
  • PUT(update):在服務(wù)器更新資源(客戶端提供改變后的完整資源)。
  • PATCH(update):在服務(wù)器更新資源(客戶端提供改變的屬性)。
  • delete(delete):從服務(wù)器刪除資源。

其中

1 刪除資源 必須 用 delete 方法
2 創(chuàng)建新的資源 必須 使用 POST 方法
3 更新資源 應(yīng)該 使用 PUT 方法
4 獲取資源信息 必須 使用 GET 方法

針對每一個(gè)端點(diǎn)來說,下面列出所有可行的 HTTP 動詞和端點(diǎn)的組合

請求方法URL描述
GET/zoos列出所有的動物園(ID和名稱,不要太詳細(xì))
POST/zoos新增一個(gè)新的動物園
GET/zoos/{zoo}獲取指定動物園詳情
PUT/zoos/{zoo}更新指定動物園(整個(gè)對象)
PATCH/zoos/{zoo}更新動物園(部分對象)
delete/zoos/{zoo}刪除指定動物園
GET/zoos/{zoo}/animals檢索指定動物園下的動物列表(ID和名稱,不要太詳細(xì))
GET/animals列出所有動物(ID和名稱)。
POST/animals新增新的動物
GET/animals/{animal}獲取指定的動物詳情
PUT/animals/{animal}更新指定的動物(整個(gè)對象)
PATCH/animals/{animal}更新指定的動物(部分對象)
GET/animal_types獲取所有動物類型(ID和名稱,不要太詳細(xì))
GET/animal_types/{type}獲取指定的動物類型詳情
GET/employees檢索整個(gè)雇員列表
GET/employees/{employee}檢索指定特定的員工
GET/zoos/{zoo}/employees檢索在這個(gè)動物園工作的雇員的名單(身份證和姓名)
POST/employees新增指定新員工
POST/zoos/{zoo}/employees在特定的動物園雇傭一名員工
delete/zoos/{zoo}/employees/{employee}從某個(gè)動物園解雇一名員工
超出 Restful 端點(diǎn)的,應(yīng)該 模仿上表的方式來定義端點(diǎn)。

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é)果按照哪個(gè)屬性排序,以及排序順序。
  • ?animal_type_id=1:指定篩選條件

所有 URL 參數(shù) 必須 是全小寫,必須 使用下劃線類型的參數(shù)形式。

分頁參數(shù) 必須 固定為 pageper_page

經(jīng)常使用的、復(fù)雜的查詢 應(yīng)該 標(biāo)簽化,降低維護(hù)成本。如

GET /trades?status=closed&sort=sortby=name&order=asc
# 可為其定制快捷方式
GET /trades/recently_closed

Authentication

應(yīng)該 使用 OAuth2.0 的方式為 API 調(diào)用者提供登錄認(rèn)證。必須 先通過登錄接口獲取 Access Token 后再通過該 token 調(diào)用需要身份認(rèn)證的 API

Oauth 的端點(diǎn)設(shè)計(jì)示列

  • RFC 6749 /token
  • Twitter /oauth2/token
  • Fackbook /oauth/access_token
  • Google /o/oauth2/token
  • Github /login/oauth/access_token
  • Instagram /oauth/authorize

客戶端在獲得 access token 的同時(shí) 必須 在響應(yīng)中包含一個(gè)名為 expires_in 的數(shù)據(jù),它表示當(dāng)前獲得的 token 會在多少  后失效。

{
    "access_token": "token....",
    "token_type": "Bearer",
    "expires_in": 3600
}

客戶端在請求需要認(rèn)證的 API 時(shí),必須 在請求頭 Authorization 中帶上 access_token

Authorization: Bearer token...

當(dāng)超過指定的秒數(shù)后,access token 就會過期,再次用過期/或無效的 token 訪問時(shí),服務(wù)端 應(yīng)該 返回 invalid_token 的錯(cuò)誤或 401 錯(cuò)誤碼。

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "error": "invalid_token"
}
Laravel 開發(fā)中,應(yīng)該 使用 JWT 來為管理你的 Token,并且 一定不可 在 api 中間件中開啟請求 session

Response

所有的 API 響應(yīng),必須 遵守 HTTP 設(shè)計(jì)規(guī)范,必須 選擇合適的 HTTP 狀態(tài)碼。一定不可 所有接口都返回狀態(tài)碼為 200 的 HTTP 響應(yīng),如:

HTTP/1.1 200 ok
Content-Type: application/json
Server: example.com
{
    "code": 0,
    "msg": "success",
    "data": {
        "username": "username"
    }
}

HTTP/1.1 200 ok
Content-Type: application/json
Server: example.com
{
    "code": -1,
    "msg": "該活動不存在",
}

下表列舉了常見的 HTTP 狀態(tài)碼

狀態(tài)碼描述
1xx代表請求已被接受,需要繼續(xù)處理
2xx請求已成功,請求所希望的響應(yīng)頭或數(shù)據(jù)體將隨此響應(yīng)返回
3xx重定向
4xx客戶端原因引起的錯(cuò)誤
5xx服務(wù)端原因引起的錯(cuò)誤
只有來自客戶端的請求被正確的處理后才能返回 2xx 的響應(yīng),所以當(dāng) API 返回 2xx 類型的狀態(tài)碼時(shí),前端 必須 認(rèn)定該請求已處理成功。

必須強(qiáng)調(diào)的是,所有 API 一定不可 返回 1xx 類型的狀態(tài)碼。當(dāng) API 發(fā)生錯(cuò)誤時(shí),必須 返回出錯(cuò)時(shí)的詳細(xì)信息。目前常見返回錯(cuò)誤信息的方法有兩種:

1、將錯(cuò)誤詳細(xì)放入 HTTP 響應(yīng)首部;

X-MYNAME-ERROR-CODE: 4001
X-MYNAME-ERROR-MESSAGE: Bad authentication token
X-MYNAME-ERROR-INFO: http://docs.example.com/api/v1/authentication

2、直接放入響應(yīng)實(shí)體中;

HTTP/1.1 401 Unauthorized
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:02:59 GMT
Connection: keep-alive
{"error_code":40100,"message":"Unauthorized"}

考慮到易讀性和客戶端的易處理性,我們 必須 把錯(cuò)誤信息直接放到響應(yīng)實(shí)體中,并且錯(cuò)誤格式 應(yīng)該 滿足如下格式:

{
    "message": "您查找的資源不存在",
    "error_code": 404001
}

其中錯(cuò)誤碼(error_code必須 和 HTTP 狀態(tài)碼對應(yīng),也方便錯(cuò)誤碼歸類,如:

HTTP/1.1 429 Too Many Requests
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:15:52 GMT
Connection: keep-alive
{"error_code":429001,"message":"你操作太頻繁了"}
HTTP/1.1 403 Forbidden
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:19:27 GMT
Connection: keep-alive
{"error_code":403002,"message":"用戶已禁用"}

應(yīng)該 在返回的錯(cuò)誤信息中,同時(shí)包含面向開發(fā)者和面向用戶的提示信息,前者可方便開發(fā)人員調(diào)試,后者可直接展示給終端用戶查看如:

{
    "message": "直接展示給終端用戶的錯(cuò)誤信息",
    "error_code": "業(yè)務(wù)錯(cuò)誤碼",
    "error": "供開發(fā)者查看的錯(cuò)誤信息",
    "debug": [
        "錯(cuò)誤堆棧,必須開啟 debug 才存在"
    ]
}

下面詳細(xì)列舉了各種情況 API 的返回說明。

200 ok

200 狀態(tài)碼是最常見的 HTTP 狀態(tài)碼,在所有 成功 的 GET 請求中,必須 返回此狀態(tài)碼。HTTP 響應(yīng)實(shí)體部分 必須 直接就是數(shù)據(jù),不要做多余的包裝。

錯(cuò)誤示例:

HTTP/1.1 200 ok
Content-Type: application/json
Server: example.com
{
    "user": {
        "id":1,
        "nickname":"fwest",
        "username": "example"
    }
}

正確示例:

1、獲取單個(gè)資源詳情

{
    "id": 1,
    "username": "godruoyi",
    "age": 88,
}

2、獲取資源集合

[
    {
        "id": 1,
        "username": "godruoyi",
        "age": 88,
    },
    {
        "id": 2,
        "username": "foo",
        "age": 88,
    }
]

3、額外的媒體信息

{
    "data": [
        {
            "id": 1,
            "avatar": "https://lorempixel.com/640/480/?32556",
            "nickname": "fwest",
            "last_logined_time": "2018-05-29 04:56:43",
            "has_registed": true
        },
        {
            "id": 2,
            "avatar": "https://lorempixel.com/640/480/?86144",
            "nickname": "zschowalter",
            "last_logined_time": "2018-06-16 15:18:34",
            "has_registed": true
        }
    ],
    "meta": {
        "pagination": {
            "total": 101,
            "count": 2,
            "per_page": 2,
            "current_page": 1,
            "total_pages": 51,
            "links": {
                "next": "http://api.example.com?page=2"
            }
        }
    }
}
其中,分頁和其他額外的媒體信息,必須放到 meta 字段中。

201 created

當(dāng)服務(wù)器創(chuàng)建數(shù)據(jù)成功時(shí),應(yīng)該 返回此狀態(tài)碼。常見的應(yīng)用場景是使用 POST 提交用戶信息,如:

  • 添加了新用戶
  • 上傳了圖片
  • 創(chuàng)建了新活動

等,都可以返回 201 狀態(tài)碼。需要注意的是,你可以選擇在用戶創(chuàng)建成功后返回新用戶的數(shù)據(jù)

HTTP/1.1 201 created
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:13:40 GMT
Connection: keep-alive
{
    "id": 1,
    "avatar": "https:\/\/lorempixel.com\/640\/480\/?32556",
    "nickname": "fwest",
    "last_logined_time": "2018-05-29 04:56:43",
    "created_at": "2018-06-16 17:55:55",
    "updated_at": "2018-06-16 17:55:55"
}

也可以返回一個(gè)響應(yīng)實(shí)體為空的 HTTP Response 如:

HTTP/1.1 201 created
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:12:20 GMT
Connection: keep-alive
這里我們 應(yīng)該 采用第二種方式,因?yàn)榇蠖鄶?shù)情況下,客戶端只需要知道該請求操作成功與否,并不需要返回新資源的信息。

202 Accepted

該狀態(tài)碼表示服務(wù)器已經(jīng)接受到了來自客戶端的請求,但還未開始處理。常用短信發(fā)送、郵件通知、模板消息推送等這類很耗時(shí)需要隊(duì)列支持的場景中;

返回該狀態(tài)碼時(shí),響應(yīng)實(shí)體 必須 為空。
HTTP/1.1 202 Accepted
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:25:15 GMT
Connection: keep-alive

204 No Content

該狀態(tài)碼表示響應(yīng)實(shí)體不包含任何數(shù)據(jù),其中:

  • 在使用 delete 方法刪除資源 成功 時(shí),必須 返回該狀態(tài)碼
  • 使用 PUTPATCH 方法更新數(shù)據(jù) 成功 時(shí),也 應(yīng)該 返回此狀態(tài)碼
HTTP/1.1 204 No Content
Server: nginx/1.11.9
Date: Sun, 24 Jun 2018 09:29:12 GMT
Connection: keep-alive

3xx 重定向

所有 API 不該 返回 3xx 類型的狀態(tài)碼。因?yàn)?nbsp;3xx 類型的響應(yīng)格式一般為下列格式:

HTTP/1.1 302 Found
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 09:41:50 GMT
Location: https://example.com
Connection: keep-alive
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="0;url=https://example.com" />
        <title>Redirecting to https://example.com</title>
    </head>
    <body>
        Redirecting to <a href="https://example.com">https://example.com</a>.
    </body>
</html>

所有 API 一定不可 返回純 HTML 結(jié)構(gòu)的響應(yīng);若一定要使用重定向功能,可以 返回一個(gè)響應(yīng)實(shí)體為空的 3xx 響應(yīng),并在響應(yīng)頭中加上 Location 字段:

HTTP/1.1 302 Found
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:52:50 GMT
Location: https://godruoyi.com
Connection: keep-alive

400 Bad Request

由于明顯的客戶端錯(cuò)誤(例如,請求語法格式錯(cuò)誤、無效的請求、無效的簽名等),服務(wù)器 應(yīng)該 放棄該請求。

當(dāng)服務(wù)器無法從其他 4xx 類型的狀態(tài)碼中找出合適的來表示錯(cuò)誤類型時(shí),都 必須 返回該狀態(tài)碼。
HTTP/1.1 400 Bad Request
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 13:22:36 GMT
Connection: keep-alive
{"error_code":40000,"message":"無效的簽名"}

401 Unauthorized

該狀態(tài)碼表示當(dāng)前請求需要身份認(rèn)證,以下情況都 必須 返回該狀態(tài)碼。

  • 未認(rèn)證用戶訪問需要認(rèn)證的 API
  • access_token 無效/過期
客戶端在收到 401 響應(yīng)后,都 應(yīng)該 提示用戶進(jìn)行下一步的登錄操作。
HTTP/1.1 401 Unauthorized
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
WWW-Authenticate: JWTAuth
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 13:17:02 GMT
Connection: keep-alive
{"message":"Token Signature could not be verified.","error_code": "40100"}

403 Forbidden

該狀態(tài)碼可以簡單的理解為沒有權(quán)限訪問該請求,服務(wù)器收到請求但拒絕提供服務(wù)。

如當(dāng)普通用戶請求操作管理員用戶時(shí),必須 返回該狀態(tài)碼。

HTTP/1.1 403 Forbidden
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 13:05:34 GMT
Connection: keep-alive
{"error_code":40301,"message":"權(quán)限不足"}

404 Not Found

該狀態(tài)碼表示用戶請求的資源不存在,如

  • 獲取不存在的用戶信息 (get /users/9999999)
  • 訪問不存在的端點(diǎn)

都 必須 返回該狀態(tài)碼,若該資源已永久不存在,則 應(yīng)該 返回 410 響應(yīng)。

405 Method Not Allowed

當(dāng)客戶端使用的 HTTP 請求方法不被服務(wù)器允許時(shí),必須 返回該狀態(tài)碼。

如客戶端調(diào)用了 POST 方法來訪問只支持 GET 方法的 API

該響應(yīng) 必須 返回一個(gè) Allow 頭信息用以表示出當(dāng)前資源能夠接受的請求方法的列表。

HTTP/1.1 405 Method Not Allowed
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Allow: GET, HEAD
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 12:30:57 GMT
Connection: keep-alive
{"message":"405 Method Not Allowed","error_code": 40500}

406 Not Acceptable

API 在不支持客戶端指定的數(shù)據(jù)格式時(shí),應(yīng)該返回此狀態(tài)碼。如支持 JSON 和 XML 輸出的 API 被指定返回 YAML 格式的數(shù)據(jù)時(shí)。

Http 協(xié)議一般通過請求首部的 Accept 來指定數(shù)據(jù)格式

408 Request Timeout

客戶端請求超時(shí)時(shí) 必須 返回該狀態(tài)碼,需要注意的時(shí),該狀態(tài)碼表示 客戶端請求超時(shí),在涉及第三方 API 調(diào)用超時(shí)時(shí),一定不可 返回該狀態(tài)碼。

409 Confilct

該狀態(tài)碼表示因?yàn)檎埱蟠嬖跊_突無法處理。如通過手機(jī)號碼提供注冊功能的 API,當(dāng)用戶提交的手機(jī)號已存在時(shí),必須 返回此狀態(tài)碼。

HTTP/1.1 409 Conflict
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 12:19:04 GMT
Connection: keep-alive
{"error_code":40900,"message":"手機(jī)號已存在"}

410 Gone

和 404 類似,該狀態(tài)碼也表示請求的資源不存在,只是 410 狀態(tài)碼進(jìn)一步表示所請求的資源已不存在,并且未來也不會存在。在收到 410 狀態(tài)碼后,客戶端 應(yīng)該 停止再次請求該資源。

413 Request Entity Too Large

該狀態(tài)碼表示服務(wù)器拒絕處理當(dāng)前請求,因?yàn)樵撜埱筇峤坏膶?shí)體數(shù)據(jù)大小超過了服務(wù)器愿意或者能夠處理的范圍。

此種情況下,服務(wù)器可以關(guān)閉連接以免客戶端繼續(xù)發(fā)送此請求。

如果這個(gè)狀況是臨時(shí)的,服務(wù)器 應(yīng)該 返回一個(gè) Retry-After 的響應(yīng)頭,以告知客戶端可以在多少時(shí)間以后重新嘗試。

414 Request-URI Too Long

該狀態(tài)碼表示請求的 URI 長度超過了服務(wù)器能夠解釋的長度,因此服務(wù)器拒絕對該請求提供服務(wù)。

415 Unsupported Media Type

通常表示服務(wù)器不支持客戶端請求首部 Content-Type 指定的數(shù)據(jù)格式。如在只接受 JSON 格式的 API 中放入 XML 類型的數(shù)據(jù)并向服務(wù)器發(fā)送,都 應(yīng)該 返回該狀態(tài)碼。

該狀態(tài)碼也可用于如:只允許上傳圖片格式的文件,但是客戶端提交媒體文件非法或不是圖片類型,這時(shí) 應(yīng)該 返回該狀態(tài)碼:

HTTP/1.1 415 Unsupported Media Type
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 12:09:40 GMT
Connection: keep-alive
{"error_code":41500,"message":"不允許上傳的圖片格式"}

429 Too Many Requests

該狀態(tài)碼表示用戶請求次數(shù)超過允許范圍。如 API 設(shè)定為 60次/分鐘,當(dāng)用戶在一分鐘內(nèi)請求次數(shù)超過 60 次后,都 應(yīng)該 返回該狀態(tài)碼。并且也 應(yīng)該 在響應(yīng)首部中加上下列頭部:

X-RateLimit-Limit: 10 請求速率(由應(yīng)用設(shè)定,其單位一般為小時(shí)/分鐘等,這里是 10次/5分鐘)
X-RateLimit-Remaining: 0 當(dāng)前剩余的請求數(shù)量
X-RateLimit-Reset: 1529839462 重置時(shí)間
Retry-After: 120 下一次訪問應(yīng)該等待的時(shí)間(秒)

列子

HTTP/1.1 429 Too Many Requests
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1529839462
Retry-After: 290
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 11:19:32 GMT
Connection: keep-alive
{"message":"You have exceeded your rate limit.","error_code":42900}

必須 為所有的 API 設(shè)置 Rate Limit 支持。

500 Internal Server Error

該狀態(tài)碼 必須 在服務(wù)器出錯(cuò)時(shí)拋出,對于所有的 500 錯(cuò)誤,都 應(yīng)該 提供完整的錯(cuò)誤信息支持,也方便跟蹤調(diào)試。

503 Service Unavailable

該狀態(tài)碼表示服務(wù)器暫時(shí)處理不可用狀態(tài),當(dāng)服務(wù)器需要維護(hù)或第三方 API 請求超時(shí)/不可達(dá)時(shí),都 應(yīng)該 返回該狀態(tài)碼,其中若是主動關(guān)閉 API 服務(wù),應(yīng)該 在返回的響應(yīng)首部加上 Retry-After 頭部,表示多少秒后可以再次訪問。

HTTP/1.1 503 Service Unavailable
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:56:20 GMT
Retry-After: 60
Connection: keep-alive
{"error_code":50300,"message":"服務(wù)維護(hù)中"}

其他 HTTP 狀態(tài)碼請參考 HTTP 狀態(tài)碼- 維基百科

版權(quán)聲明

版權(quán)聲明:自由轉(zhuǎn)載-非商用-非衍生-保持署名(創(chuàng)意共享3.0許可證

建議參考

restful-api-design-references

Principles of good RESTful API Design(譯)

理解 RESTful 架構(gòu)

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

HTTP 狀態(tài)碼- 維基百科

LICENSE

MIT License

Copyright (c) 2018 godruoyi

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING from,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.


該文章在 2022/4/18 18:07:11 編輯過
關(guān)鍵字查詢
相關(guān)文章
正在查詢...
點(diǎn)晴ERP是一款針對中小制造業(yè)的專業(yè)生產(chǎn)管理軟件系統(tǒng),系統(tǒng)成熟度和易用性得到了國內(nèi)大量中小企業(yè)的青睞。
點(diǎn)晴PMS碼頭管理系統(tǒng)主要針對港口碼頭集裝箱與散貨日常運(yùn)作、調(diào)度、堆場、車隊(duì)、財(cái)務(wù)費(fèi)用、相關(guān)報(bào)表等業(yè)務(wù)管理,結(jié)合碼頭的業(yè)務(wù)特點(diǎn),圍繞調(diào)度、堆場作業(yè)而開發(fā)的。集技術(shù)的先進(jìn)性、管理的有效性于一體,是物流碼頭及其他港口類企業(yè)的高效ERP管理信息系統(tǒng)。
點(diǎn)晴WMS倉儲管理系統(tǒng)提供了貨物產(chǎn)品管理,銷售管理,采購管理,倉儲管理,倉庫管理,保質(zhì)期管理,貨位管理,庫位管理,生產(chǎn)管理,WMS管理系統(tǒng),標(biāo)簽打印,條形碼,二維碼管理,批號管理軟件。
點(diǎn)晴免費(fèi)OA是一款軟件和通用服務(wù)都免費(fèi),不限功能、不限時(shí)間、不限用戶的免費(fèi)OA協(xié)同辦公管理系統(tǒng)。
Copyright 2010-2025 ClickSun All Rights Reserved