请问有必要把api写在同一个文件吗？

中文
#1

我看到很多都人会把所有的api写在一个文件里export，但为啥呢？有啥有点吗？

1 Like
#2

当然不需要了，分开写更方便管理。

#3

统一管理

#4

如果分开写，一个 API 在 10 个地方调用，当接口调整需要增加一个参数时，改 10 个地方还是改 1 个地方更快？

不止如此，以下这些情况都是分开写做不到的：

  1. 如果分开写，如何保证接口逻辑变动时，所有用到这个 API 的地方你都能改到，漏了怎么办？等到用户流失后，或者 BUG 反馈到手里被骂一通后再修复？
  2. 当接口因紧急情况需要暂时性禁用，并给用户提示，且业务上或者其他情况导致后端不能修改，去修改每一个用到的地方显示吗？注意紧急情况、暂时性。
  3. 对于完善的前端项目，少不了 TypeScript，难道在每个地方去对接口重复定义一次类型吗？
  4. 可读性，见下方两个示例对比：
import { getUserInfo } from '@/api/user'

// 类型已经在接口函数中定义，这里 userInfo 已经是具有完整类型定义的对象，且接口的异常处理也已完成
const userInfo = await getUserInfo()

console.log(userInfo.id)
console.log(userInfo.name)

import Axios from 'axios'
import { BASE_URL } from '@/config'

const res = await Axios.get(`${BASE_URL}/v1/api/user/info`)
const data = res.data
// 检查响应
if (data && data.code === 0) {
  // 为用户信息定义类型
  const userInfo = data.data as { id: number; name: string; nickname: string }

  console.log(userInfo.id)
  console.log(userInfo.name)
} else {
  alert(data.msg || '获取失败')
}

思考一下假设有 100 个地方用到了这个接口，当接口地址、请求参数、响应数据结构等任意一处出现变动导致的实际情况绝对是灾难性的。

另一个就是可读性，上方代码你应该能看出来。极端点，如果你的后端写出来的接口是 /v1/api/path/to/backend/beijing/huoquzhanghaoxinxi，你或者刚接触项目的同事仅仅是为了知道这个接口请求是做什么用的需要花几倍的时间并且被打断思路，效率根本无从谈起。

#5

我也是一次性导出，如果公司内有私有 npm 仓库，可以发布为一个 npm 包。

我用 pont 根据 swagger 文档自动生成的，发布到内网的，接入流水线后，更新和发布都很方便。

1 Like
#6

你这是什么设计呀，服了。

#7

举个例子，你有更合适的也可以在这讨论的

#8

为什么觉得他人不合适的代码 却不自己贴出合适的代码呀 服了