關於接口設計的思考--我們真的需要這麼多入參嗎

爲什麼說起接口設計

最近，我改造一箇舊接口時發現，這個接口有 30 多個入參，而事實上並不需要那麼多，而且，這個接口還存在比較大的安全隱患。所以，關於如何設計接口入參，我想談談自己的一些想法。

當然，只是一家之言，不一定就是對的。

給以下需求設計一個接口

我改造的這個接口主要用來保存單據，單據由商場下單員錄入，單據內容包括：客戶（誰）、門店（在哪裏）、服務時間（什麼時候）、服務內容（做了什麼事）等等。

單據的表設計大致如下。通過對應的 id 關聯了商場、門店和客戶，並且冗餘了部分字段。這裏暫且不討論表設計的合理性。

字段	描述
id	主鍵
org_id	商場id
org_no	商場編碼
shop_id	門店id
shop_no	門店編碼
customer_id	客戶id
customer_name	客戶名
customer_tel	客戶電話
······	省略

前端頁面大致是這樣的。商場、門店和客戶等信息都是選出來的，而不可以手動編輯。門店是商場的下級，它們的關係有點像部門和科室，所以，當我選擇了門店後，商場自然地也帶出來了。

那麼，針對這個接口，我們該如何設計入參呢？

舊接口的設計--把所有事情交給前端

舊接口的設計非常直接，數據庫表需要什麼字段，前端就傳什麼字段。

public class ServiceInfoDTO {
    @NotBlank
    private String orgId;
    @NotBlank
    private String orgNo;
    @NotBlank
    private String shopId;
    @NotBlank
    private String shopNo;
    @NotBlank
    private String customerId;
    @NotBlank
    private String customerName;
    @NotBlank
    private String customerTel;
    // ······
}

這個接口把數據的組裝邏輯全部丟給了前端，而後端幾乎什麼都不需要做，只要把前端的數據直接入庫就行。因爲什麼都不需要做，性能肯定很好。還有，這個接口上線至今，暫未出現 bug。

那麼，它就算是一個好接口了嗎？

我認爲不是，因爲這個接口太過信任調用方，即使我隨便入一個商場 id，數據照樣可以入庫。而且，不應該把邏輯都放在前端，也並不需要那麼多的入參。

我也很好奇一點，設計出這樣的接口，前端竟然沒有意見。

新接口的設計--更少更安全的入參

那麼，我們應該如何改造這個接口呢？

首先，我們來解決入參過多的問題，思路就是將數據組裝邏輯轉移到後端。在這個接口中，字段間是存在關聯關係的，例如，有了門店 id，我們就可以拿到門店編碼、商場 id、商場編碼，客戶信息也是同理。所以，我們是否可以將入參更改成這樣：

public class ServiceInfoDTO {
    // @NotBlank
    // private String orgId;
    // @NotBlank
    // private String orgNo;
    @NotBlank
    private String shopId;
    // @NotBlank
    // private String shopNo;
    @NotBlank
    private String customerId;
    // @NotBlank
    // private String customerName;
    // @NotBlank
    // private String customerTel;
    // ······
}

接着我們來解決安全問題。我們需要增加校驗，例如，當前下單員能不能選到傳進來的門店和客戶，等等。

通過改造，這個接口性能上不如舊接口，但更加安全。

你怎麼看

我還遇到過其他類似的接口。例如，查詢”我的客戶“的接口讓前端傳創建人 id 進行過濾，後端不做條件設置和校驗，直接將條件轉爲 sql 查詢數據庫，查詢”商場客戶“時則讓前端傳商場 id 進行過濾。你覺得合理嗎？

本文爲原創文章，轉載請附上原文出處鏈接：https://www.cnblogs.com/ZhangZiSheng001/p/14968393.html