前端，把 api 封装到一个文件夹到底有没有必要

[kensoz]

最近在改一个 vue 项目，看了很多 api 接口封装的文章，似乎这是主流的处理方式？

于是尝试了一下发现了几个问题。

首先，管理是集中了，不过有点类似于 vuex 的思维方式。看过很多人不提倡把请求放在 vuex 里，而使用就近原则，不过本题的 api 接口封装，虽然只是把一些基本实例写好在导入到模板文件中，但是还是让人感觉到了 vuex 那个味。

其次，修改起来感觉没有独立方便，导入还有改名什么的有点麻烦了，感觉 api 端口修改频率都不如参数的修改高。尤其是需要改名的时候，忘记改一个地方的情况经常发生。

所以想问问，这种方案真的是主流的处理方式嘛？真的有必要嘛？

[kennhuang]

写 unit tests 的同学就知道封装出来的好处了😂

[hitaoguo]

我用装饰器做的封装，代码类似这样。


然后页面里就直接这样用

[ccraohng]

api 配置对象配合 ts 输出 一个类似 service 的对象

[chairuosen]

不封在一起，所有请求通用的：鉴权、域名配置、封装协议解构、异常判断、日志、重试、超时、token 过期重拿、mock 、监控、、、、、等等等等写在哪里。后端换个域名、path 、封装协议，甚至接口实现要所有地方挨个找么？

按道理，所有非你项目代码实现的部分，都不应该直接在业务逻辑里调（比如 http 接口，RN 里的客户端接口，SDK 的接口），应该有个 adapter 层来做对接，都是不可信的，没准哪天对方心情不好想改就改的，他改了你不可能全局搜代码改吧。

[otakustay]

https://i.loli.net/2021/08/30/PbtvE15jouyZ4BM.png

[masterV]

同意 2L acthtml 和 10L ntwjx 的答案。
封装请求不仅仅是为了看起来工整有序，分离数据源与业务逻辑也很重要。
封装请求后，前端业务处不 care 数据怎么来的、后端需要什么参数，通通可以在请求文件里写好，比如可做以下处理：

1 、规范协议（请求参数、响应参数）；
2 、做默认赋值处理（ page/size/offset/limit ）；
3 、处理成后端需要的格式（指定类型、指定格式）；
4 、字段映射（后端字段命名可能是下划线，前端可能习惯用驼峰，前后端对同一事物翻译可能不同，映射了就皆大欢喜）
5 、做好以上后，在 vscode 中会自动匹配到定义的参数类型给出提示，js 写成 ts 的感觉，很舒服，这应该就是上面很多楼提到的 adapter 的功能，顾名思义转接器。
5 、其他：
- 认证和授权, 引导到登录界面, 申请权限界面
- 异常处理, 上报和用户友好提示
- 接口缓存
- 并发控制

[DOLLOR]

ts 把 api 封装好，每次调用就能获得 interface 定义好类型的对象，不舒服吗？

[ae86]

@otakustay #25 有原地址吗，这种 狭长 的在电脑上看不方便

[liaoberlin]

这个肯定要结合使用场景来讨论的，结合我这几年做过的项目倒是觉得统一在一个文件或文件夹下是比较合理的，说下我的使用方式

1. 我们接口调用都不是手写的，通过一个命令行就直接生成到项目里面统一的文件夹了，包括接口配置跟接口方法、TS 声明，放在一起是方便统一生成，调用的地方只需要调用生成好的方法传参数就行

2. 对于一些接口需要多个地方调用的，最好是要封装的，当然除了简单的 method，url 之外，有些接口还要一些 headers 、是否展示 loading 、是否是 restful 接口等等这些额外的配置参数，封装起来之后多处调用的时候都不需要管这些配置，只需要传参数就行

3. 对于都放在同一个文件容易冲突，可以把一个接口或一类接口放在同一个文件，然后都在 api.js 中引入统一暴露出去就行

[otakustay]

@ae86 找不到啥服务能托管 markdown 分享，就截成图了

[EscYezi]

@otakustay gist

[CQYJ]

封装是为了解决复用的问题，不复用就不要封装

[shilianmlxg]

@hitaoguo 大佬 求教程

[hitaoguo]

@shilianmlxg #33 写了个文章你看下 https://segmentfault.com/a/1190000040661288