后端接口的開發(fā)思路

1.確定接口需求

與前端開發(fā)人員溝通，了解他們需要哪些接口以及接口的參數(shù)、返回值等信

息。

2.考慮接口的可擴展性

確認好需求后，根據(jù)實際業(yè)務(wù)場景設(shè)計接口，充分考慮接口的可擴展性。

比如有個需求：是用戶添加或者修改員工信息，你要考慮用戶的密碼是不是

也在接口中直接修改，還是需要建立一個通用的修改接口標準，其他修改信息

直接復(fù)用這個接口。

使用版本控制：在接口中添加版本號可以使得接口具有更好的兼容性和可擴

展性，同時也方便對接口進行升級和維護。

使用抽象數(shù)據(jù)結(jié)構(gòu)：使用抽象數(shù)據(jù)結(jié)構(gòu)可以使接口更加通用和可擴展，可以

適應(yīng)不同類型的數(shù)據(jù)C

3.根據(jù)接口需求，設(shè)計接口的結(jié)構(gòu)，包括接口的URL、請求方式、參數(shù)等。

接口結(jié)構(gòu)的設(shè)計：一般分為兩種，一種是調(diào)用方約定結(jié)構(gòu)方式。

二是做為接口設(shè)計方設(shè)計標準的報文結(jié)構(gòu)格式，調(diào)用方必須采用該結(jié)構(gòu)方式

調(diào)用。

設(shè)計參數(shù)：根據(jù)接口功能和客戶端需求，設(shè)計合適的參數(shù)，包括必選參數(shù)、

可選參數(shù)、路徑參數(shù)、查詢參數(shù)等。

設(shè)計返回值：根據(jù)接口功能和前端需求，設(shè)計合適的返回值，包括狀態(tài)碼、

響應(yīng)頭、響應(yīng)體等。接口狀態(tài)和錯誤需要統(tǒng)一明確。

狀態(tài)碼：一般定好一些標準的狀態(tài)碼，比如code=0000-代表報文請求成功，

Code二9999-代表報文請求失敗等。

確定請求方式：根據(jù)接口功能和數(shù)據(jù)安全性要求，選擇合適的請求方式，例

如GET、POST、PUT、DELETE等。

4.接口參數(shù)驗證

你設(shè)計的接口，必須先校驗參數(shù)。比如人參是否允許為空，入?yún)㈤L度是否符

合你的預(yù)期長度，這些都是接口的必備項，出參也是，比如你定義的接口報文，

參數(shù)是不為空的，但是你的接口返回參數(shù)，沒有做校驗。

5.接口是否需要防重處理

如果客戶端重復(fù)請求，你的邏輯如何處理？是不是考慮接口去重處理。

如果是查詢類的請求，不需要防重。如果是更新修改類的話，尤其金融轉(zhuǎn)賬

類的，就要過濾重復(fù)請求了。

6.調(diào)用第三方接口要考慮異常和超時處理

如果你調(diào)用第三方接口，或者分布式遠程服務(wù)的的話，需要考慮：

異常處理

比如，你調(diào)別人的接口，如果異常了，怎么處理，是重試還是當做失敗還是

告警處理。

接口超時

沒法預(yù)估對方接口一般多久返回，一般設(shè)置個超時斷開時間，以保護你的接

口。之前見過一個生產(chǎn)問題，就走http調(diào)用不設(shè)置超時時間，最后響應(yīng)方進程

假死，請求一直占著線程不釋放，拖垮線程池。

重試次數(shù)

你的接口調(diào)失敗，需不需要重試？重試幾次？需要站在業(yè)務(wù)上角度思考這個

問題。

7.日志設(shè)計

日志是一個系統(tǒng)的關(guān)鍵，所以接口設(shè)計的時侯日志保存是必須要考慮的，要

考慮哪些日志是需要落入數(shù)據(jù)庫，哪些是info展示即可等等。

8.接口實現(xiàn)過程中，恰當使用緩存

哪些場景適合使用緩存？讀多寫少且數(shù)據(jù)時效要求越低的場景。

緩存用得好，可以承載更多的請求，提升查詢效率，減少數(shù)據(jù)庫的壓力。

9.查詢類的語句分頁

對于查詢的接口要考慮分頁的設(shè)計

10.保證接口安全性

如果你的API接口是對外提供的，需要保證接口的安全性。保證接口的安全

性有token機制和接口簽名。

1L接口文檔要詳細清晰

在接口設(shè)計完成后，需要編寫詳細的接口文檔，包括接口的URL、請求參數(shù)、

返回