我們都知道在一個團(tuán)隊(duì)中是由很多角色組成的，例如：業(yè)務(wù)、產(chǎn)品、設(shè)計(jì)、前端、后端、測試。每個角色各司其職，一起合作完成項(xiàng)目的交付。

而前端與后端的溝通則是需要通過一個統(tǒng)一的文件進(jìn)行溝通交流，即通過接口文檔事先約定好后端的接口返回內(nèi)容，然后大家就按照這個文檔約定完成前后端的開發(fā)。并且一般接口文檔都是通過后端人員編寫的，維護(hù)流程也比較繁瑣。

最近被群里小伙伴安利了一款接口管理工具?ApiPost，陌溪在使用后覺的非常不錯，在這里我也分享給大家。

ApiPost 包含了以下四種功能，同時具備接口調(diào)試，接口文檔，以及?Mock?工具，以及接口流程測試。

ApiPost = API 接口調(diào)試工具 + 接口文檔快速生成 + Mock 工具 + 接口流程測試

• API 接口調(diào)試工具：常見的有 Postman、Postwoman 等等

• 接口文檔快速生成：常見的接口文檔工具有?Swagger?和?smart-doc，但是對代碼侵入性比較強(qiáng)。

• Mock 工具：主要用于前端根據(jù)接口生成對應(yīng)的數(shù)據(jù)，如?RAP?等工具。

• 接口測試：常見的接口測試工具有?JMeter

同時?ApiPost?也是國人開發(fā)的一款接口管理工具，致力于打造更好用的、中文的、接口調(diào)試與文檔管理工具（簡直是英語渣渣的福音~）

ApiPost首頁

Api 接口調(diào)試

代碼格式化

接口調(diào)試是在開發(fā)階段中使用最多的一個功能，利用 ApiPost 進(jìn)行常規(guī)的接口調(diào)試功能

ApiPost 進(jìn)行常規(guī)的接口調(diào)試功能

讓我感覺最舒服的是，對于返回的參數(shù)是可以進(jìn)行 Json 格式化的，下面是?Postman?自帶的?Pretty?功能 。

Postman自帶的Pretty功能

下面是?ApiPost?的?Json?格式化功能，并且通過右側(cè)的三角形，可以對數(shù)組元素進(jìn)行展開或者合攏。在面對返回結(jié)果是一個數(shù)組，并且每個對象中字段很多的時候，這個功能就非常棒了。

ApiPost的Json格式化功能

沒有對比就沒有傷害，在看看?Postman?的輸出，每次只能把結(jié)果復(fù)制出來，然后打開?Json?在線格式化，才能夠看到返回的結(jié)果，簡直增加了額外的負(fù)擔(dān)。

Json 格式化：https://www.sojson.com/

在線Json格式化

全局參數(shù)

同時，還有一個讓我非常喜歡的點(diǎn)，就是?全局參數(shù)。

在上面的示例中，我們需要給接口填寫對應(yīng)的鑒權(quán)請求頭，才能夠請求后臺獲得數(shù)據(jù)。

全局參數(shù)

但在實(shí)際項(xiàng)目中，對于一批接口需要測試的時候，往往每個接口都需要填寫相同的鑒權(quán)請求頭，這樣過程會非常繁瑣。如果使用 ApiPost 的話，我們可以利用全局參數(shù)或者目錄參數(shù)實(shí)現(xiàn)。

全局參數(shù)

配置完成后，以后添加的接口，再次請求后臺時，就會攜帶全局定義的請求頭過去。同理，還支持全局的?Query?以及?Body，可以把一些不變的請求參數(shù)都配置好全局參數(shù)，這樣會讓我們編寫接口請求時，省下很多時間~

目錄參數(shù)

同時，我們還可以創(chuàng)建不同的目錄，用來區(qū)分項(xiàng)目接口所處的不同模塊。例如：以蘑菇博客為例，可以創(chuàng)建兩個目錄?mogu-admin?和?mogu-web，分別代表蘑菇博客的后端管理與門戶項(xiàng)目。

蘑菇博客地址：https://gitee.com/moxi159753/mogu_blog_v2

因?yàn)?，后臺管理和門戶是有兩套鑒權(quán)邏輯的，即上面提到的全局配置 token 就不能針對兩個場景生效了！

那如果我還想同時測試 門戶類相關(guān)接口，或者是后臺管理相關(guān)接口，那怎么辦呢？

這個時候就需要用到目錄參數(shù)了，它的作用和全局參數(shù)雷同，只是作用域不一樣，mogu-admin?目錄下的接口不會使用同級的 mogu-web 目錄的目錄參數(shù)作為發(fā)送參數(shù)。

目錄參數(shù)

通過對不同的目錄，配置不同的全局參數(shù)，即可完美的解決剛剛的場景。

同時，當(dāng)全局參數(shù)、目錄參數(shù)、接口中都使用了同一個參數(shù)時，最終會按照以下優(yōu)先級讀取參數(shù)值：

單個接口 > 目錄參數(shù) > 全局參數(shù)

如上面的示例，如果全局參數(shù)、目錄參數(shù)、接口中都定義了 header 參數(shù) token：

全局參數(shù)：token 值為：698d51a19d8a121ce581499d7b701668 // 最低優(yōu)先級 目錄參數(shù)：token 值為：b50e345cc9febd86dedecc551ebcc505 // 其次優(yōu)先級 單接口參數(shù)：token 值為：a1a9db893bb8a28ccb665d2af54d9417 // 最高優(yōu)先級

那么最終發(fā)送的?token?值為：a1a9db893bb8a28ccb665d2af54d9417

接口文檔快速生成

點(diǎn)擊分享文檔，即可獲取對應(yīng)的文檔鏈接

復(fù)制并打開文檔地址就可以看到了完整的接口文檔。

細(xì)心的小伙伴可能會發(fā)現(xiàn)，這個請求參數(shù)上沒有相關(guān)字段的介紹，我們回到剛剛的?ApiPost?頁面，點(diǎn)擊?提取字段和描述，然后填入對應(yīng)的字段名稱。

然后重新發(fā)布，即可看到每個字段的含義了

有更細(xì)心的小伙伴，可能又會發(fā)現(xiàn)，這里為啥缺了點(diǎn)返回值呢？那是因?yàn)?APIPOST 不會把發(fā)送后的實(shí)時響應(yīng)的數(shù)據(jù)作為響應(yīng)示例。這個時候，需要手動的將實(shí)時響應(yīng)結(jié)果導(dǎo)入或者復(fù)制到對應(yīng)的成功響應(yīng)示例和錯誤響應(yīng)示例。

然后重新生成文檔，這個時候，就會包含我們的成功示例啦。

同時還有對應(yīng)的返回值字段描述

通過這個方法，可以隨時隨地的測試以及更新文檔，簡直是后端小伙伴的福音~

但是，不知道小伙伴們有沒有發(fā)現(xiàn)一個問題，就是在生成接口文檔的時候，還是需要自己填寫參數(shù)描述。

填寫參數(shù)描述是我們最煩惱的一件事情，尤其對于很多接口來說，往往具有大量相同名稱、相同意義的參數(shù)，假如每次都需要手動錄入，將會是一件非常耗時、低效的事情。

這個時候，我們可以通過?ApiPost?參數(shù)描述庫解決這個問題，通過自定義參數(shù)描述庫，我們可以將本項(xiàng)目用到的大量參數(shù)進(jìn)行預(yù)注釋。

并且，我們在填寫完某個描述后，會自動同步到?參數(shù)描述庫，以后如果匹配到了相同的名稱，會自動生成對應(yīng)的描述，簡直是一勞永逸的方法。

Mock 工具

我們都知道，在后端接口還沒有開發(fā)完成的時候，接口是無法獲取數(shù)據(jù)的，那么前端小伙伴就需要通過?Mock?事先編寫好?API?的數(shù)據(jù)生成規(guī)則，由工具動態(tài)生成?API?的返回?cái)?shù)據(jù)。通過訪問 Mock 來獲得頁面所需要的數(shù)據(jù)，就可以輕松地完成對接工作。前后端人員只需要定義好接口文檔就可以開始并行工作，互不影響，只在最后的聯(lián)調(diào)階段往來密切。

ApiPost?可以讓你在沒有后端程序的情況下能真實(shí)地返回接口數(shù)據(jù)，我們可以用 ApiPost 實(shí)現(xiàn)項(xiàng)目初期純前端的效果演示，也可以用?ApiPost?實(shí)現(xiàn)開發(fā)中的數(shù)據(jù)模擬從而實(shí)現(xiàn)前后端分離。

同時，ApiPost?支持參數(shù)直接引用?mock.js?變量，點(diǎn)擊下方可以查看?內(nèi)置 Mock 字段變量?有哪些

目前常用的內(nèi)置變量有以下幾種：

• @guid()：隨機(jī)生成一個 GUID，例：DEfbBBBf-7A23-a4DB-9BB1-57BCFf5FB5fc

• @integer(1,100)：隨機(jī)生成一個?1 ~100?的整數(shù)

• @datetime("yyyy-MM-dd HH:mm:ss")：返回一個隨機(jī)的日期和時間字符串。例：1977-11-17 03:50:15

• @url("http")：生成隨機(jī)一個?http URL

• @email()：生成一個隨機(jī)?email?郵箱

• @province()：隨機(jī)生成一個中國省份（或直轄市、自治區(qū)、特別行政區(qū)）

• @city()：隨機(jī)生成一個中國城市

• @title()：隨機(jī)生成一個標(biāo)題

• @cname()：隨機(jī)生成一個中文名稱

• @cparagraph()：隨機(jī)生成一段中文文本

下面我們利用這些常見的?Mock?變量，來生成一個?Mock?服務(wù)吧。

首先點(diǎn)擊?Mock 服務(wù)，然后編輯?Mock 模板，右側(cè)即可看到我們實(shí)時生成的?Mock 數(shù)據(jù)?了

在點(diǎn)擊上方的?復(fù)制鏈接?，即可把這個接口的?mock?請求交給前端小伙伴了，然后各種進(jìn)行合作開發(fā)。

測試流程

流程測試是針對一個接口集合的測試，選擇相應(yīng)的環(huán)境，可以作為一系列請求一起運(yùn)行。當(dāng)您想要自動化 API 測試時，流程測試非常有用。點(diǎn)擊開始，接口集合會并發(fā)的像服務(wù)器發(fā)出請求，最后會按照定義好的測試校驗(yàn)?zāi)K給出測試結(jié)果。對于測試同學(xué)來說，這是一個非常不錯的功能。

在 ApiPost 中，創(chuàng)建一個流程測試需要如下步驟：

• 新建接口，并添加斷言

• 打開流程測試，新建一個流程

• 向流程添加測試接口

• 選擇環(huán)境，點(diǎn)擊開始測試

• 查看返回的測試接口

流程測試界面如下圖：

通過點(diǎn)擊接口名稱查看請求的請求和響應(yīng)參數(shù)信息

同時在?ApiPost?中，還提供了很多內(nèi)置函數(shù)，例如我們很輕松的就可以對某個變量進(jìn)行解密處理。

更多關(guān)于?ApiPost?的功能，還等待小伙伴去發(fā)現(xiàn)。好啦，本期就到這里啦。

< END >