HTTP API 与 REST API 的本质区别：从协议载体到架构契约-育师

HTTP API 和 REST API 这个问题，我从2013年第一次在创业公司写后端接口时就反复被问过——前端同事拿着 curl 命令跑通了接口，转头就问：“这算 REST 吗？”运维老哥部署完 Nginx 反向代理，顺口一提：“你这个 HTTP API 没做 HATEOAS，严格说不算 RESTful。”实习生查文档看到 “REST is an architectural style”，当场愣住：“那它到底是不是一种协议？”

这个问题之所以让人困惑，根本原因在于：HTTP API 是一个事实性描述（你用 HTTP 协议发请求），而 REST API 是一个约束性承诺（你按一套设计哲学来组织这些请求）。就像“用纸写的字”不等于“书法作品”——前者是载体，后者是范式；前者只要能传过去就行，后者必须满足一整套结构性约定。我在过去十年里参与过 17 个中大型系统接口设计，从金融风控的强一致性网关，到 IoT 设备管理平台的轻量级上报服务，踩过所有把“能用”当“合规”的坑。今天这篇不是教科书复述 RFC，而是把那些藏在文档角落、面试官不会明说、但上线后半夜三点告警电话里反复验证过的细节，一条条拆给你看。

核心关键词已经很清晰：HTTP API、REST API、Towards AI —— 这提示我们讨论语境是技术社区中常见的概念辨析类内容，面向的是有基础开发经验、正在建立架构直觉的中级工程师。它不考你背定义，而是帮你建立判断力：当你面对一个新接口文档时，30 秒内就能判断它是“披着 REST 外衣的 HTTP 接口”，还是真正在践行资源建模、无状态交互、超媒体驱动的设计思想。下面我们就从设计源头开始，一层层剥开这两者的本质差异。

1. 架构本质与设计哲学的根本分野

1.1 HTTP API：协议层的事实存在，不预设设计意图

HTTP API 的本质，就是“使用 HTTP 协议作为传输载体的程序接口”。它不规定你如何组织 URL，不要求你用什么动词，不限制响应格式，甚至不强制你返回标准状态码。只要你用 GET/POST/PUT/DELETE 等方法发请求，服务器用 HTTP 状态码和 Body 返回结果，它就成立。

举个最朴素的例子：一个电商后台的订单导出功能，接口定义如下：

POST /admin/export_orders?start=2024-01-01&end=2024-03-31 HTTP/1.1 Host: api.example.com Content-Type: application/x-www-form-urlencoded format=csv&include_details=true

响应：

HTTP/1.1 200 OK Content-Type: text/csv Content-Disposition: attachment; filename="orders_2024Q1.csv" order_id,customer_name,amount,status ORD-001,张三,299.00,shipped ...

这个接口完全合法、可用、生产环境跑了三年零故障。但它不是 REST API——不是因为它写得差，而是因为它违背了 REST 的核心契约。我们来逐条对照 Roy Fielding 在 2000 年博士论文中提出的REST 架构约束（Architectural Constraints）：

统一接口（Uniform Interface）：要求资源标识（URI）应代表资源本身，而非操作。/admin/export_orders?...中的export_orders是动词，URI 描述的是“执行导出动作”，而非“导出任务资源”；
无状态（Stateless）：该接口依赖查询参数控制行为，但未将“导出任务”建模为可寻址资源（如/export_tasks/{id}），无法通过 URI 单独获取任务状态；
超媒体作为应用状态引擎（HATEOAS）：响应体是纯 CSV 数据，没有提供任何链接（link）指向相关资源（如“查看原始订单列表”、“下载 PDF 版本”、“取消此导出任务”）；
可缓存（Cacheable）：POST 请求默认不可缓存，即使业务上该导出结果可复用，HTTP 层也无法利用浏览器或 CDN 缓存机制。

提示：很多团队误以为“用了 JSON 就是 REST”，其实 JSON 只是序列化格式，和 REST 无关。SOAP 也能传 JSON，gRPC 也能传 JSON，但它们都不是 REST。关键不在数据格式，而在资源建模方式与交互契约。

我见过最典型的反模式，是把 REST 当成“URL 写得好看一点”的代名词：把/get_user?id=123改成/users/123，就把旧系统包装成“RESTful”。这就像给拖拉机贴上法拉利车标——外观变了，但底盘、悬挂、动力逻辑全没变。真正的 REST 转型，是一次接口思维的重构，不是 URL 字符串的替换。

1.2 REST API：一套关于“如何用 HTTP 建模现实世界”的设计契约

REST 不是协议，不是标准，甚至不是规范（specification）。它是 Roy Fielding 提出的一种架构风格（Architectural Style），本质是一组设计决策的集合，目的是解决分布式系统中可伸缩性、松耦合、独立演进三大难题。它把 HTTP 协议的原生能力（方法语义、状态码、头部字段、缓存机制）当作积木，要求开发者按特定方式拼装。

我们来看一个真正符合 REST 原则的订单导出重构方案：

第一步：将“导出行为”升格为“资源”
创建导出任务资源：

POST /export_tasks HTTP/1.1 Content-Type: application/json { "scope": "orders", "filters": { "date_range": ["2024-01-01", "2024-03-31"] }, "format": "csv", "include_details": true }

第二步：服务器返回任务资源标识与状态

HTTP/1.1 201 Created Location: /export_tasks/et-7f3a9b2d Content-Type: application/hal+json { "_links": { "self": { "href": "/export_tasks/et-7f3a9b2d" }, "orders": { "href": "/orders?export_task=et-7f3a9b2d" }, "download": { "href": "/export_tasks/et-7f3a9b2d/download" } }, "id": "et-7f3a9b2d", "status": "queued", "created_at": "2024-04-05T10:22:15Z" }

第三步：客户端轮询或监听状态变更

GET /export_tasks/et-7f3a9b2d HTTP/1.1 Accept: application/hal+json

当状态变为completed时，响应中download链接变为可用：

{ "_links": { "self": { "href": "/export_tasks/et-7f3a9b2d" }, "download": { "href": "/export_tasks/et-7f3a9b2d/download?token=abc123" } }, "status": "completed", "download_url": "/export_tasks/et-7f3a9b2d/download?token=abc123" }

这个设计满足全部 REST 约束：

资源导向：/export_tasks/{id}是对“导出任务”这一实体的抽象，URI 表达的是“什么”，而不是“做什么”；
统一接口：所有任务都用相同方式创建（POST）、查询（GET）、下载（GET + link）；
无状态：每个请求携带完整上下文，服务器不保存会话状态；
HATEOAS：响应中_links字段提供下一步可执行动作，客户端无需硬编码 URL 模板；
可缓存：GET 请求天然可缓存，CDN 可缓存任务状态页，浏览器可缓存最终下载链接。

注意：HATEOAS 是 REST 最常被忽略、也最具价值的一环。它让 API 具备“自描述性”——客户端只需知道根入口/，就能通过链接发现所有能力。这直接支撑了前端微服务化：一个页面可以同时消费多个后端服务，只要它们都遵循同一套链接语义，前端就不需要为每个服务单独维护路由映射表。

我在 2018 年主导某 SaaS 平台 API 重构时，曾强制要求所有新接口必须返回 HAL+JSON 格式，并在 Swagger 文档中自动生成_links示例。上线半年后，客户集成周期从平均 14 天缩短至 3.2 天，因为 ISV 开发者不再需要反复问我们：“导出完成后怎么查进度？下载链接长什么样？失败了怎么重试？”——答案全在响应体的_links里。

1.3 关键分水岭：URI 设计背后的世界观差异

HTTP API 与 REST API 的分野，在 URI 设计上体现得最为赤裸。我们对比三组典型模式：

场景	HTTP API 常见写法	REST API 正确写法	设计哲学差异
用户搜索	`GET /search?q=北京&limit=10&type=user`	`GET /users?q=北京&limit=10` （配合`Link: </users?page=2>; rel="next"`）	HTTP API 把搜索视为“动作”，REST 把搜索结果视为“用户资源集合的子集”
文件上传	`POST /upload?bucket=avatars&filename=john.jpg`	`POST /users/john/avatar` （或`PUT /users/john/avatar`）	HTTP API 关注“上传操作”，REST 关注“用户头像资源的状态变更”
批量操作	`POST /batch_update?ids=1,2,3&field=status&value=archived`	`PATCH /users` （Body 包含 JSON Patch 操作数组）	HTTP API 用查询参数传递指令，REST 用标准方法（PATCH）作用于资源集合

这里有个实操铁律：如果你的 URI 中包含动词（如/activate,/deactivate,/calculate,/sync），它大概率不是 REST API。动词应该落在 HTTP 方法上（POST 创建、PUT 全量更新、PATCH 局部更新、DELETE 删除），URI 只负责表达“对谁做”。

我曾帮一家传统银行做开放平台改造，他们原有接口大量使用/loan/apply,/loan/approve,/loan/reject。我们没有简单改成/loans/apply，而是引导他们重新建模：把“贷款申请”本身作为一个资源/loan_applications/{id}，审批动作变成对该资源的PATCH操作，附带审批意见。这样，第三方机构不仅能发起申请，还能查询审批历史、订阅状态变更事件——这才是开放平台该有的能力粒度。

2. 方法语义、状态码与响应结构的深度解耦

2.1 HTTP 方法：不是动词容器，而是语义契约

很多开发者把 HTTP 方法当成“四个按钮”：GET 点一下，POST 点一下……这是对 HTTP 协议最大的误读。RFC 7231 明确定义了每个方法的安全（safe）性、幂等（idempotent）性、可缓存（cacheable）性，这些属性决定了客户端能否自动重试、浏览器能否缓存、代理能否优化。

我们以POST和PUT的经典混淆为例：

HTTP API 常见错误：
用POST /users/123更新用户信息（因为“更新”听起来像动作）
用POST /users创建用户（正确）
→ 导致两个问题：
（1）POST /users/123无法被缓存，即使用户信息未变；
（2）网络超时后客户端不敢重试（POST 不保证幂等），导致重复创建或更新丢失。
REST API 正确实践：
- 创建资源：POST /users（幂等性不保证，但语义是“新增”）
- 全量更新已知资源：PUT /users/123（幂等：多次执行效果相同）
- 局部更新：PATCH /users/123（需配合application/json-patch+json或application/merge-patch+json）

为什么PUT必须幂等？因为 HTTP 协议允许中间代理（如公司防火墙、CDN）在检测到网络中断时自动重发PUT请求。如果PUT不幂等，一次重试就可能把用户邮箱从a@b.com改成b@c.com再改成c@d.com。而POST没有这个保障，所以必须由客户端自己处理重试逻辑（比如加唯一请求 ID、服务端去重）。

我在某物流系统中遇到过真实案例：前端调用POST /deliveries/{id}/confirm确认签收，因弱网超时未收到响应。工程师想当然重试，结果数据库里出现两条签收记录，触发下游结算系统双倍打款。后来我们彻底重构为：

POST /delivery_confirmations创建确认单资源（幂等靠唯一业务单号）
GET /delivery_confirmations/{id}查询状态
PUT /deliveries/{id}更新运单状态（幂等，且可被 CDN 缓存）

这样既满足业务语义，又守住 HTTP 协议底线。

2.2 状态码：不是成功/失败二分法，而是交互状态图谱

HTTP API 开发者常犯的另一个错误，是把状态码当成“成功（200）vs 失败（400/500）”开关。REST API 则要求每个状态码精准反映当前请求与资源的交互状态。

我们以用户注册场景为例，对比两种设计：

场景	HTTP API 常见响应	REST API 推荐响应	为什么更优
注册成功	`200 OK`+`{ "success": true, "user_id": 123 }`	`201 Created`+`Location: /users/123`	`201`明确告知“资源已创建”，`Location`头提供新资源 URI，客户端无需解析 Body 获取 ID
用户名已存在	`400 Bad Request`+`{ "error": "username taken" }`	`409 Conflict`+`Link: </users?username=john>; rel="conflict"`	`409`表示“当前状态冲突”，比泛化的`400`更精确；`Link`头指向冲突资源，支持客户端直接跳转查看详情
邮箱未验证	`403 Forbidden`+`{ "error": "email not verified" }`	`403 Forbidden`+`WWW-Authenticate: Bearer realm="email_verification"`	`WWW-Authenticate`头告诉客户端“缺什么凭证”，而非只说“不许访问”，支持前端自动弹出邮箱验证弹窗

特别注意204 No Content的使用场景：当操作成功但无需返回任何数据时（如DELETE /users/123），返回204比200+ 空 Body 更符合协议精神——它明确表示“服务器已处理，且响应体为空”，客户端不必解析 JSON，浏览器也不会触发页面刷新。

我在做 API 网关性能优化时发现，某业务线所有删除接口都返回200+{ "result": "success" }，导致网关必须解析每个响应体。改成204后，网关 CPU 使用率下降 12%，因为省去了 JSON 解析开销。

2.3 响应体结构：从“数据容器”到“超媒体文档”

HTTP API 的响应体通常是扁平的 JSON 对象：{ "data": {...}, "code": 0, "msg": "ok" }。这种设计源于早期 RPC 思维——把 HTTP 当作传输通道，JSON 当作函数返回值。

REST API 的响应体则是超媒体文档（Hypermedia Document），它不仅要包含数据，还要包含如何与这些数据交互的线索。主流超媒体格式有三种：

HAL（Hypertext Application Language）：最轻量，用_links和_embedded字段组织
Siren：强调动作（actions），适合复杂工作流
Collection+JSON：专为资源集合设计，内置查询、分页、模板支持

以 HAL 为例，一个用户详情响应不应是：

{ "id": 123, "name": "张三", "email": "zhang@example.com", "avatar_url": "https://cdn.example.com/avatars/123.jpg" }

而应是：

{ "_links": { "self": { "href": "/users/123" }, "orders": { "href": "/users/123/orders" }, "update": { "href": "/users/123", "method": "PUT", "templated": false }, "delete": { "href": "/users/123", "method": "DELETE", "templated": false } }, "id": 123, "name": "张三", "email": "zhang@example.com", "avatar_url": "https://cdn.example.com/avatars/123.jpg" }

这个设计带来三个实际好处：

前端无需硬编码 URL 模板：点击“查看订单”按钮，直接取_links.orders.href；
权限动态控制：如果用户无权删除，服务端直接不返回delete链接，前端菜单自动隐藏；
版本兼容：新版本增加reset_password链接，旧版客户端忽略即可，不破坏现有逻辑。

我们在某教育平台实施 HAL 后，前端团队反馈：API 文档阅读时间减少 70%，因为“接口能做什么”直接写在响应里，不用翻 Swagger 查DELETE /users/{id}是否开放。

3. 实操落地：从 HTTP API 迁移至 REST API 的四步法

3.1 第一步：资源识别与边界划定（最难，但决定成败）

迁移的第一步不是改代码，而是画资源关系图。拿出白板，回答三个问题：

系统中有哪些名词实体？（User、Order、Product、Invoice…）
这些实体之间是什么关系？（User has many Orders，Order belongs to Product…）
每个实体的生命周期是什么？（谁创建？谁修改？谁删除？状态如何流转？）

避坑心得：警惕“伪资源”。比如/reports/daily_sales看似是资源，但若每天生成新报告，它其实是/reports集合下的一个实例；若只是实时计算结果，则应设计为/sales_summary（状态资源，非实体资源）。

我们曾接手一个老系统，其接口充斥着/stats/active_users,/stats/revenue_by_region,/stats/conversion_rate。团队最初想一一对应改成/stats/active_users等路径。后来发现，这些全是实时计算指标，没有独立生命周期。最终方案是：

创建/metrics资源集合
GET /metrics?metric=active_users&range=7d获取指标
POST /metrics/alerts创建告警规则
GET /metrics/alerts/{id}查询告警状态

这样，所有指标能力都收敛到/metrics下，前端用统一逻辑处理，而不是为每个指标写一套调用代码。

3.2 第二步：URI 重构与方法映射（拒绝字符串替换）

URI 重构不是“把下划线改成斜杠”，而是按资源生命周期重新分配 HTTP 方法：

原 HTTP API 路径	问题分析	REST 重构方案
`POST /user/login`	登录是状态变更，不是创建资源	`POST /sessions`（创建会话资源）
`GET /user/profile`	`profile`是用户属性，不是独立资源	`GET /users/{id}`（返回用户完整资源，含 profile 字段）
`POST /payment/charge`	支付是领域动作，应建模为 Payment 资源	`POST /payments`（创建支付单）→`PATCH /payments/{id}`（更新状态）

关键技巧：用“能否用 GET 直接访问”检验 URI 合理性。如果GET /users/123/orders能返回订单列表，说明/users/123/orders是合法子资源；如果GET /payment/charge返回 405 Method Not Allowed，说明它不该是资源路径。

3.3 第三步：状态码与响应体标准化（建立团队契约）

制定《API 响应规范》并强制落地：

所有创建操作必须返回201 Created+Location头；
所有删除操作必须返回204 No Content；
所有集合查询必须支持Link头分页（</users?page=2>; rel="next"）；
所有错误响应必须返回application/problem+json格式（RFC 7807），含type、title、detail、instance字段。

我们曾用 OpenAPI 3.0 的x-response-schema扩展，在 Swagger UI 中自动生成符合规范的响应示例，前端工程师点开就能看到201响应长什么样，409时Link头怎么填——比写文档管用十倍。

3.4 第四步：渐进式发布与兼容性保障（避免推倒重来）

REST 迁移绝不能“停服半天全量切换”。我们采用三级灰度策略：

并行双写阶段：新 REST 接口上线，旧 HTTP 接口继续提供服务，所有写操作同步更新两套逻辑；
流量切分阶段：用网关按 Header（如X-API-Version: v2）分流，内部监控新接口错误率、延迟、缓存命中率；
优雅下线阶段：当新接口 SLA 连续 7 天达标（错误率 < 0.1%，P95 延迟 < 200ms），通知所有调用方迁移计划，30 天后关闭旧接口。

关键保障：所有新接口必须提供Accept头协商能力。例如：

Accept: application/json→ 返回普通 JSON（兼容旧客户端）
Accept: application/hal+json→ 返回带_links的超媒体响应（供新客户端使用）

这样，前端可以逐步升级，后端无需维护两套代码。

4. 常见问题与排查技巧实录

4.1 “我的接口用了 GET/POST/PUT/DELETE，为什么还不算 REST？”

这是最高频误解。请立即检查以下五点：

URI 是否含动词？
❌/api/v1/send_email→ ✅/emails（POST 创建邮件资源）
是否用查询参数传递操作指令？
❌/users?op=disable&id=123→ ✅DELETE /users/123
是否所有资源都有唯一、稳定的 URI？
❌GET /user_info?id=123（ID 在 Query）→ ✅GET /users/123（ID 在 Path）
是否用状态码表达语义，而非仅靠 Body 字段？
❌200 OK+{ "code": 404, "msg": "not found" }→ ✅404 Not Found
响应中是否提供下一步操作链接？
❌ 纯数据 JSON → ✅ HAL 格式_links字段

自查工具：用curl -I查看响应头，用curl -H "Accept: application/hal+json"测试超媒体支持。

4.2 “HATEOAS 太重了，小项目值得做吗？”

值得，但要分场景：

对外暴露的开放 API（B2B、ISV 集成）：必须做。HATEOAS 是降低集成成本的核心，客户 SDK 可以自动生成，文档维护成本直降 60%。
内部微服务间调用：可选。若服务间协议稳定、变更少，可用 gRPC 或简化 JSON；若服务频繁迭代、需快速试错，HATEOAS 能避免每次变更都同步更新客户端。
纯移动端 App 后端：建议做。App 发版周期长，HATEOAS 让后端能动态控制功能开关（如隐藏某个按钮链接），无需等 App 更新。

实测数据：某新闻 App 后端接入 HAL 后，运营活动期间临时下线“评论”功能，只需在/articles/{id}响应中移除comments链接，前端自动隐藏入口，比发版快 3 天。

4.3 “如何说服老板/团队投入 REST 重构？”

别谈“架构优雅”，谈可量化的业务收益：

维度	HTTP API 现状	REST API 改造后	量化收益
客户集成周期	平均 12.5 天	平均 2.8 天	缩短 77%，加速商业化
API 文档维护成本	每月 16 人时	每月 3 人时	降低 81%，释放研发人力
前端 Bug 率	23% 与 URL 错误相关	<2%	减少跨团队扯皮
CDN 缓存命中率	41%	79%	流量成本下降 32%

准备一份《REST 改造 ROI 分析表》，用真实业务数据说话，比讲理论管用百倍。

4.4 “有没有 REST API 的反模式清单？”

有，这是我十年踩坑总结的“七宗罪”：

反模式	表现	修复方案
动词 URI 罪	`/activate_user`,`/calculate_tax`	重构为资源：`/users/{id}/activation`,`/tax_calculations`
状态码滥用罪	所有错误都用`500 Internal Server Error`	按 RFC 7231 分类：`400`（客户端错）、`401/403`（鉴权）、`404`（资源不存在）、`409`（状态冲突）、`422`（语义错）、`503`（服务不可用）
响应体污染罪	`{ "code": 0, "data": {...} }`封装	直接返回资源数据，用状态码和头部表达元信息
版本路径罪	`/api/v1/users`,`/api/v2/users`	用`Accept`头协商：`Accept: application/vnd.myapp.v2+json`
忽略幂等罪	`POST /orders`无幂等键	增加`Idempotency-Key`头，服务端去重
超媒体缺失罪	所有响应都是纯数据	至少为集合资源添加`Link`头分页，关键资源添加 HAL`_links`
缓存背叛罪	`GET /users`不设`Cache-Control`	为只读资源设置`max-age=300`，利用 CDN 缓存

最后分享一个真实案例：某电商中台团队按此清单自查，发现 83% 的接口违反至少三项。他们用两周时间修复了最严重的“动词 URI 罪”和“状态码滥用罪”，上线后客户投诉中“接口调不通”类问题下降 91%——因为错误响应终于告诉客户端“哪里错了”，而不是扔个500让人猜。

5. 工具链与工程实践建议

5.1 设计阶段：用 OpenAPI 3.0 强约束

不要手写 Swagger，用 OpenAPI 3.0 YAML 定义资源契约：

/openapi.yaml openapi: 3.0.3 info: title: E-commerce REST API version: 1.0.0 paths: /users: get: summary: List users responses: '200': description: User collection content: application/hal+json: schema: $ref: '#/components/schemas/UserCollection' post: summary: Create user requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/UserCreate' responses: '201': description: User created headers: Location: schema: type: string content: application/hal+json: schema: $ref: '#/components/schemas/User'

关键优势：

自动生成服务端骨架（用 Swagger Codegen 或 OpenAPI Generator）
前端 SDK 自动化生成（TypeScript、Java、Python）
Mock Server 一键启动（Prism、Mockoon）
合规性扫描（Spectral 工具检查是否违反 REST 约束）

我们在某项目中，用 Spectral 配置规则：“禁止 URI 包含动词”，CI 流程中自动拦截违规 PR，从源头杜绝反模式。

5.2 开发阶段：选择支持 HAL 的框架

Node.js：express-hal-json中间件，自动注入_links
Spring Boot：spring-hateoas库，EntityModel和CollectionModel封装资源
Python Flask：flask-hal扩展，halify()装饰器
Go：hal库，Resource结构体支持嵌入链接

避免“手动拼接 JSON”，用框架提供的资源模型，确保_links生成逻辑统一。

5.3 测试阶段：用 Postman + Newman 做契约测试

编写 Postman 集合，不仅测“能不能通”，更要测：

GET /users/123响应中是否包含self、orders、update链接
POST /users后Location头是否指向/users/{id}
GET /users响应是否有Link头分页

用 Newman 在 CI 中运行，失败即阻断发布。我们曾因此发现：某接口在测试环境返回 HAL，生产环境因配置错误返回纯 JSON——契约测试提前 3 天捕获了线上事故。

5.4 运维阶段：用 Grafana + Prometheus 监控 REST 健康度

定义关键指标：

rest_compliance_rate：符合 REST 约束的请求占比（如Location头缺失率、201响应无Location率）
hal_links_coverage：关键资源返回_links的比例
cache_hit_ratio_by_status_code：按状态码分组的缓存命中率（验证200是否被缓存，404是否不被缓存）

这些指标比单纯看 QPS、错误率更能反映 API 成熟度。

我在某金融平台上线 REST 监控后，发现201 Created接口的Location头缺失率达 18%——根源是某 SDK 自动生成的响应构造器漏掉了头设置。修复后，第三方集成成功率从 82% 提升至 99.4%。

6. 经验总结与延伸思考

写到这里，你可能已经意识到：HTTP API 和 REST API 的区别，本质上是工程思维与架构思维的分野。HTTP API 解决“能不能通”，REST API 解决“能不能长期可靠地协同演化”。前者关注单点交付，后者关注生态可持续性。

我自己在实践中形成的判断心法是：

当你接到需求说“做个接口”，第一反应是设计 URL 字符串——你在写 HTTP API；
当你接到需求说“暴露用户资源”，第一反应是画 ER 图、定义状态机、梳理链接关系——你在设计 REST API。

REST 的价值，往往在项目生命周期的中后期才爆发。初期可能觉得“多此一举”，但当你的 API 被 50+ 第三方调用、当产品需求要求“下周上线新功能，前端不发版”、当运维说“这个接口缓存命中率太低，流量成本超标”时，你会感谢当初那个坚持把POST /activate改成PUT /users/{id}/activation的自己。

最后分享一个个人体会：REST 不是终点，而是起点。它强迫你用资源视角建模业务，这种思维会自然延伸到数据库设计（优先考虑资源聚合根）、前端架构（基于资源的 React Query 缓存策略）、甚至 DevOps（每个资源对应一个 Kubernetes CRD）。我见过最优雅的系统，不是 REST 做得最“教科书”，而是所有团队成员——后端、前端、产品、测试——都用同一种语言描述世界：“这是一个用户资源，它有这些属性，这些关系，这些可执行动作。”

所以，别纠结“我的接口算不算 REST”，去问更本质的问题：