React项目中Axios调用API两种返回写法的最佳实践选择问询

以下是你提到的两种常见实现方案：

方案1：仅返回响应体data #

export const getProduct = ():Promise<Product> => {
  const {data} = await axios.get<Product>('http://myurl.com/api/getproduct');
  return data;
}

方案2：返回完整Axios响应对象 #

export const getProduct = ():Promise<AxiosResponse<Product>> => {
  return axios.get<Product>('http://myurl.com/api/getproduct');
}

两种方案的优缺点对比 #

• 仅返回响应体data（方案1）
  • 优点：接口层和Axios库解耦，上层业务代码不需要感知请求库的存在，类型声明简洁，后续替换请求库（比如切换为fetch、umi-request等）时，只需要修改接口层的实现，不需要改动业务调用代码，心智负担更低，是绝大多数业务场景的最优选择
  • 缺点：无法满足需要获取响应头、HTTP状态码等非业务数据的特殊需求
• 返回完整响应对象（方案2）
  • 优点：灵活度最高，调用侧可以拿到所有响应相关的信息，适配特殊的定制化需求
  • 缺点：和Axios强绑定，业务层需要额外引入Axios的类型定义，后续换请求库时需要全量修改所有调用侧的代码，维护成本更高

行业通用规范建议 #

优先默认使用方案1作为接口层的统一规范，仅在有特殊需求的个别场景下使用方案2，或是对通用请求函数增加可选配置来兼容两种需求。

你可以在封装的通用请求函数里加参数控制返回格式，示例如下：

// 通用请求函数
const request = async <T = any>(config: AxiosRequestConfig, returnFullResponse = false): Promise<T | AxiosResponse<T>> => {
  const response = await axios.request<T>(config);
  // 可在此处统一处理错误、全局报错提示等逻辑
  return returnFullResponse ? response : response.data;
}

// 普通业务接口调用，默认只返回data
export const getProduct = ():Promise<Product> => {
  return request<Product>({ url: 'http://myurl.com/api/getproduct', method: 'GET' });
}

// 需要完整响应的特殊接口
export const getProductWithFullResponse = ():Promise<AxiosResponse<Product>> => {
  return request<Product>({ url: 'http://myurl.com/api/getproduct', method: 'GET' }, true) as Promise<AxiosResponse<Product>>;
}

这样既保证了大部分场景的简洁性，也兼容了少数特殊场景的需求，是目前行业内接受度最高的实现方式。

内容的提问来源于stack exchange，提问作者Nick Mehrdad Babaki