web服务是把所有的功能场景都写到一个api里好还是分开写好？

Question

最近在爬取某个网站的时候，遇到了这么个问题

目标网站所有的业务场景功能接口，都是访问的一个api，通过请求参数来区分功能，可能其就是通过判断入参来分发到某个handler的把，有的时候会发现其入参只是一个sqlID，用过sqlID的不同来执行不同的sql语句以实现不同的业务场景查询；

我平时写api基本是一个功能一个接口，不会融合成一个，遵循restful开发；

请问各位大佬，哪种方式好？优缺点？

Answer 1

我们一般也是不同功能写不同接口，至少说api/后面的一层根据业务和功能会有所区别。

比如 XXX/api/file/download...
楼主说的这种传sqlId的我还真没尝试过...而且这种场景应该会很局限才对。

但是我猜测哈，接口也不一定就是一个纯粹前端与后端的交互，很有可能中间是有其他服务来转接的。比如在前端和后端之间可能有一层部署好的网关或者其他服务，那如果这个服务要求接口必须要写成某种格式，比如api/sqlid，必须带有这个id，然后通过中间服务去对接后端对应的功能。

Answer 2

一般开发，肯定是分开好
你感觉它们没有分开，可能是某层通过转换代理表现出来（以隐藏细节或者提供简化的可扩展接口）

如果是对外提供服务的，可能会进行接口汇聚成为一个唯一接口，但底层（后台）其实是分开的，这样这个接口进行功能变化时，大多数都不用变，只影响很少的部分（变化部分），而且还可以做到具体功能迭代升级，而接口稳定。