到底要不要统一管理 API

查看 194|回复 18
作者:tlerbao   
现在的前后端分离项目,诸如前端 VUE 项目大家都好像喜欢统一管理 API
之前和一个码农聊过,他认为完全没必要,又不是不去看页面
所以:
你是直接 http.get(后端 URL) ,还是 import 进来 await getUserList....
所以:
统一管理 API 的好处到底是啥?是不是反倒麻烦了
直接在页面直接写 URL 请求后端不好吗?

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 上花时间收益还更高。
您需要登录后才可以回帖 登录 | 立即注册

返回顶部