当然要统一管理了：
1. 引入一层封装 API ，可以提高复用性，比如各类 common API ，字典之类、用户信息获取类，免得到处都是 URL 复制粘贴
2. 如果接口会变动，只需要改动这一层就行了，而且可以追溯到都有哪些地方用到了此 API
3. 写拦截器，统一处理状态码，统一处理 header 、token 、以及一些特定的请求头要求
4. 多个 API 组成一个功能时，可以很方便的写一个 function ，然后直接多个 API 调用配合 + 异常处理（撤销 API 、取消之类 API ），对于调用方而言只需要关心结果成功、或者失败 + 原因，封装细节不需要调用时有心智负担
5. 忽略掉了网络请求和 axios 细节，对于调用方 import 进来直接 call 调用 function + 传参，不需要关心他是 POST 、GET ... 请求方法，不需要关心 header 放什么、不需要关心参数传递是放在 QueryParameter 还是 RequestBody 、PathVariable....因为一旦封装一层，就代表 API SDK 了，只需要引入调用就行
WEB API 本来就天然适合封装（模块化）：
- WEB 请求存在大量与应用本身无关的细节，这些细节不应该与业务逻辑混合在一起
- 需要多个地方调用相同的 WEB 请求
- 多个 WEB 请求需要复用处理鉴权、错误处理（ HTTP 状态、自定义错误代码）的逻辑
将 API 理解成远程调用的话，就更能理解为啥要封装了。
将访问外部 API 接口进行统一管理是一个很自然的想法，你疑惑为啥要这么做，可能是因为你接触的问题复杂度不够或者你习惯了麻烦。
云服务厂商在提供服务时，在提供 WEB API 的同时，同时提供封装的 SDK 也是差不多的道理。是因为用户存在相关需求，用 SDK 能降低开发成本。
