API交互：前后端分离开发实战指南

一、简单实战：计算机

1. 核心概念：前后端交互接口

接口（API）是前后端分离开发中，客户端与服务器约定的 HTTP 请求 / 响应规则，类似 "应用程序的操作说明书"（接口文档）。
开发前需约定接口，双方按文档开发；接口文档通常由服务提供方编写，变更需同步对方。

约定维度	具体例子（加法接口）	为什么要约定？
请求路径	`calc/sum`（不是随便写的`add/num`）	前端知道往哪个 "地址" 发请求
请求方式	GET/POST（不是前端想发 GET、后端只接 POST）	确保请求方式匹配，避免 405 错误
参数名 + 类型	`num1`（Integer）、`num2`（Integer）	前端传对参数名 / 类型，后端能解析
参数是否必传	`num1`/`num2`都必传（不是可选）	避免前端漏传导致后端计算出错
响应格式	`text/html`（不是 JSON/XML）	前端知道怎么解析返回的内容
响应内容规则	"计算机计算结果：X"（不是只返回数字 X）	前端能按固定格式展示结果
异常响应	比如参数非数字时返回 "参数错误"	前端知道如何处理异常场景

简单说：约定的是 "前端怎么发请求、后端怎么返回响应" 的全流程规则，而非只约定变量 / 方法名。

（2）"方法名字" 不是后端内部的方法名，是接口的 "对外标识"

后端内部写的方法名（比如 Java 里的public int addNumber(int a, int b)）属于 "后端内部实现"，前端完全不用管；
双方约定的是接口的对外路径 / 标识 （比如calc/sum），而非后端代码里的方法名 ------ 哪怕后端把内部方法名改成sumTwoNum，只要对外的calc/sum路径不变，前端完全不用改代码。

（3）"不需要一起使用的就不用管"------ 这个边界要明确

✅ 后端内部的逻辑：比如计算加法时要不要加日志、要不要校验参数（只要最终按约定返回）、变量命名（比如后端用n1代替num1）------ 前端完全不用管；
✅ 前端内部的逻辑：比如输入框的样式、点击按钮的动画、拿到结果后怎么渲染 ------ 后端完全不用管；
❌ 只要是 "跨前后端传输的内容"，哪怕是 "异常码"（比如后端返回code: 500表示计算失败），都必须约定 ------ 否则前端拿到500不知道是什么意思。

1.1 用一句话总结

前后端约定 "数据交互的规则"（请求地址 / 方式 / 参数、响应格式 / 内容 / 异常），前端按规则发请求、后端按规则处理并返回响应；双方各自内部的代码实现（方法名、变量名、业务逻辑细节），只要不违反约定，都可以自由调整，不用互相干涉。

2. 加法计算器案例解析

2.1接口定义

2.2请求参数

2.3响应数据

总结+注意事项：

✅ 接口定义的核心是「前端怎么找到后端 + 怎么传参 + 知道后端会返回什么」，而非关注后端 "具体怎么实现"；
✅ 路径（URL）+ 请求方式（GET/POST）= 前端定位后端功能的 "唯一标识"；
✅ 接口描述 = 这个功能的用途；请求参数 = 传参规则；返回结果 = 响应规则；
✅ 后端具体实现（比如用 Java/Python/Go 写、用什么算法、内部调用了哪些工具类），前端完全不用管。
✅ 路径绑定的是 "要实现的功能 "，不是 "后端的方法名。(接口定义里的路径（如user/login）是 "对外暴露的功能地址 "------ 哪怕后端把方法名改成verifyUser()，只要user/login这个路径不变、规则不变，前端完全不用改代码。)

接口定义里的返回规则，不能只写 "成功返回什么"，还要约定 "失败返回什么"：

比如登录接口：

✅ 成功：返回 "登录成功"+ 用户信息（JSON 格式）+ 状态码 200；
✅ 失败：返回 "账号密码错误"+ 错误码（如 1001）+ 状态码 400；如果只约定 "成功的返回形式"，前端遇到异常时会不知道怎么处理（比如拿到空数据、乱码，没法判断是 "没传参" 还是 "密码错"）。

"请求参数"→ 不止 "参数要求"，还要约定 "参数规则"

请求参数的定义，除了 "要传什么参数"，还要明确：

参数类型（比如username是字符串、age是整数）；
是否必传（比如登录的username必传，rememberMe可选）；
格式约束（比如password长度 6-16 位、phone符合手机号格式）；这些规则前端要遵守（比如前端校验手机号格式，避免无效请求），后端也要校验（防止恶意传参），但 "怎么校验"（前端用正则、后端用注解）各自实现，不用约定。

接口定义还需约定 "响应格式类型"

比如返回结果是text/html（加法案例）、application/json（登录案例）、application/xml等 ------ 前端要知道用什么方式解析（比如 JSON 要转对象，HTML 可直接渲染），这也是接口定义的必要项。

2.4服务器代码

2.5前端代码

2.6运行测试

二、lombok

2.1lombok介绍

通过注解简化 Java 代码编写，在编译阶段自动生成重复代码（如 getter/setter、构造方法等），减少冗余。

2.2原理解释

1. Lombok 的工作阶段

Lombok 是编译期代码生成工具 ：在 Java 源码编译为字节码（.class 文件）的过程中，Lombok 会识别类上的注解（如@Data），自动生成对应的代码（如 getter/setter、构造方法等），最终生成的字节码包含这些完整代码。

2. 反编译的作用

通过 IDEA 对.class文件反编译（将字节码转换为可读的 Java 代码），可以观察到：添加@Data注解的类，反编译后的代码中已包含自动生成的方法（如getId()、getName()等），证明 Lombok 的代码生成是在编译阶段完成的。

3. Lombok 对 Java 运行流程的影响

原生 Java 流程 ：.java源码 → 编译 → .class字节码 → JVM 加载运行
引入 Lombok 后 ：.java源码 + Lombok → 编译（生成包含自动代码的字节码） → .class字节码 → JVM 加载运行

简言之，Lombok 在编译环节介入，替开发者生成重复代码，而 JVM 运行时使用的仍是完整的字节码文件，不感知 Lombok 的存在。

@Data等价于（@Getter+@Setter+@ToString+@EqualsAndHashCode+@RequiredArgsConstructor+@NoArgsConstructor）

注解	作用
`@Getter`	自动生成 getter 方法
`@Setter`	自动生成 setter 方法
`@ToString`	自动生成 toString 方法
`@EqualsAndHashCode`	自动生成 equals 和 hashCode 方法
`@NoArgsConstructor`	自动生成无参构造方法
`@AllArgsConstructor`	自动生成全属性构造方法
`@NonNull`	限制属性不可为 null
`@RequiredArgsConstructor`	生成包含`final`或`@NonNull`属性的构造方法

3.通过 EditStarters 插件快速引入 Lombok 依赖

安装 EditStarters 插件 在 IDEA 的Settings → Plugins中搜索 "EditStarters" 并安装，重启 IDEA 使插件生效。
通过插件添加依赖
- 在pom.xml文件上右键，选择Generate → Edit Starters；
- 在弹出的配置界面中，选择Developer Tools分类，勾选 "Lombok"，点击 "Add" 后确认，插件会自动将 Lombok 的依赖坐标写入pom.xml。

3.1插件作用

EditStarters 是针对 Spring Boot 项目的依赖管理插件，可通过可视化界面快速选择并添加依赖（无需手动查找依赖坐标），简化了 Maven/Gradle 的依赖配置流程。

3.2注意事项

该插件仅支持 Spring Boot 生态内的常用依赖（如 Lombok、Spring Web 等）；若需添加非 Spring Boot 相关依赖，仍需手动从 Maven 仓库查找坐标并写入配置文件。