面经策

什么是 Restful 风格的接口？ ​

  • 标签：后端、Spring

🏛 业务架构师 ​

RESTful 风格的核心是把后端能力建模为"资源"，用 URL 定位资源、用 HTTP 方法表达操作、用状态码表达结果：

  • URL 是名词：/orders/12345（好）vs /getOrderById?id=12345（坏——动词进了 URL）；
  • 方法表达语义：GET 查询、POST 创建、PUT 全量更新、PATCH 部分更新、DELETE 删除；
  • 状态码表达结果：200/201/204/400/404/409/422/500 各司其职；
  • 无状态：每次请求自带完整上下文，服务不依赖会话。

业务架构师视角，我推 REST 的理由不在"标准洁癖"，而在协作成本与生态兼容：

  1. 契约可预测：调用方看 URL 就懂语义，前后端、跨团队联调的沟通成本低；配合 OpenAPI/Swagger 自动生成文档和客户端 SDK；
  2. 基础设施天然支持：网关（路由/限流按路径）、缓存（GET 幂等可缓存）、CDN、监控（按状态码统计成功率）都假设 REST 语义——用对 GET/POST、用对状态码，全链路的缓存与容错行为才会正确；
  3. 幂等性要显设计：PUT/DELETE 天然幂等，POST 不幂等——支付、下单这类 POST 操作要配幂等号（Idempotency-Key）。REST 只是风格，资金安全靠的是风格之上的业务设计。

务实提醒：不必教条（GraphQL、RPC 在特定场景更优），内部高频调用 Dubbo/gRPC、对外 OpenAPI 用 REST，是我常见的组合。

🏗 系统架构师 ​

REST 是一组架构约束，落到接口风格上：

  • 面向资源：URL 表达名词性资源（/orders/123），而非动作（不是 /getOrder?id=）；
  • 统一接口：HTTP 动词表达操作——GET 读（安全幂等）、POST 建、PUT 全量改（幂等）、PATCH 局部改、DELETE 删（幂等）；
  • 无状态：请求自含全部上下文，会话态外置；
  • 状态码即语义：200/201/204/400/404/409/429 各司其职；
  • 表现层协商：同一资源多种表示（JSON/XML）。

架构上我强调幂等性的工程价值：GET/PUT/DELETE 幂等意味着可安全重试——超时重试、网关重试、MQ 去重都建立在这个性质上；POST 非幂等，重试必须带幂等键（客户端生成 requestId，服务端去重），这是支付与下单链路的标配设计。

我也直言不追「纯 REST」：HATEOAS 在企业内网收益低。实用主义组合——资源化 URL 加动词语义加无状态加明确错误契约，足够支撑绝大多数 API。

💻 全栈开发专家 ​

REST 是以资源为中心的接口设计风格，核心约束：

  1. URL 表达资源（名词），HTTP 动词表达操作：
java
@GetMapping("/orders/{id}")       // 查
@PostMapping("/orders")           // 增，返回 201
@PutMapping("/orders/{id}")       // 全量改
@PatchMapping("/orders/{id}")     // 部分改
@DeleteMapping("/orders/{id}")    // 删，返回 204
  1. 合理使用状态码：200/201/204/400/401/403/404/409（冲突）/429（限流），而不是全 200 + 业务 code
  2. 无状态：会话状态不存服务端，每次请求带齐上下文（token），天然适配水平扩容
  3. 版本化（/api/v1/orders）、过滤分册放 query（?status=PAID&page=2）、层级表达从属（/users/9/orders）

工程上我的补充观点：严格的 REST 在企业内网常被打折——批量操作、复杂查询用 POST + JSON 更实际（如 POST /orders/batch-cancel），别为教条硬塞 GET；统一响应体 + 业务码与 HTTP 状态码双轨是多数团队的现实选择，关键是用 OpenAPI 文档把约定写死；POST 不幂等，防重要靠幂等键 + 唯一索引。这些权衡说出来，说明真设计过接口而不是背风格指南。