到底要不要统一管理 API

2024-01-17 17:42:41 +08:00
tlerbao  tlerbao

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

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

所以:

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

所以:

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

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

3469 次点击
所在节点   程序员  程序员
24 条回复
liuhuansir
liuhuansir
2024-01-17 17:45:09 +08:00
有没有可能一个 URL 在多个页面使用呢?
lx271896700133
lx271896700133
2024-01-17 18:00:36 +08:00
我觉得没必要。
markgor
markgor
2024-01-17 18:04:43 +08:00
之前仅仅封装请求函数,不封装接口 URI ;
现在,把接口 URI 封装为方法。

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

坏处:
好像没啥坏处。

实际:
看项目规模和规定
markgor
markgor
2024-01-17 18:08:58 +08:00
对了,最重要一点,IDE 可以推导参数,特别是 ts 下

你如果都用 http.get(xxxxx),参数 ide 无法推导,但 IDE 的推导并不直接影响代码的执行,对于小型的项目,意义不大,来来去去几个参数,但对于大型的项目,我觉得这个还是挺好的。
rabbbit
rabbbit
2024-01-17 18:10:31 +08:00
后端不变就第一种,后端改来改去就第二种,项目规模大第二种。
举个例子,有个接口返回 {id:xxx},突然有一天变成了 {fooId: xxx},然后有十几个地方依赖这个接口。
molvqingtai
molvqingtai
2024-01-17 18:21:04 +08:00
假如前端同学 A 在 A 页面已经写过一遍 getUserInfo, 另个一前端 B 在需要在 B 页面也需要调用这个接口,难道还 要翻一遍 API 文档或问后端哪个接口是获取用户信息
nulIptr
nulIptr
2024-01-17 18:34:19 +08:00
当然可以,sql 写在 controller 里也可以啊
自己项目爱咋搞咋搞,多人合作的项目按照领导说的来,自己负责的话掂量掂量会不会不好意思给人看自己的代码
rossroma
rossroma
2024-01-17 19:10:17 +08:00
统一管理好处很多:
1. 可以把 get 或 post 封装起来,这样就不用担心在调用端写错了;
2. 部分接口可能需要自定义 header 或者公共参数,你可以直接写在封装的方法里,避免每次调用的时候单独再传;
3. 如果接口的 url 发生变更,你只需要改一处即可
IvanLi127
IvanLi127
2024-01-17 19:34:12 +08:00
我觉得多套一层,配套的工作量也不少。类型得定义下吧,文档得写上吧,同一个接口的多种不兼容的出入参得做重载或再写一份吧。
上面做到了才有工程化上的优势,不然只会增加 debug 的复杂程度。
愿意加强工程化的当然能抽象就抽象。不过后端靠谱的话,不建议在这上面花时间,或许在 BFF 上花时间收益还更高。
oneisall8955
oneisall8955
2024-01-17 19:54:53 +08:00
当然统一管理了,不然乱的一批
llej
llej
2024-01-17 20:01:10 +08:00
不管放一起也好,分开也好,只要能够 f2 重构的时候全部自动改变就行
pdzinc
pdzinc
2024-01-17 20:04:26 +08:00
但凡项目大一点 必须上
y3322
y3322
2024-01-17 20:07:14 +08:00
简单项目感觉没必要。项目规模有一定规模,还是要有的
zhy
zhy
2024-01-17 20:12:53 +08:00
要不要统一管理,应该看谁来用这些 API ,如果要复用、共享,那当然要统一管理。
另外统一管理是一项长期投资,不用以后还债
zhuangzhuang1988
zhuangzhuang1988
2024-01-17 20:29:38 +08:00
要的, 看过写在一起的 然后 vue 文件特别大。
bojackhorseman
2024-01-17 22:16:26 +08:00
我用工具🌚直接解析 swagger 生成请求和类型,再也不用手写请求函数啦
devswork
2024-01-17 22:43:11 +08:00
当然要统一管理了:
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
2024-01-17 23:13:17 +08:00
WEB API 本来就天然适合封装(模块化):

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

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

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

云服务厂商在提供服务时,在提供 WEB API 的同时,同时提供封装的 SDK 也是差不多的道理。是因为用户存在相关需求,用 SDK 能降低开发成本。
unt
2024-01-18 09:46:23 +08:00
正式项目“必须”上,没啥好讨论的。

实验性项目就随便了,效率第一。
limiter
2024-01-18 15:26:30 +08:00
没必要,组件化开发之后各接口交由各组件自己维护调用,只封装统一的业务逻辑,鉴权、失败处理等。要允许部分资源的重复,都放在一块很容易创造上帝类,然后整个项目到处引用,改都不好改

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1009433

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX