接口合并与拆分的一些注意事项
一、业务场景
Web项目开发中，接口开发是最常见的工作，大多数人每天大量的工作都是在写接口。其次可能会写一些其他
的东西，比如定时任务，MQ数据同步，写各种文档等等的操作。接口是一个系统与外界交互的方式，比如查询
数据，修改数据，新增数据，删除数据等等；或者提供其他的一些功能，比如数据导出导入，文件上传，发送email
等等。这些都是通过接口来完成的，接口质量的好坏关系着整个系统能否正常运转，需要考虑的事项比较多。
二、需求分析
曾经在掘金上面看到过一篇优质文章，主要讲的是写一个接口的注意事项，文章写得很好，值得反复查看。自己
目前写的这篇博文，没有像那位作者一样写得那么高大上，主要还是一些比较常规的注意事项，或者是真实遇到的
一些问题，如何去解决。比如为什么有的接口不能共用，需要进行拆分，怎么进行拆分？如果通过传入不同的参数来
进行控制不是一样的效果吗？用户角色鉴权一般都会有，可是怎么进行数据鉴权呢？如果越权了将会造成什么后果？
什么时候接口可以进行合并操作呢？等等，都是一些在开发中可能会实实在在遇到的一些问题，下面一一解答。
https://juejin.cn/post/7095532251118567431
三、解决方案
.1.接口拆分的方式：按照功能进行拆分，按照权限进行拆分，或者出于接口性能的考虑进行拆分。示例一，某一张表
table已经写好的常规的增、删、改、查功能。现在新增一个功能，暂且叫做功能A吧，就一个简单的功能，按照业务要求
只修改table表中的一个字段，这时候是直接使用修改功能还是新加一个接口进行操作呢？自己的做法会直接新增一个接口，
这个是按照功能的单一职责来进行拆分的，修改数据和功能A完全是两个不同维度的操作。放在一个接口中也能够实现功能，
只是这种方式不可取，这样写会让人分不清这个接口是用来修改数据信息的还是用来实现功能A的。因此接口最好独立出来，
但是在service中可以共用，互不影响。
示意二：某张表数据类型分为A/B/C三种类型，由一个字段来进行区分，某个接口的功能是来用作查询的，比如是查询类型A
的列表数据。如果新增一个功能菜单，想查询类型B的数据，则可以添加一个参数，然后让前端页面中直接传递一个固定参数即可。
这个时候需不需要拆分呢？为什么？自己的回答是需要进行拆分，原因很简单，这个接口通过一个特定的参数，完成不同数据类型
的查询，实现两个功能。如果有人只能看A类型的数据，在前端做一些手脚，修改这个传递的参数值，则有可能会查询到B类型
的数据。简单点说就是数据越权，看到到当前用户没有权限查看的数据。这时候如何处理呢？当然是拆分为不同的两个接口，接口
A还是查询A类型的数据，接口B则只查询B类型的数据。两个接口可以在Controller中将需要查询的参数类型写死，这样就很好的
解决掉上面可能存在的问题。
示例三：某接口是一个简单的APP端查询的接口，都是返回同样的数据，参数也都是一模一样的，只是调用的地方不一样，
一个在点击操作A时查询，一个在点击操作B的时候进行查询。这时候要不要进行拆分呢？一定要进行拆分。如果App的用户
量比较大，则在接口设计的时候，一般都会对接口进行限流处理，即是某个接口达到最大访问量的时候，就会直接返回友好的
提示信息，比如系统繁忙，请稍后重试。操作A和操作B都是调用同一个接口，它们的最大并发访问量假设为50，每个操作的
平均访问并发数为25，如果超过50则任意一个地方再次访问就会进行提示。可是如果拆分为两个接口，则变为操作A的并发
访问量为50，操作B的并发访问量为50，整整增大了2倍，Service仍然可以共用。这就是为什么要进行拆分的原因。
实际项目中遇到的一些情况，最开始一个同事写的接口，为了方便，三种不同类型的列表数据都使用一个接口进行查询，还有
一个详情查询的接口也是使用同一个，结果被要求整改。整改之后变为了6个接口，每一个列表查询只能查询特定的数据，详情查询
也是一样的道理。自己第一次遇到要求这么严格的要求，也算是学习到新东西，因为公司对于系统安全这一块要求非常严格。如果出
现这种低级的数据越权的情况，那后果将会很严重。
.2.接口合并的方式：按照实际业务需求进行合并。示例一：在查询某张主表信息的时候，还会进行附带查询与主表相关的很多数据，比如
查询表A，还需要查询与表A相关的1,2,3,4,5张表的数据。这时候如果单独查询，则需要发5次请求，如果只查询一次，将6张表的数据在后台
查询出来，然后在组装成一个对象中返回，则请求的次数会减少很多。也是一种优化的方式，减少前端与后台的交互次数，将需要的数据一次性返回。
示例二：和示例一类似，只是查询的表没有这么多，大多都是两张表或三张表进行关联查询。比如查询表A的时候，还需要查询表B的数据，这时候
如果查询多次也会有些浪费资源，直接一次性查询出两张表的数据即可。
