关于接口设计的思考--我们真的需要这么多入参吗

为什么说起接口设计

最近，我改造一个旧接口时发现，这个接口有 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