前端API设计最佳实践:让你的API更优雅

前端API设计最佳实践:让你的API更优雅

毒舌时刻

API设计?听起来就像是后端工程师的事情,关前端什么事?你以为前端只需要调用API就可以了?别天真了!如果API设计得不好,前端开发会变得非常痛苦。

你以为随便设计个API就能用?别做梦了!我见过太多糟糕的API设计,比如返回的数据结构不一致,错误处理不规范,文档不完整,这些都会让前端开发者崩溃。

为什么你需要这个

  1. 提高开发效率:良好的API设计可以减少前端开发的工作量,提高开发效率。
  2. 减少错误:规范的API设计可以减少前端开发中的错误,提高代码的可靠性。
  3. 改善用户体验:合理的API设计可以提高应用的响应速度,改善用户体验。
  4. 便于维护:良好的API设计可以使代码更易于维护,减少后期的维护成本。
  5. 促进团队协作:规范的API设计可以促进前后端团队的协作,减少沟通成本。

反面教材

// 这是一个典型的糟糕API设计 // 1. 不一致的命名规范 // 获取用户列表 fetch('/api/getUsers') .then(response => response.json()) .then(data => console.log(data)); // 获取单个用户 fetch('/api/user/1') .then(response => response.json()) .then(data => console.log(data)); // 2. 不一致的返回格式 // 成功返回 // { "status": "success", "data": { "id": 1, "name": "John" } } // 失败返回 // { "error": "User not found" } // 3. 不规范的错误处理 fetch('/api/users') .then(response => { if (response.status === 200) { return response.json(); } else if (response.status === 404) { throw new Error('Not found'); } else if (response.status === 500) { throw new Error('Server error'); } else { throw new Error('Unknown error'); } }) .then(data => console.log(data)) .catch(error => console.error(error)); // 4. 缺少分页和过滤 fetch('/api/users') .then(response => response.json()) .then(data => { // 当用户数量很多时,会返回大量数据,影响性能 console.log(data); }); 

问题

  • 命名规范不一致,有的使用驼峰命名,有的使用下划线命名
  • 返回格式不一致,成功和失败的返回格式不同
  • 错误处理不规范,需要手动处理不同的状态码
  • 缺少分页和过滤功能,返回大量数据时影响性能
  • 缺少版本控制,后续API变更时会影响现有代码

正确的做法

RESTful API设计

// 1. 一致的命名规范 // 获取用户列表 fetch('/api/v1/users') .then(response => response.json()) .then(data => console.log(data)); // 获取单个用户 fetch('/api/v1/users/1') .then(response => response.json()) .then(data => console.log(data)); // 创建用户 fetch('/api/v1/users', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ name: 'John', email: '[email protected]' }) }) .then(response => response.json()) .then(data => console.log(data)); // 更新用户 fetch('/api/v1/users/1', { method: 'PUT', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ name: 'John Doe', email: '[email protected]' }) }) .then(response => response.json()) .then(data => console.log(data)); // 删除用户 fetch('/api/v1/users/1', { method: 'DELETE' }) .then(response => response.json()) .then(data => console.log(data)); 

一致的返回格式

// 成功返回 // { // "success": true, // "data": { "id": 1, "name": "John" }, // "message": "User retrieved successfully" // } // 失败返回 // { // "success": false, // "error": { "code": 404, "message": "User not found" } // } // 统一的错误处理 async function fetchApi(url, options = {}) { try { const response = await fetch(url, options); const data = await response.json(); if (!data.success) { throw new Error(data.error?.message || 'Unknown error'); } return data.data; } catch (error) { console.error('API Error:', error); throw error; } } // 使用统一的错误处理 fetchApi('/api/v1/users') .then(data => console.log(data)) .catch(error => console.error(error)); 

分页和过滤

// 分页 fetch('/api/v1/users?page=1&limit=10') .then(response => response.json()) .then(data => console.log(data)); // 过滤 fetch('/api/v1/users?name=John&email=example.com') .then(response => response.json()) .then(data => console.log(data)); // 排序 fetch('/api/v1/users?sort=name&order=asc') .then(response => response.json()) .then(data => console.log(data)); 

API版本控制

// 使用URL路径进行版本控制 fetch('/api/v1/users') .then(response => response.json()) .then(data => console.log(data)); // 或使用请求头进行版本控制 fetch('/api/users', { headers: { 'Accept': 'application/vnd.example.v1+json' } }) .then(response => response.json()) .then(data => console.log(data)); 

API客户端封装

// api.js - 封装API客户端 class ApiClient { constructor(baseUrl) { this.baseUrl = baseUrl; } async request(endpoint, options = {}) { const url = `${this.baseUrl}${endpoint}`; const defaultOptions = { headers: { 'Content-Type': 'application/json' } }; const mergedOptions = { ...defaultOptions, ...options, headers: { ...defaultOptions.headers, ...options.headers } }; try { const response = await fetch(url, mergedOptions); const data = await response.json(); if (!data.success) { throw new Error(data.error?.message || 'Unknown error'); } return data.data; } catch (error) { console.error('API Error:', error); throw error; } } // 用户相关API getUsers(params = {}) { const queryString = new URLSearchParams(params).toString(); return this.request(`/users${queryString ? `?${queryString}` : ''}`); } getUser(id) { return this.request(`/users/${id}`); } createUser(user) { return this.request('/users', { method: 'POST', body: JSON.stringify(user) }); } updateUser(id, user) { return this.request(`/users/${id}`, { method: 'PUT', body: JSON.stringify(user) }); } deleteUser(id) { return this.request(`/users/${id}`, { method: 'DELETE' }); } } // 使用API客户端 const api = new ApiClient('https://api.example.com/v1'); // 获取用户列表 api.getUsers({ page: 1, limit: 10 }) .then(users => console.log(users)) .catch(error => console.error(error)); // 创建用户 api.createUser({ name: 'John', email: '[email protected]' }) .then(user => console.log(user)) .catch(error => console.error(error)); 

毒舌点评

API设计确实很重要,但我见过太多前端开发者把API设计的责任完全推给后端,自己只负责调用。你以为后端会自动设计出好的API?别做梦了!后端开发者可能不了解前端的需求,设计出来的API可能并不适合前端使用。

想象一下,当后端设计了一个返回格式不一致的API,前端需要写大量的代码来处理不同的返回格式,这会大大增加前端的开发工作量。

还有那些没有分页和过滤功能的API,当数据量很大时,前端会收到大量数据,导致应用变得很慢。

所以,前端开发者应该积极参与API设计,与后端开发者沟通,确保API设计符合前端的需求。

当然,API设计也不是越复杂越好。过于复杂的API设计会增加后端的开发成本,也会增加前端的学习成本。

最后,记住一句话:API设计的目的是为了方便使用,而不是为了炫技。如果你的API设计让使用者感到困惑,那你就失败了。

Read more

FASTLIVO2算法解析与实战(一):SLAM领域的新标杆,如何让机器人“看得更清、跑得更稳”

FASTLIVO2算法解析与实战(一):SLAM领域的新标杆,如何让机器人“看得更清、跑得更稳”

FASTLIVO2系统概述 1. 背景介绍 1.1 传感器特性 FASTLIVO2 系统融合了三种互补的传感器:激光雷达(LiDAR)、相机(Camera)和惯性测量单元(IMU)。它们在感知方式、输出数据和环境适应性上各具特点,通过融合实现优势互补。 特性激光雷达(LiDAR)相机(Camera)IMU工作方式主动发射激光,通过反射测量距离和方位被动接收环境光,捕捉 2D 图像信息主动测量自身运动感知内容环境几何结构(深度、形状、表面)环境纹理与颜色(语义、细节、动态物体)自身运动状态(姿态、速度、加速度)数据输出3D 点云(精确深度)2D 像素矩阵(RGB 或灰度)6 自由度运动参数优势- 直接深度测量,精度高- 不受光照影响- 在结构化环境中鲁棒-

【论文阅读】DSRL: Steering Your Diffusion Policy with Latent Space Reinforcement Learning

【论文阅读】Steering Your Diffusion Policy with Latent Space Reinforcement Learning * 1 团队与发表时间 * 2. 问题背景与核心思路 * 3. 具体做法 * 3.1 模型设计 * 3.2 Loss 设计 * 3.3 数据设计 * 4 实验效果 * 5 结论 * 6 扩散模型进行RL的方案 * 6.1 纯离线设置 (Purely Offline Setting) * 6.2 在线设置 (Online Setting) * 6.3 残差策略 (Residual Policy) 1 团队与发表时间

【XR技术介绍】一文理清 OpenVR、OpenXR、SteamVR 与各厂商 SDK等容易混淆的概念

【XR技术介绍】一文理清 OpenVR、OpenXR、SteamVR 与各厂商 SDK等容易混淆的概念

在虚拟现实、混合现实开发领域,OpenVR、OpenXR、SteamVR 以及各硬件厂商专属 SDK,是我们经常遇到的东西。是不是傻傻分不清楚,容易混淆它们的定位、归属、功能与适用场景,这些到底是标准协议?还是插件?还是开发工具包?本文将从概念定义、制定 / 开发主体、核心职能、技术关系、适用场景多个维度,系统拆解它们差异与关联,帮你建立完整的认知框架。 一、基础概念总览:先分清 “标准” 与 “实现” 在正式拆解前,先建立一个核心认知:OpenXR 与 OpenVR 是行业标准 / 接口规范,属于抽象的技术协议;SteamVR 是基于标准的 runtime 运行时实现,是可落地的软件平台;硬件厂商 SDK 则是设备专属的底层驱动与开发工具包,是硬件直连的桥梁。标准解决 “兼容统一” 问题,运行时与

DAY4 基于 OpenClaw + 飞书开放平台实现 AI 新闻推送机器人

DAY4 基于 OpenClaw + 飞书开放平台实现 AI 新闻推送机器人

DAY4 基于 OpenClaw + 飞书开放平台实现 AI 新闻推送机器人 目录 DAY4 基于 OpenClaw + 飞书开放平台实现 AI 新闻推送机器人 前  言 1 环境准备 1.1 华为云开发环境 1.2 ModelArts 代金券与模型服务 1.3 启动 OpenClaw 网关 2 飞书开放平台配置 2.1 创建企业自建应用 2.2 添加机器人能力 2.3 配置应用权限 2.4 发布应用版本 3 OpenClaw 与飞书集成 3.1 配置 OpenClaw