现在的前后端分离项目,诸如前端 VUE 项目大家都好像喜欢统一管理 API
之前和一个码农聊过,他认为完全没必要,又不是不去看页面
所以:
你是直接 http.get(后端 URL) ,还是 import 进来 await getUserList....
所以:
统一管理 API 的好处到底是啥?是不是反倒麻烦了
直接在页面直接写 URL 请求后端不好吗?
1
liuhuansir 290 天前
有没有可能一个 URL 在多个页面使用呢?
|
2
lx271896700133 290 天前
我觉得没必要。
|
3
markgor 290 天前
之前仅仅封装请求函数,不封装接口 URI ;
现在,把接口 URI 封装为方法。 好处: 复用的页面调用方便了,接口涉及修改的时候不用搜索来搜索去了; 坏处: 好像没啥坏处。 实际: 看项目规模和规定 |
4
markgor 290 天前
对了,最重要一点,IDE 可以推导参数,特别是 ts 下
你如果都用 http.get(xxxxx),参数 ide 无法推导,但 IDE 的推导并不直接影响代码的执行,对于小型的项目,意义不大,来来去去几个参数,但对于大型的项目,我觉得这个还是挺好的。 |
5
rabbbit 290 天前
后端不变就第一种,后端改来改去就第二种,项目规模大第二种。
举个例子,有个接口返回 {id:xxx},突然有一天变成了 {fooId: xxx},然后有十几个地方依赖这个接口。 |
6
molvqingtai 290 天前
假如前端同学 A 在 A 页面已经写过一遍 getUserInfo, 另个一前端 B 在需要在 B 页面也需要调用这个接口,难道还 要翻一遍 API 文档或问后端哪个接口是获取用户信息
|
7
nulIptr 290 天前
当然可以,sql 写在 controller 里也可以啊
自己项目爱咋搞咋搞,多人合作的项目按照领导说的来,自己负责的话掂量掂量会不会不好意思给人看自己的代码 |
8
rossroma 290 天前
统一管理好处很多:
1. 可以把 get 或 post 封装起来,这样就不用担心在调用端写错了; 2. 部分接口可能需要自定义 header 或者公共参数,你可以直接写在封装的方法里,避免每次调用的时候单独再传; 3. 如果接口的 url 发生变更,你只需要改一处即可 |
9
IvanLi127 290 天前 via Android
我觉得多套一层,配套的工作量也不少。类型得定义下吧,文档得写上吧,同一个接口的多种不兼容的出入参得做重载或再写一份吧。
上面做到了才有工程化上的优势,不然只会增加 debug 的复杂程度。 愿意加强工程化的当然能抽象就抽象。不过后端靠谱的话,不建议在这上面花时间,或许在 BFF 上花时间收益还更高。 |
10
oneisall8955 290 天前 via Android
当然统一管理了,不然乱的一批
|
11
llej 290 天前
不管放一起也好,分开也好,只要能够 f2 重构的时候全部自动改变就行
|
12
pdzinc 290 天前
但凡项目大一点 必须上
|
13
y3322 290 天前
简单项目感觉没必要。项目规模有一定规模,还是要有的
|
14
zhy 290 天前
要不要统一管理,应该看谁来用这些 API ,如果要复用、共享,那当然要统一管理。
另外统一管理是一项长期投资,不用以后还债 |
15
zhuangzhuang1988 290 天前
要的, 看过写在一起的 然后 vue 文件特别大。
|
16
bojackhorseman 290 天前 via iPhone
我用工具🌚直接解析 swagger 生成请求和类型,再也不用手写请求函数啦
|
17
devswork 290 天前
当然要统一管理了:
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 了,只需要引入调用就行 |
18
CLMan 290 天前
WEB API 本来就天然适合封装(模块化):
- WEB 请求存在大量与应用本身无关的细节,这些细节不应该与业务逻辑混合在一起 - 需要多个地方调用相同的 WEB 请求 - 多个 WEB 请求需要复用处理鉴权、错误处理( HTTP 状态、自定义错误代码)的逻辑 将 API 理解成远程调用的话,就更能理解为啥要封装了。 将访问外部 API 接口进行统一管理是一个很自然的想法,你疑惑为啥要这么做,可能是因为你接触的问题复杂度不够或者你习惯了麻烦。 云服务厂商在提供服务时,在提供 WEB API 的同时,同时提供封装的 SDK 也是差不多的道理。是因为用户存在相关需求,用 SDK 能降低开发成本。 |
19
unt 289 天前
正式项目“必须”上,没啥好讨论的。
实验性项目就随便了,效率第一。 |
20
limiter 289 天前
没必要,组件化开发之后各接口交由各组件自己维护调用,只封装统一的业务逻辑,鉴权、失败处理等。要允许部分资源的重复,都放在一块很容易创造上帝类,然后整个项目到处引用,改都不好改
|
21
Dlin 289 天前
统一管理的目的是进行复用。我不信你愿意这里写一段,然后 copy 到另一个地方,到时候要找用了这个 API 的地方到处翻,要是改一个啥,你还得到处改。
|
22
gerefoxing 289 天前
要的,向上面说的统一管理好处很多的。强迫症看到有重复的方法和 url 就难受。
|
23
kuber 289 天前
我觉得 OP 可以了解一下软件架构设计方面的东西。封装无非是为了处理复用和应对变化。如果是做 POC 当然无所谓,怎么快怎么来,生产系统还是有必要的。
有一本很好的书,Robert C. Martin 的“敏捷软件开发”。开篇就讲解了软件架构的原则,跟你的问题相关的有开闭原则和接口隔离原则。 |
24
keepRun 288 天前
统一管理对于大项目来说是很必要的,这是个好习惯。
如果是小项目,那你怎么来都行,只要能跑就行 |