api接口詳解大全?優(yōu)秀的設(shè)計(jì)是產(chǎn)品變得卓越的原因設(shè)計(jì)API意味著提供有效的接口，可以幫助API使用者更好地了解、使用和集成，同時(shí)幫助人們有效地維護(hù)它每個(gè)產(chǎn)品都需要使用手冊(cè)，API也不例外在API領(lǐng)域，可以將設(shè)計(jì)視為服務(wù)器和客戶端之間的協(xié)議進(jìn)行建模API協(xié)議可以幫助內(nèi)部和外部的利益相關(guān)者理解應(yīng)該做什么，以及如何更好地協(xié)同工作來構(gòu)建一個(gè)出色的API，今天小編就來聊一聊關(guān)于api接口詳解大全?接下來我們就一起去研究一下吧!

api接口詳解大全

優(yōu)秀的設(shè)計(jì)是產(chǎn)品變得卓越的原因。設(shè)計(jì)API意味著提供有效的接口，可以幫助API使用者更好地了解、使用和集成，同時(shí)幫助人們有效地維護(hù)它。每個(gè)產(chǎn)品都需要使用手冊(cè)，API也不例外。在API領(lǐng)域，可以將設(shè)計(jì)視為服務(wù)器和客戶端之間的協(xié)議進(jìn)行建模。API協(xié)議可以幫助內(nèi)部和外部的利益相關(guān)者理解應(yīng)該做什么，以及如何更好地協(xié)同工作來構(gòu)建一個(gè)出色的API。

一、API接口1.什么是API接口

應(yīng)用程序編程接口（Application Programming Interface，API接口），是應(yīng)用程序重要的組成部分，就是應(yīng)用程序?qū)ν馓峁┝艘粋€(gè)操作數(shù)據(jù)的入口，這個(gè)入口可以是一個(gè)函數(shù)或類方法，也可以是一個(gè)url地址或者一個(gè)網(wǎng)絡(luò)地址。當(dāng)客戶端調(diào)用這個(gè)入口，應(yīng)用程序則會(huì)執(zhí)行對(duì)應(yīng)代碼操作，給客戶端完成相對(duì)應(yīng)的功能。

2.API接口類型

目前市面上大部分公司開發(fā)人員使用的接口實(shí)現(xiàn)規(guī)范主要有：restful、RPC。

RPC（ Remote Procedure Call ）: 翻譯成中文:遠(yuǎn)程過程調(diào)用[遠(yuǎn)程服務(wù)調(diào)用]. 從字面上理解就是訪問/調(diào)用遠(yuǎn)程服務(wù)端提供的api接口。這種接口一般以服務(wù)或者過程式代碼提供。

• 服務(wù)端提供一個(gè)唯一的訪問入口地址：http://api.xxx.com/ 或 http://www.xx.com/api
• 客戶端請(qǐng)求服務(wù)端的時(shí)候，所有的操作都理解為動(dòng)作，一般web開發(fā)時(shí)，對(duì)應(yīng)的就是HTTP請(qǐng)求的post請(qǐng)求
• 通過請(qǐng)求體參數(shù)，指定要調(diào)用的接口名稱和接口所需的參數(shù)action=get_all_student&class=301&sex=1m=get_all_student&sex=1&age=22&command=100&sex=1&age=22

  接口多了,對(duì)應(yīng)函數(shù)名和參數(shù)就多了,前端在請(qǐng)求api接口時(shí)難找.容易出現(xiàn)重復(fù)的接口

  RESTful:?翻譯成中文: 資源狀態(tài)轉(zhuǎn)換.(表征性狀態(tài)轉(zhuǎn)移)

  把服務(wù)端提供的所有的數(shù)據(jù)/文件都看成資源， 那么通過api接口請(qǐng)求數(shù)據(jù)的操作，本質(zhì)上來說就是對(duì)資源的操作了.因此，Restful中要求，我們把當(dāng)前接口對(duì)外提供哪種資源進(jìn)行操作，就把資源的名稱寫在url地址。

  web開發(fā)中操作資源，最常見的最通用的無非就是增刪查改，所以restful要求在地址欄中聲明要操作的資源是什么。然后通過http請(qǐng)求動(dòng)詞來說明對(duì)該資源進(jìn)行哪一種操作。POST http://www.xxx.com/api/students/ 添加學(xué)生數(shù)據(jù)GET http://www.xxx.com/api/students/ 獲取所有學(xué)生DELETE http://www.xxx.com/api/students/<pk>/ 刪除id=pk的一個(gè)學(xué)生PUT http://www.xxx.com/api/students/<pk>/ 修改一個(gè)學(xué)生的全部信息 [id,name,sex,age,]PATCH http://www.xxx.com/api/students/<pk>/ 修改一個(gè)學(xué)生的部分信息[age]

  也就是說，我們僅需要通過url地址上的資源名稱結(jié)合HTTP請(qǐng)求動(dòng)作，就可以說明當(dāng)前api接口的功能是什么了。

  Restful是以資源為主的api接口規(guī)范，體現(xiàn)在地址上就是資源就是以名詞表達(dá)。RPC則以動(dòng)作為主的api接口規(guī)范，體現(xiàn)在接口名稱上往往附帶操作數(shù)據(jù)的動(dòng)作。

  3.為什么要編寫接口文檔

  為了在團(tuán)隊(duì)內(nèi)部形成共識(shí)、防止個(gè)人習(xí)慣差異引起的混亂，我們都需要找到一種大家都覺得很好的接口實(shí)現(xiàn)規(guī)范，而且這種規(guī)范能夠讓后端寫的接口，用途一目了然，減少客戶端和服務(wù)端雙方之間的合作成本。由于接口所包含的內(nèi)容比較細(xì)，在項(xiàng)目中常常需要使用接口文檔。研發(fā)人員可以根據(jù)接口文檔進(jìn)行開發(fā)、協(xié)作，測(cè)試人員可以根據(jù)接口文檔進(jìn)行測(cè)試，系統(tǒng)也需要參照接口文檔進(jìn)行維護(hù)等。

  二、API接口規(guī)范1.協(xié)議

  API與客戶端用戶的通信協(xié)議，推薦使用http協(xié)議，同時(shí)兼容HTTP，以確保交互數(shù)據(jù)的傳輸安全。

  2.域名

  應(yīng)該盡量將API部署在專用域名之下。http://api.xxx.com

  如果確定API很簡(jiǎn)單，不會(huì)有進(jìn)一步擴(kuò)展，可以考慮放在主域名下。http://www.xxx.com/api/

  3.版本（Versioning）

  推薦將API的版本號(hào)放入U(xiǎn)RL。

  http://api.xxx.com/app/v1.0/foohttp://api.xxx.com/app/v1.1/foohttp://api.xxx.com/app/v2.0/foo

  另一種做法是，將版本號(hào)放在HTTP頭信息中，但不如放入U(xiǎn)RL方便和直觀。

  版本號(hào)規(guī)范：1）采用多版本并存，增量發(fā)布的方式。2）版本號(hào)可以分為整型和浮點(diǎn)型整型：大功能版本，如v1、v2、v3 ...浮點(diǎn)型：補(bǔ)充功能版本，如v1.1、v1.2、v2.1、v2.2 ...

  關(guān)于版本兼容性，小版本變化向下兼容的，只要大版本不變化。3）對(duì)于一個(gè)API或服務(wù)，應(yīng)在生產(chǎn)中最多保留3個(gè)最詳細(xì)的版本

  4.路徑（Endpoint）

  路徑又稱"終點(diǎn)"（endpoint），表示API的具體網(wǎng)址，每個(gè)網(wǎng)址代表一種資源（resource）

  接口命名應(yīng)該是一個(gè)動(dòng)賓結(jié)構(gòu)，由動(dòng)詞 名詞組成，采取駝峰式命名規(guī)范，例如：

  product/v1.0/getProducts 獲取產(chǎn)品order/v1.1/saveOrder 保存訂單

  接口命名常見通用動(dòng)詞可以參考如下：

  動(dòng)作	前綴	備注
  獲取	get	get{XXX}
  獲取	get	get{XXX}List
  新增	add	add{XXX}
  修改	update	update{XXX}
  保存	save	save{XXX}
  刪除	delete	delete{XXX}
  上傳	upload	upload{XXX}
  發(fā)送	send	send{XXX}

  5.基本規(guī)范5.1 請(qǐng)求參數(shù)

  公共參數(shù)是每個(gè)接口都要攜帶的參數(shù)，描述每個(gè)接口的基本信息，用于統(tǒng)計(jì)或其他用途，放在Header或url參數(shù)中。

  Queryurl?后面的參數(shù)，存放請(qǐng)求接口的參數(shù)數(shù)據(jù)。

  Header請(qǐng)求頭，存放以下公共參數(shù)、APP端公共參數(shù)等，也可以存放一些特殊加密字段。

  BodyBody體，存放請(qǐng)求接口的參數(shù)數(shù)據(jù)。

  公共參數(shù)：

  參數(shù)	說明	備注
  app_id	唯一標(biāo)識(shí)用戶ID	app_id是全局唯一的，每個(gè)app_id將對(duì)應(yīng)一個(gè)客戶
  app_key	加密key	app_key用于參數(shù)簽名使用，可以理解為加密鹽值，注意app_key保存到客戶端,不需要作為參數(shù)傳遞，需要做一些安全處理，防止泄露。
  timestamp	時(shí)間戳	時(shí)間戳，是客戶端調(diào)用接口時(shí)對(duì)應(yīng)的當(dāng)前時(shí)間戳，時(shí)間戳用于防止DoS攻擊。當(dāng)黑客劫持了請(qǐng)求的url去DoS攻擊，每次調(diào)用接口時(shí)接口都會(huì)判斷服務(wù)器當(dāng)前系統(tǒng)時(shí)間和接口中傳的的timestamp的差值，如果這個(gè)差值超過某個(gè)設(shè)置的時(shí)間(假如5分鐘)，那么這個(gè)請(qǐng)求將被攔截掉，如果在設(shè)置的超時(shí)時(shí)間范圍內(nèi)，是不能阻止DoS攻擊的。timestamp機(jī)制只能減輕DoS攻擊的時(shí)間，縮短攻擊時(shí)間。如果黑客修改了時(shí)間戳的值可通過sign簽名機(jī)制來處理。
  request_id	請(qǐng)求ID	用戶請(qǐng)求ID，是客戶端隨機(jī)生成的值,要保證全局唯一，可以參考snowflake算法，作為參數(shù)傳遞過來，增加request_id的目的是一方面增加sign簽名的多變性，另一方面主要用于防重放攻擊，還可以作為全鏈路跟蹤排查問題手段。
  sign	簽名	一般用于參數(shù)簽名，防止參數(shù)被非法篡改，最常見的是修改金額等重要敏感參數(shù)， sign的值一般是將所有非空參數(shù)按照升續(xù)排序然后 token app_key timestamp request_id拼接在一起，然后使用某種加密算法進(jìn)行加密，作為接口中的一個(gè)參數(shù)sign來傳遞，也可以將sign放到請(qǐng)求頭中。接口在網(wǎng)絡(luò)傳輸過程中如果被黑客挾持，并修改其中的參數(shù)值，然后再繼續(xù)調(diào)用接口，雖然參數(shù)的值被修改了，但是因?yàn)楹诳筒恢纒ign是如何計(jì)算出來的，不知道sign都有哪些值構(gòu)成，不知道以怎樣的順序拼接在一起的，最重要的是不知道簽名字符串中的app_key是什么，所以黑客可以篡改參數(shù)的值，但沒法修改sign的值，當(dāng)服務(wù)器調(diào)用接口前會(huì)按照sign的規(guī)則重新計(jì)算出sign的值然后和接口傳遞的sign參數(shù)的值做比較，如果相等表示參數(shù)值沒有被篡改，如果不等，表示參數(shù)被非法篡改了，就不執(zhí)行接口了。
  token	系統(tǒng)調(diào)用的唯一憑證	訪問令牌access token, 用于接口中, 用于標(biāo)識(shí)接口調(diào)用者的身份、憑證，減少用戶名和密碼的傳輸次數(shù)。一般情況下客戶端(接口調(diào)用方)需要先向服務(wù)器端申請(qǐng)一個(gè)接口調(diào)用的賬號(hào)，服務(wù)器會(huì)給出一個(gè)app_id和一個(gè)app_key, app_key用于參數(shù)簽名使用，注意app_key保存到客戶端，需要做一些安全處理，防止泄露。 Token的值一般是UUID，服務(wù)端生成Token后需要將token做為key，將一些和token關(guān)聯(lián)的信息作為value保存到緩存服務(wù)器中(redis)，當(dāng)一個(gè)請(qǐng)求過來后，服務(wù)器就去緩存服務(wù)器中查詢這個(gè)Token是否存在，存在則調(diào)用接口，不存在返回接口錯(cuò)誤，一般通過攔截器或者過濾器來實(shí)現(xiàn)。

  一般token、timestamp、request_id和sign 四個(gè)參數(shù)會(huì)在接口中會(huì)同時(shí)作為參數(shù)傳遞，每個(gè)參數(shù)都有各自的用途，其中首次獲取token需要app_id、timestamp、request_id、sign，客戶端獲取token后不再需要傳遞app_id。APP 端請(qǐng)求公共參數(shù)

  APP端請(qǐng)求參數(shù)除了上述公共參數(shù)外，還需要以下額外公共參數(shù)：

  參數(shù)	說明	備注
  network	網(wǎng)絡(luò)	WIFI、4G
  operator	運(yùn)營(yíng)商	中國(guó)聯(lián)通/移動(dòng)
  platform	平臺(tái)	iOS、Android
  system	系統(tǒng)	ios 13.3、android 9
  device	設(shè)備型號(hào)	iPhone XR、小米9
  udid	設(shè)備唯一標(biāo)示

  過濾參數(shù)：

  若記錄數(shù)量很多，服務(wù)器不可能返回全部記錄給用戶。API應(yīng)該提供分頁參數(shù)及其它篩選參數(shù)，過濾返回結(jié)果。

  參數(shù)示例如下limit=10：指定返回記錄的數(shù)量offset=10：指定返回記錄的開始位置。page=2&per_page=100：指定第幾頁，以及每頁的記錄數(shù)。sort_by=name&order=asc：指定返回結(jié)果按照哪個(gè)屬性排序，以及排序順序。

  注意：

  1）上傳/下載上傳/下載，參數(shù)增加文件md5，用于完整性校驗(yàn)（傳輸過程可能丟失數(shù)據(jù)）。2）避免精度丟失縮小單位保存數(shù)據(jù)，如：錢以分為單位、距離以米為單位。

  5.2 響應(yīng)數(shù)據(jù)

  為了方便給客戶端響應(yīng)，響應(yīng)數(shù)據(jù)會(huì)包含三個(gè)屬性，狀態(tài)碼（code）,信息描述（message）,響應(yīng)數(shù)據(jù)（data）?？蛻舳烁鶕?jù)狀態(tài)碼及信息描述可快速知道接口，如果狀態(tài)碼返回成功，再開始處理數(shù)據(jù)。array類型數(shù)據(jù)。通過list字段，保證data的Object結(jié)構(gòu)。

  返回示例：

  { code: “SUCCESS”, // 返回碼, 詳情后面的【接口返回碼】部分會(huì)說 data: {} , // 數(shù)據(jù) message: “成功” // 存放響應(yīng)信息提示,顯示給客戶端用戶【須語義化中文提示】 }

  分頁類型數(shù)據(jù)。返回總條數(shù)，用于判斷是否可以加載更多。返回示例：

  { code: “SUCCESS”, data: { "list":[] "total":10 }, // 數(shù)據(jù), message: “成功” }

  響應(yīng)狀態(tài)碼code統(tǒng)一使用英文組合字符串，多層分級(jí)使用“.”分隔，例如：PARAMETER.ILLEGALL

  PARAMETER.ILLEGALL代表參數(shù)錯(cuò)誤，不推薦使用數(shù)字，數(shù)字錯(cuò)誤碼可讀性太差。

  注意：1）返回屬性名命名時(shí)，建議使用駝峰命名，首字母小寫。2）返回屬性值為空時(shí)，嚴(yán)格按類型返回默認(rèn)值。3）返回金額類型/時(shí)間日期類型的屬性值，如果僅用來顯示，建議后端返回可以顯示的字符串。4）返回業(yè)務(wù)邏輯的狀態(tài)碼和對(duì)應(yīng)的文案，建議后端兩者都返回，中間添加“|”分隔，例如“SUCCESS|成功”，SUCCESS表示接口狀態(tài)成功，顯示給客戶表示“成功”。5）調(diào)用方不需要的屬性，不要返回。

  5.3使用GET/POST作為接口請(qǐng)求方式

  一般調(diào)用接口最常用的兩種方式就是GET和POST。兩者的區(qū)別也很明顯，GET請(qǐng)求會(huì)將參數(shù)暴露在瀏覽器URL中，而且對(duì)長(zhǎng)度也有限制。為了更高的安全性，所有接口都采用POST方式請(qǐng)求。另外不推薦使用rest的PUT和DELETE，因?yàn)楹芏酁g覽器不支持，很多框架也不支持。

  我們這里用的的GET和POST同RESTFul中的GET、POST是不一樣的。通常使用GET、POST的選擇點(diǎn)在于，簡(jiǎn)單的用GET、復(fù)雜對(duì)象用POST，并沒有動(dòng)作的含義，例如我也可以使用get來執(zhí)行添加的動(dòng)作，如果參數(shù)很多，我也可以使用POST來執(zhí)行查詢操作；但在REST里，GET對(duì)應(yīng)的是查詢一個(gè)資源，而POST對(duì)應(yīng)的是新增一個(gè)資源，意義是決然不同的。理解這一點(diǎn)非常重要。

  5.4返回格式

  返回響應(yīng)數(shù)據(jù)采用JSON，不推薦使用XML，XML是W3C為了替換HTML研發(fā)出來的，但是現(xiàn)在很明顯失敗了。默認(rèn)情況下要支持gzip

  三、接口安全規(guī)范3.1安全設(shè)計(jì)規(guī)范

  獲取token一般會(huì)涉及到幾個(gè)參數(shù)app_id，app_key，timestamp，request_id，sign。我們通過以上幾個(gè)參數(shù)來獲取調(diào)用系統(tǒng)的憑證。

• app_id和app_key可以直接通過平臺(tái)線上申請(qǐng)，也可以線下直接頒發(fā)。app_id是全局唯一的，每個(gè)app_id將對(duì)應(yīng)一個(gè)客戶，app_key需要客戶端高度保密。
• timestamp是時(shí)間戳，使用系統(tǒng)當(dāng)前的unix時(shí)間戳。時(shí)間戳的目的就是為了減輕DDOS的攻擊。防止請(qǐng)求被攔截后一直嘗試請(qǐng)求接口。服務(wù)器端設(shè)置時(shí)間戳閥值，如果請(qǐng)求時(shí)間戳和服務(wù)器時(shí)間超過閥值，則響應(yīng)失敗。
• request_id是隨機(jī)值。隨機(jī)值主要是為了增加sign的多變性，也可以保護(hù)接口的冪等性，相鄰的兩次請(qǐng)求reqeust_id不允許重復(fù)，如果重復(fù)則認(rèn)為是重復(fù)提交，響應(yīng)失敗。
• sign是參數(shù)簽名，將所有非空參數(shù)按照升續(xù)排序、app_key、timestamp、reqeust_id拼接起來進(jìn)行md5加密（當(dāng)然使用其他方式進(jìn)行不可逆加密也沒問題）。

  token作為系統(tǒng)調(diào)用的唯一憑證，token可以設(shè)置一次有效，也可以設(shè)置時(shí)效性，這里推薦設(shè)置時(shí)效性。如果一次有效的話這個(gè)接口的請(qǐng)求頻率可能會(huì)很高。token推薦加到請(qǐng)求頭上，這樣可以跟業(yè)務(wù)參數(shù)完全區(qū)分開來。

  這里面主要涉及到sign簽名設(shè)計(jì)規(guī)范和token生成規(guī)范，需要遵守如上規(guī)范，能夠保證API接口的安全性和冪等性。

  3.2客戶端IP白名單

  ip白名單是指將接口的訪問權(quán)限對(duì)部分ip進(jìn)行開放。這樣就能避免其他ip進(jìn)行訪問，設(shè)置ip白名單比較麻煩的一點(diǎn)就是當(dāng)你的客戶端進(jìn)行遷移后，就需要重新聯(lián)系服務(wù)提供者添加新的ip白名單。設(shè)置ip白名單的方式很多，除了傳統(tǒng)的防火墻之外，spring cloud alibaba提供的組件sentinel也支持白名單設(shè)置。為了降低api的復(fù)雜度，推薦使用防火墻規(guī)則進(jìn)行白名單設(shè)置或者在API網(wǎng)關(guān)層面設(shè)置IP白名單，比如shenyu網(wǎng)關(guān)支持IP白名單設(shè)置。

  3.3單個(gè)接口針對(duì)ip限流

  限流是為了更好的維護(hù)系統(tǒng)穩(wěn)定性。使用redis進(jìn)行接口調(diào)用次數(shù)統(tǒng)計(jì)，ip 接口地址作為key，訪問次數(shù)作為value，每次請(qǐng)求value 1，設(shè)置過期時(shí)長(zhǎng)來限制接口的調(diào)用頻率。不過這里還是推薦在網(wǎng)關(guān)層面進(jìn)行設(shè)置，比如shenyu網(wǎng)關(guān)支持IP限流。

  3.4敏感數(shù)據(jù)加密與脫敏

  參數(shù)安全：登錄密碼、支付密碼，需加密后傳輸，建議使用非對(duì)稱加密

  響應(yīng)結(jié)果：用戶手機(jī)號(hào)、用戶郵箱、身份證號(hào)、支付賬號(hào)、郵寄地址等要進(jìn)行脫敏，部分?jǐn)?shù)據(jù)加 * 號(hào)處理。

  在接口調(diào)用過程中數(shù)據(jù)通常需要脫敏安全處理，最常用的方式就是加密。加密方式使用安全性比較高的RSA非對(duì)稱加密。非對(duì)稱加密算法有兩個(gè)密鑰，這兩個(gè)密鑰完全不同但又完全匹配。只有使用匹配的一對(duì)公鑰和私鑰，才能完成對(duì)明文的加密和解密過程。

  四、API接口冪等性

  冪等性是指任意多次請(qǐng)求的執(zhí)行結(jié)果和一次請(qǐng)求的執(zhí)行結(jié)果所產(chǎn)生的影響相同。說的直白一點(diǎn)就是查詢操作無論查詢多少次都不會(huì)影響數(shù)據(jù)本身，因此查詢操作本身就是冪等的。但是新增操作，每執(zhí)行一次數(shù)據(jù)庫就會(huì)發(fā)生變化，所以它是非冪等的。

  我們無法保證接口的每一次調(diào)用都是有返回結(jié)果的，要考慮到出現(xiàn)網(wǎng)絡(luò)異常的情況。舉個(gè)例子，訂單創(chuàng)建時(shí)，我們需要去減庫存，這時(shí)接口發(fā)生了超時(shí)，調(diào)用方進(jìn)行了重試，這時(shí)是否會(huì)多扣一次庫存？

  對(duì)于一些重要的操作需要防止客戶端重復(fù)提交的(如非冪等性重要操作)，具體辦法是當(dāng)請(qǐng)求第一次提交時(shí)將request_id作為key保存到redis，相應(yīng)的返回結(jié)果集作為value存儲(chǔ)到redis，并設(shè)置超時(shí)時(shí)間。當(dāng)同一個(gè)請(qǐng)求第二次訪問時(shí)會(huì)先檢測(cè)redis是否存在該request_id，如果存在則證明重復(fù)提交了，接口直接返回不再繼續(xù)調(diào)用了。

  五、API調(diào)用流程

  1.接口調(diào)用方(客戶端)向接口提供方(服務(wù)器)申請(qǐng)接口調(diào)用賬號(hào)，申請(qǐng)成功后，接口提供方會(huì)給接口調(diào)用方一個(gè)app_id和app_key

  2.客戶端攜帶參數(shù)app_id、timestamp、request_id、sign去調(diào)用服務(wù)器端的API token，其中sign=加密(app_id timestamp request_id app_key)

  3.使用參數(shù)app_id，timestamp，request_id，sign來獲取token，token作為系統(tǒng)調(diào)用的唯一憑證

  4.客戶端拿著token 去訪問相應(yīng)的接口

  5.如果token過期需要獲取刷新token

  sign的作用是防止參數(shù)被篡改，客戶端調(diào)用服務(wù)端時(shí)需要傳遞sign參數(shù)，服務(wù)器響應(yīng)客戶端時(shí)也可以返回一個(gè)sign用于客戶端校驗(yàn)返回的值是否被非法篡改了。

  六、接口文檔

  1、盡量采用自動(dòng)化接口文檔，可以做到在線測(cè)試，同步更新,推薦使用swagger、yapi。2、應(yīng)包含：接口BASE地址、接口版本、接口模塊分類等。3、每個(gè)接口應(yīng)包含：接口地址：不包含接口BASE地址。請(qǐng)求方式: GET、POST。請(qǐng)求參數(shù)：數(shù)據(jù)格式【默認(rèn)JSON、可選form data】、數(shù)據(jù)類型、是否必填、中文描述。響應(yīng)參數(shù)：類型、中文描述。

  七、總結(jié)

  關(guān)于限流設(shè)計(jì)、熔斷設(shè)計(jì)、降級(jí)設(shè)計(jì)，目前主流網(wǎng)關(guān)都有相關(guān)功能（比如shenyu網(wǎng)關(guān)），可以不在API實(shí)現(xiàn)中開發(fā)這些功能。

  另外推薦把API相關(guān)日志存儲(chǔ)到日志平臺(tái)，日志平臺(tái)有利于故障定位和日志統(tǒng)計(jì)分析以及接口監(jiān)控。日志平臺(tái)的搭建可以使用的是ELK組件，使用Logstash進(jìn)行收集日志文件，使用Elasticsearch引擎進(jìn)行搜索分析，最終在Kibana平臺(tái)展示出來。文章來源地址http://www.zghlxwxcb.cn/news/detail-446584.html

到了這里，關(guān)于api接口詳解大全（看這篇就足以了）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！