最近，我改造一个旧接口时发现，这个接口有 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 进行过滤。你觉得合理吗？
Original: https://www.cnblogs.com/ZhangZiSheng001/p/14968393.html
Author: 子月生
Title: 关于接口设计的思考–我们真的需要这么多入参吗
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/610440/
转载文章受原作者版权保护。转载请注明原作者出处！