标签：String -- 多入 商场 private 接口 id NotBlank

为什么说起接口设计

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

当然，只是一家之言，不一定就是对的。

给以下需求设计一个接口

我改造的这个接口主要用来保存单据，单据由商场下单员录入，单据内容包括：客户（谁）、门店（在哪里）、服务时间（什么时候）、服务内容（做了什么事）等等。

单据的表设计大致如下。通过对应的 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;
    // ······
}

这个接口把数据的组装逻辑全部丢给了前端，而后端几乎什么都不需要做，只要把前端的数据直接入库就行。因为什么都不需要做，性能肯定很好。还有，这个接口上线至今，暂未出现 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

标签：String,--,多入,商场,private,接口,id,NotBlank
来源： https://www.cnblogs.com/ZhangZiSheng001/p/14968393.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。