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

子月生發表於2021-07-04

為什麼說起介面設計

最近，我改造一箇舊介面時發現，這個介面有 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

相關文章