api接口設計

健壯性

對外提供的接口，最好支持冪等性，即相同的請求重復調用，服務端的操作應該只有一次，并且每次返回的結果應該是一樣的。
一般的做法是要求客戶端在每次調用的時候帶上唯一鍵，服務端第一次正常處理，并緩存唯一鍵和結果，后面再有重復調用，即可直接獲取緩存結果返回。
如果客戶端沒有唯一鍵的條件，也可以要求傳時間戳，用時間戳作為唯一鍵。

對外的接口，粒度能細就細，最好不要是那種入參是type，然后服務端根據type類型返回不同的數據，這樣容易被調用方猜到一些服務端不想暴漏的內容。
舉個例子，比如你要對外提供字典接口。 你的service方法是入參type， type=country，就返回所有國家字典；
type=currency，就返回所有幣種字典。
其實你只想對外暴漏這兩個功能，但其實你的service還支持type=company，就返回所有公司，
這個你是不想對外暴漏的，但有可能會被調用方猜到，從而獲取了隱私數據。
所以這種情況，就應該把接口拆開，比如獲取國家就是一個接口，獲取幣種就是另外一個接口。

接口的入參，最好是包好的dto，這個不用多說，接口升級的時候，不會影響到用舊版本的客戶端，便于擴展。

接口的出參，盡可能的少，沒用的字段一定不要加，因為考慮到以后接口維護的時候，加字段好加，減字段可不好減。

接口的出參，服務不要把異常直接拋出來，一定要加全局異常捕獲，明確指定不同類型的出參碼，比如調用錯誤是什么，參數錯誤是什么等等。

單一職責，一個接口應該是專門給一個功能或者一類特定功能用的，避免接口復用，這個也是擴展性問題。

命名要統一，一定要有全局意識。比如所有的查詢都是find開頭，所有的查列表都是以list結尾，所有的分頁都是currentPage+pageSize等等

命名要準確，隨便用漢字拼音首字母命名都是一種不負責任的做法

安全性

上面有提到用時間戳作為請求唯一鍵，可以做冪等。其實用時間戳，還有個好處，就是可以判斷是不是截取url的惡意調用。
因為我們可以判斷當前時間和時間戳的間隔，如果大于某個值，比如大于5秒，我們就判定這個url無效。 這樣可以有效的抵擋一部分的DOS攻擊。

如果調用方很確定，并且數量不多的話，直接配置ip白名單，簡單高效。

再復雜的設計，比如簽名驗證，但個人覺得這個普通場景沒什么必要，增加復雜度，
但安全度極高的場景，是必加的，而且至少要token+時間戳的簽名，token是客戶端的身份證明。

總結

以上是生活随笔為你收集整理的api接口设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。