到底要不要统一管理 API

[tlerbao]

现在的前后端分离项目，诸如前端 VUE 项目大家都好像喜欢统一管理 API

之前和一个码农聊过，他认为完全没必要，又不是不去看页面

所以：

你是直接 http.get(后端 URL) ，还是 import 进来 await getUserList....

所以：

统一管理 API 的好处到底是啥？是不是反倒麻烦了

直接在页面直接写 URL 请求后端不好吗？

[liuhuansir]

有没有可能一个 URL 在多个页面使用呢？

[lx271896700133]

我觉得没必要。

[markgor]

之前仅仅封装请求函数，不封装接口 URI ；
现在，把接口 URI 封装为方法。

好处：
复用的页面调用方便了，接口涉及修改的时候不用搜索来搜索去了；

坏处：
好像没啥坏处。

实际：
看项目规模和规定

[markgor]

对了，最重要一点，IDE 可以推导参数，特别是 ts 下

你如果都用 http.get(xxxxx),参数 ide 无法推导，但 IDE 的推导并不直接影响代码的执行，对于小型的项目，意义不大，来来去去几个参数，但对于大型的项目，我觉得这个还是挺好的。

[rabbbit]

后端不变就第一种，后端改来改去就第二种，项目规模大第二种。
举个例子，有个接口返回 {id：xxx}，突然有一天变成了 {fooId: xxx}，然后有十几个地方依赖这个接口。

[molvqingtai]

假如前端同学 A 在 A 页面已经写过一遍 getUserInfo, 另个一前端 B 在需要在 B 页面也需要调用这个接口，难道还 要翻一遍 API 文档或问后端哪个接口是获取用户信息

[nulIptr]

当然可以，sql 写在 controller 里也可以啊
自己项目爱咋搞咋搞，多人合作的项目按照领导说的来，自己负责的话掂量掂量会不会不好意思给人看自己的代码

[rossroma]

统一管理好处很多：
1. 可以把 get 或 post 封装起来，这样就不用担心在调用端写错了；
2. 部分接口可能需要自定义 header 或者公共参数，你可以直接写在封装的方法里，避免每次调用的时候单独再传；
3. 如果接口的 url 发生变更，你只需要改一处即可

[IvanLi127]

我觉得多套一层，配套的工作量也不少。类型得定义下吧，文档得写上吧，同一个接口的多种不兼容的出入参得做重载或再写一份吧。
上面做到了才有工程化上的优势，不然只会增加 debug 的复杂程度。
愿意加强工程化的当然能抽象就抽象。不过后端靠谱的话，不建议在这上面花时间，或许在 BFF 上花时间收益还更高。

[oneisall8955]

当然统一管理了，不然乱的一批

[llej]

不管放一起也好，分开也好，只要能够 f2 重构的时候全部自动改变就行

[pdzinc]

但凡项目大一点 必须上

[y3322]

简单项目感觉没必要。项目规模有一定规模，还是要有的

[zhy]

要不要统一管理，应该看谁来用这些 API ，如果要复用、共享，那当然要统一管理。
另外统一管理是一项长期投资，不用以后还债

[zhuangzhuang1988]

要的， 看过写在一起的 然后 vue 文件特别大。

[bojackhorseman]

我用工具🌚直接解析 swagger 生成请求和类型，再也不用手写请求函数啦

[devswork]

当然要统一管理了：
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 了，只需要引入调用就行

[CLMan]

WEB API 本来就天然适合封装（模块化）：

- WEB 请求存在大量与应用本身无关的细节，这些细节不应该与业务逻辑混合在一起
- 需要多个地方调用相同的 WEB 请求
- 多个 WEB 请求需要复用处理鉴权、错误处理（ HTTP 状态、自定义错误代码）的逻辑

将 API 理解成远程调用的话，就更能理解为啥要封装了。

将访问外部 API 接口进行统一管理是一个很自然的想法，你疑惑为啥要这么做，可能是因为你接触的问题复杂度不够或者你习惯了麻烦。

云服务厂商在提供服务时，在提供 WEB API 的同时，同时提供封装的 SDK 也是差不多的道理。是因为用户存在相关需求，用 SDK 能降低开发成本。

[unt]

正式项目“必须”上，没啥好讨论的。

实验性项目就随便了，效率第一。

[limiter]

没必要，组件化开发之后各接口交由各组件自己维护调用，只封装统一的业务逻辑，鉴权、失败处理等。要允许部分资源的重复，都放在一块很容易创造上帝类，然后整个项目到处引用，改都不好改

[Dlin]

统一管理的目的是进行复用。我不信你愿意这里写一段，然后 copy 到另一个地方，到时候要找用了这个 API 的地方到处翻，要是改一个啥，你还得到处改。

[gerefoxing]

要的，向上面说的统一管理好处很多的。强迫症看到有重复的方法和 url 就难受。

[kuber]

我觉得 OP 可以了解一下软件架构设计方面的东西。封装无非是为了处理复用和应对变化。如果是做 POC 当然无所谓，怎么快怎么来，生产系统还是有必要的。
有一本很好的书，Robert C. Martin 的“敏捷软件开发”。开篇就讲解了软件架构的原则，跟你的问题相关的有开闭原则和接口隔离原则。

[keepRun]

统一管理对于大项目来说是很必要的，这是个好习惯。
如果是小项目，那你怎么来都行，只要能跑就行