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

[kensoz]

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

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

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

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

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

[hackyuan]

选中函数名 F2

[acthtml]

抽象出来，放在一个独立的文件夹主要解决：

1. 多个前端组件可能对同一个 [后端服务复用] 。
2. 组件不依赖于服务，而是依赖于服务的产生的数据，方便 [前端组件的复用] 。
3. 结构清晰，如果后端服务改动，可以很容易做修改。

[zarvin]

vue 开发全局搜索用得多，看了几个开源项目好像都是这样

[shzx1994529]

一个路由一个 api.js 呗，这玩意无所谓啊，能让别人看懂就行

[Yooe]

我怎么记得之前好像看到过这个帖子？= =

[Kusoku]

小的项目放在一起就是为了方便统一维护，根据模块拆分到不同的小文件也是为了按需要引入，这种组织方式可以适应绝大部分项目的需要。如果按模块划分子文件夹，然后再每个子文件夹再划分各种小文件夹，有部分公共请求也需要单独拿出来，实际上还不如单独用一个文件夹来放请求接口配置的内容，区分公共部分和模块部分，这样清楚明晰方便定位。

[chenluo0429]

api 接口封装就是为了对组件屏蔽后端的具体实现，同时统一处理接口的变更。
如果有参数变更，封装反而可以通过默认值等手段来快速适配。如果有破坏性的变更需要全部修改，封装的你都能忘记，独立的你就一定改得全？

[mozhizhu]

你经历过后端改请求方式吗？经历过后端改路由吗？

[cydysm]

不同项目有不同的处理方式，没有银弹，写得多了就知道怎么办了。

[netwjx]

没有显著必要, 曾经多年 java 和 dotnet, 熟悉各种 MVC, ORM

在前端领域, 将 ajax 调用抽取成函数, 99%是脱裤子放屁


因为 ajax 请求的代码量很少, 后端是因为这部分业务逻辑比较多, 必须复用

前端就算写 3 遍 ajax 调用, 重复的只有 1~2 行, 所谓封装, 只是将这部分重复的代码, 变成了重复的函数调用, 并没有实质意义, 反而增加了一层映射关系(函数名 -> ajax URL)


不重复的部分是如何生成不同的 ajax 请求参数, 而切实有效的封装, 是真能减少重复业务逻辑的

比如根据业务逻辑

- 规整各种 ajax 请求参数: id 必须转换成有效数字, 而不能是字符串
- 处理 ajax 响应参数: 转换成适合前端使用的格式

另一类需要集中处理的逻辑, 用 ajax 模块插件实现

- 认证和授权, 引导到登录界面, 申请权限界面
- 异常处理, 上报和用户友好提示
- 接口缓存
- 并发控制

[libook]

抛开场景谈对错都是耍流氓。

一个 Vue 项目是由各种类别的模块组成的（如组件、服务、路由……），对于不同项目来说；不同类别的模块规模不同，比如可能营销项目路由路由巨多、组件和服务很少，后台项目路由很少、组件和服务巨多；模块之间的对应关系也不一样，比如有的项目服务可以被所有组件复用，也有的项目服务是从属于各个组件的，不可跨组件使用。
Vue 提供了项目文件结构的灵活性，那么自然在不同场景下可以设计成不同的文件结构，最终都是服务于开发效率。

[Biwood]

我也觉得有些多余，明明 request 工具在组建里面直接请求就行了，还要多封装一层，而且这些请求函数复用性特别低，绝大部分都只在一个模块用到了一次而已。真有复用的情况，也是跟着组件一起，而不是单独调用。有种过度设计的感觉。

@libook
楼主说的应该是那种纯粹的 api 封装，只是提前固定了路径和 method 而已，不携带具体的业务数据，你说的“服务”的概念其实已经在 api 基础上做了其他业务逻辑了。

[lin07hui]

我这边之前的人封装的
// src/api/index.js
export * from "./xxx.js";

// src/api/xxx.js
export const xxxDetail = (id) => { ... };
export const xxxList = ({ page, ... }) => { ... };
export const xxxSave = ({ id, ... } ) => { ... };

// src/store/modules/xxx.js
import { xxxDetail, xxxList, xxxSave } from "@/utils/api";
import { createState } from "@/utils/state";

const options = createState({ detail: { api: xxxDetail, ... }, list: { api: xxxList, ... }, save: { api: xxxSave, ... });

export default {
namespaced: true,
...options
};

// src/utils/state -- 248 行代码
// createState
/**
* Create a store options
* @param {Promise} list.api - 获取分页列表数据接口
* @param {Object} list.params - 发送给接口的参数
* @param {Function} list.beforeSet - 设置数据之前执行，beforeSet(接口数据)
* @param {Promise} detail.api - 获取单条数据接口
* @param {Object} detail.params - 发送给接口的参数
* @param {Promise} save.api - 保存接口
* @param {Function} save.success - 保存成功后运行：success({ commit, state, dispatch }, record)
* ....还有很多
*/

[Biwood]

当然，如果是 TypeScript 项目，这样写比较方便提前约定前后端字段的对应关系，类似于 adapter 的概念

[lin07hui]

@lin07hui #13 import { xxxDetail, xxxList, xxxSave } from "@/api";

[ansenJ]

初期多人开发的时候 别说 API 了 Store Router 都是每人一个文件， 等项目稳定了再汇总的。多人操作一个文件的那位， 你是爱上解决 git 冲突吗？

[fernandoxu]

按领域组织更好，

[Sapp]

现在 api 不都是自动生成函数么？还有人手写？？？

[chairuosen]

说不需要的都没写过大项目？

[cloudzqy]

现在基本 typescript 了，基本都封，定义类型比较方便。