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

x33g5p2x  于2021-11-14 转载在 其他  
字(1.7k)|赞(0)|评价(0)|浏览(210)

最近,我改造一个旧接口时发现,这个接口有 30 多个入参,而事实上并不需要那么多,而且,这个接口还存在比较大的安全隐患。所以,关于如何设计接口入参,我想谈谈自己的一些想法。 当然,只是一家之言,不一定就是对的。

为什么说起接口设计

最近,我改造一个旧接口时发现,这个接口有 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
分层,抽象,高内聚,低耦合

相关文章