REST API 面试题与答案（2026 指南）

REST API 支撑了互联网的大多数系统集成。无论您应聘后端、全栈还是软件工程岗位，几乎都会被问到有关 REST API 设计、HTTP 方法与认证模式的问题。

本指南带您梳理面试官真正会问的问题。我按难度与岗位类型进行了组织，便于您聚焦目标职位最关键的内容。每个答案都包含实用示例，必要时还附有可改造的代码片段。

请记住一点：面试更常考基础而非高阶话题。只要打牢基础（HTTP 方法、状态码、无状态性），大多数 REST API 面试都能从容应对。那些“花哨”的架构模式是后话。

基础 REST API 面试题

这些问题考察您的基础知识。几乎所有面试都会涉及，与资历无关。

1. 什么是 REST？它有哪些约束？

REST 是“表述性状态转移”（Representational State Transfer）的缩写，是一种用于设计网络应用的架构风格，由 Roy Fielding 在其 2000 年博士论文中提出。

REST 有六个约束：

1. 客户端-服务器： 将用户界面与数据存储分离
2. 无状态：每个请求都包含完成该请求所需的全部信息
3. 可缓存： 响应必须指明是否可缓存
4. 分层系统：组件不能越过其直接所处的层次
5. 统一接口： 标准化的资源交互方式
6. 按需代码（可选）： 服务器可向客户端发送可执行代码

2. REST 与 SOAP 有何区别？

REST 是一种架构风格；SOAP 是一种协议。REST 通常通过 HTTP 使用 JSON，并利用标准 HTTP 方法。SOAP 只使用 XML，并定义了带有信封和 headers 的自有消息格式。

对于需要正式契约（WSDL）或消息级安全（WS-Security）的企业系统，SOAP 仍然有意义。

3. 什么是 HTTP 方法？各在何时使用？

HTTP 方法定义了对资源要执行的动作。

4. PUT 与 POST 的区别？

POST 由服务器决定 URI 来创建新资源。PUT 在客户端指定的特定 URI 处替换资源。

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resource技术支持

如果对不存在的 URI 执行 PUT，服务器可能会创建它；如果对已存在的 URI 执行 PUT，则会替换整个资源。

5. PUT 与 PATCH 的区别？

PUT 替换整个资源。PATCH 进行部分修改。

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "[email protected]", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}技术支持

6. 在 REST 中，“无状态”是什么意思？

无状态意味着每个请求都必须包含服务器处理该请求所需的全部信息。服务器不会在请求之间存储任何客户端上下文。

这意味着没有服务端会话。如果用户已认证，客户端必须在每次请求中携带凭据（通常是令牌）。

7. 什么样的 API 才是 RESTful？

当一个 API 满足所有 REST 约束（包括 HATEOAS，超媒体即应用状态引擎）时，才称得上真正 RESTful。实际中，多数自称“REST”的 API 实际是“类 REST”，或处于 Richardson 成熟度模型的第 2 级。老实说，对大多数用例来说这已经足够。

REST API 的 Richardson 成熟度模型层级。图片由作者提供。

8. 必须掌握的基础 HTTP 状态码有哪些？

至少要熟悉以下七个常用状态码，覆盖大多数 API 场景：

9. 资源与端点有何区别？

资源是数据实体（用户、订单、商品）。端点是访问该资源的 URL 路径。

Resource: User
Endpoints: GET /users, GET /users/123, POST /users技术支持

10. URI 设计的最佳实践是什么？

使用名词而非动词。URI 全小写，多词用连字符。集合使用复数名词。

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_items技术支持

避免过深的嵌套。与其使用 /users/123/posts/456/comments/789，不如考虑 /comments/789 或 /comments?post_id=456。

11. 什么是幂等性？哪些 HTTP 方法是幂等的？

如果多次执行某个操作与执行一次得到相同结果，则该操作是幂等的。

将某值设置为固定值的 PATCH 是幂等的；对计数器做自增的 PATCH 则不是。

12. 安全方法与幂等方法有何不同？

安全方法不修改资源（GET、HEAD、OPTIONS）。幂等方法可多次调用且效果相同（GET、PUT、DELETE）。

所有安全方法都是幂等的，但并非所有幂等方法都是安全的。DELETE 虽幂等但不安全，因为它会修改状态。

13. 何时使用查询参数，何时使用路径参数？

路径参数用于标识特定资源。查询参数用于筛选、排序或分页集合。

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10技术支持

14. 什么是内容协商？

内容协商允许客户端请求资源的不同表示形式。客户端发送 Accept 头，服务器以相应格式响应。

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XML技术支持

15. OPTIONS 方法的作用是什么？

OPTIONS 返回服务器针对特定 URL 所支持的 HTTP 方法。浏览器会在 CORS 预检请求中使用它来检查是否允许跨域请求。

进阶 REST API 面试题

这些问题考察实践应用与决策能力。中级岗位常见。

16. 401 与 403 有何区别？

这是最常被混淆的一对状态码。我在代码评审中见过资深工程师也会搞错。

401 Unauthorized

表示未认证。服务器不知道您是谁。响应应提示用户登录。

403 Forbidden

表示未被授权。服务器知道您是谁，但您没有权限。重新认证无济于事。

认证与授权错误的判定流程图。图片由作者提供。

17. 400 与 422 有何区别？

以下示例用于说明差异：

400 Bad Request

表示语法错误。服务器无法解析请求（例如 JSON 结构无效、缺少必要请求头）。

422 Unprocessable Entity

表示语法有效但语义错误。JSON 有效，但数据校验失败（如邮箱格式无效、密码过短）。

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validation技术支持

18. 何时使用 409 Conflict？

当请求与资源的当前状态冲突时使用 409：

• 乐观锁失败（ETag 不匹配）
• 唯一性约束冲突（用户名重复）
• 非法状态转换（取消已发货订单）

19. 如何实现分页？

两种主要方式：

基于偏移量的分页

简单，但在大数据集上性能较差。

GET /users?limit=20&offset=40技术支持

基于游标的分页

扩展性更好，且可避免数据变动导致的“页面漂移”。

GET /users?limit=20&cursor=eyJpZCI6MTIzfQ技术支持

Stripe、GitHub、Slack 等公司在大数据集上采用游标分页。

20. 常见的 API 版本化策略有哪些？

主要有三种方式，各有取舍：

URI 版本

最常见。显式且易于调试。

GET /v1/users
GET /v2/users技术支持

请求头版本

URL 更干净，但在浏览器中测试更困难。

GET /users
Accept-Version: v2技术支持

查询参数版本

易于添加，但会使 URL 杂乱。

GET /users?version=2技术支持

21. 什么是 ETag？缓存如何工作？

ETag 是资源的版本标识。服务器在响应中发送，客户端在后续请求中回传以检查资源是否变更。

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)技术支持

22. REST API 使用哪些认证方式？

四种最常见方式是 API Key、Bearer Token、OAuth 2.0 与 JWT：

23. 什么是 JWT？如何工作？

JWT（JSON Web Token）由三部分组成：Header、Payload 与 Signature。延伸阅读：在 Python 中处理 JSON。

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)技术支持

服务器对令牌进行签名；客户端在请求中携带它。服务器无需查库即可校验签名。

24. RS256 与 HS256 的区别？

HS256（对称）：同一密钥用于签名与验证。若多服务需要验证令牌，风险较高。

RS256（非对称）：私钥签名、公钥验证。推荐用于需要多服务验证的分布式系统。

25. 什么是 HATEOAS？

HATEOAS（超媒体即应用状态引擎）指响应中包含相关操作与资源的链接。

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}技术支持

实际中，大多数 API 并不会完整实现 HATEOAS。了解概念即可，工作中很少需要完全遵循 HATEOAS，即便是大型科技公司也不常见。

26. 如何一致地处理错误？

使用 RFC 7807 Problem Details 格式来统一错误响应：

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}技术支持

27. 什么是限流？为何重要？

限流可保护 API 免受滥用并确保公平使用。常见响应如下：

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0技术支持

28. 如何设计筛选与排序？

使用带有清晰约定的查询参数：

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,name技术支持

高级 REST API 面试题

这些问题考察架构思维。高级岗位常见。

29. OAuth 2.0 与 OAuth 2.1 有何变化？

OAuth 2.1 整合了安全最佳实践：

关键点：对所有客户端使用带 PKCE 的授权码模式。

30. 如何为支付端点实现幂等性？

使用幂等键，使 POST 在重试时仍安全：

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return result技术支持

客户端生成 UUID 并随请求发送。若相同键再次到达，则返回缓存响应。

31. 如何设计分布式限流器？

在分布式系统中，不能使用内存计数器，因为流量会在实例间负载均衡。这是常见的陷阱。

架构：

1. 使用 Redis 作为集中式计数存储
2. 实现令牌桶算法以容忍突发流量
3. 使用原子操作（Lua 脚本）避免竞态

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429技术支持

32. 何时选择 gRPC 而不是 REST？

选择 gRPC 的场景：

• 内部微服务通信（吞吐可提升 5-10 倍）
• 实时流式需求
• 带宽受限的移动端到后端
• 多语言环境需要严格契约

选择 REST 的场景：

• 面向公众的 API，消费者多样
• Web 应用（浏览器通用支持）
• 简单的 CRUD 操作
• 团队不熟悉 Protocol Buffers

33. 如何处理长耗时操作？

使用异步请求模式：

1. 客户端发送请求

2. 服务器返回 202 Accepted 并附带状态 URL

3. 客户端轮询状态 URL 直至完成

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}技术支持

34. 什么是 Saga 模式？

Saga 在不加锁的情况下处理跨微服务的分布式事务。每个服务执行本地事务并发布事件。若某一步失败，补偿事务用于撤销之前步骤。

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel Order技术支持

35. 常见的 JWT 安全漏洞有哪些？

算法混淆：攻击者将 RS256 改为 HS256，并用公钥签名。修复：始终白名单算法。

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])技术支持

“none” 算法：攻击者完全移除签名。修复：拒绝“none”算法。

后端开发者 REST API 面试题

36. 什么是 N+1 查询问题？

当您获取 N 条记录，又为每条记录的关联各执行一次额外查询时，就会出现 N+1 问题。

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queries技术支持

解决方案：

Django：外键用 select_related()，多对多用 prefetch_related()。

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()技术支持

SQLAlchemy：使用 joinedload() 或 selectinload()。

37. 如何配置连接池？

连接池会复用数据库连接，而不是为每个请求新建连接。

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)技术支持

38. 您了解哪些缓存策略？

三种主要缓存策略，分别适配不同的访问模式：

39. 如何实现 Webhook 签名校验？

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)技术支持

40. 哪些指标能反映 API 健康状况？

应监控以下四类关键指标来评估 API 健康：

全栈开发者 REST API 面试题

41. 浏览器何时发送 CORS 预检请求？

浏览器在以下情况会发送 OPTIONS 预检：

• 使用 GET、HEAD、POST 之外的方法
• 自定义请求头（Authorization、X-API-Key）
• Content-Type 非 form-urlencoded、multipart/form-data、text/plain

42. 如何安全地配置 CORS？

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));技术支持

切勿在使用凭据时搭配通配符（*）。切勿允许 null 来源。

43. 客户端应将令牌存在哪里？

令牌存储需要在 XSS 与 CSRF 风险之间权衡

最佳实践：将刷新令牌存放在 HttpOnly Cookie，并设置 SameSite=Strict。访问令牌存内存。

44. 何时用 WebSocket，何时用 SSE？

取决于您是否需要双向通信以及如何处理重连：

通知、直播信息流、股票行情适合用 SSE。聊天、多人游戏、协同编辑适合用 WebSocket。

45. 如何处理文件上传？

对大文件，使用分片上传并跟踪进度：

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}技术支持

基于场景的 REST API 面试题

46. 设计一个酒店预订系统的 REST API

资源：

• /hotels - 列出与搜索酒店

• /hotels/{id}/rooms - 可用房间

• /bookings - 创建与管理预订

• /guests/{id} - 住客档案

关键决策：

• 酒店搜索采用游标分页
• 对房态使用乐观锁
• 重复预订返回 409 Conflict
• 支付处理使用幂等键

47. 如何实现软删除？

增加 deleted_at 时间戳，而非直接移除记录：

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()技术支持

48. 如何从 v1 迁移到 v2 而不破坏客户端？

使用“绞杀榕”模式：

1. 并行部署 v2 与 v1
2. 将新功能路由至 v2
3. 逐步迁移现有端点
4. 通过 Sunset 头通知弃用
5. 迁移期结束后移除 v1

49. 如何设计支持复杂筛选的搜索 API？

以多筛选条件的商品搜索为例：

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123技术支持

设计决策：

• 全文检索用 Elasticsearch（关系型数据库难以胜任模糊匹配）
• 实现分面搜索以展示可用筛选项
• 返回各筛选条件的计数，便于用户预估结果量
• 缓存热门搜索组合

50. 在微服务架构中如何处理 API 版本化？

选项：

1. 网关级版本：API 网关将 /v1/* 路由到旧服务，/v2/* 路由到新服务

2. 服务级版本： 各服务各自处理版本协商

3. 消费者驱动契约： 使用 Pact 等工具保障兼容性

对多数团队而言，网关级版本化提供了最清晰的边界。

51. 如何为不同用户等级实现限流？

方案是定义分层阈值，并用 Redis 计数器进行检查：

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )技术支持

行为类 REST API 面试题

52. 向非技术人员解释 REST

“把 REST API 想象成餐馆里的服务员。您（顾客）不能直接进厨房，而是告诉服务员您要点什么，服务员再端给您。菜单就像 API 文档，列出可点的内容。服务员遵循一些规则：您要查询（GET）、您要新增点单（POST）、或者您要退掉某样菜（DELETE）。如果厨房里某样没了，服务员会告知您（404 Not Found），避免您一直干等。”

这个类比在与干系人沟通时非常好用。

53. 描述一次您对 API 的优化经历

使用 STAR 法：

• 情境："我们的搜索 API 在流量高峰时响应需要 3 秒"
• 任务："需要在不做大改动的前提下降低延迟"
• 行动："为高频查询加入 Redis 缓存，实现游标分页，并新增数据库索引"
• 结果："响应降至 200ms，吞吐能力提升 5 倍"

54. 如何将破坏性变更通知给 API 使用者？

1. 尽早公告：重大变更至少提前 6-12 个月通知

2. 使用 Sunset 头：Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. 提供迁移指南： 明确变更点与适配方法

4. 双版本并行： 过渡期内保留旧版本

5. 监控使用情况： 追踪仍在使用旧版本的客户端

55. 您会为 API 编写哪些文档？

必备文档包括：

• OpenAPI/Swagger 规范： 机器可读的契约
• 入门指南： 5 分钟内完成第一次调用
• 认证指南： 如何获取与使用凭据
• 错误参考： 所有可能的错误码及处理方式
• 更新日志： 各版本改动
• 限流文档： 各等级限制与 429 处理方法

56. 何时不要使用 REST？

REST 并非万能。知道何时选择替代方案体现架构成熟度。我见过团队在并不合适的场景强行使用 REST，反而带来更多问题。

REST API 速查

在准备面试或实际开发中需要核对 HTTP 方法属性、状态码或常见模式时，可将本节作为速查参考。

HTTP 方法对比

下表概述了各 HTTP 方法的关键属性，帮助您为用例选择合适的方法。

状态码参考

以下是最常用的 HTTP 状态码，按类别组织。重在理解使用时机，而非死记规范全表。

2xx 成功

• 200 OK：成功的 GET、PUT、PATCH
• 201 Created：成功的 POST（包含 Location 头）
• 204 No Content：成功的 DELETE

4xx 客户端错误

• 400 Bad Request：语法错误
• 401 Unauthorized：需要认证
• 403 Forbidden：已认证但未授权
• 404 Not Found：资源不存在
• 409 Conflict：状态冲突
• 422 Unprocessable Entity：校验错误
• 429 Too Many Requests：被限流

5xx 服务器错误

• 500 Internal Server Error：通用服务器故障
• 502 Bad Gateway：上游服务器错误
• 503 Service Unavailable：暂时过载

常见错误避免

即使是有经验的开发者也会踩坑。设计或实现 REST API 时注意避开这些常见问题：

• 在 URL 中使用动词（例如 /getUsers 而非 /users）

• 错误状态返回 200 OK，会破坏客户端错误处理

• 混淆 401 与 403（认证 vs 授权）

• URL 过度嵌套 超过两级

• 将令牌存入 localStorage（引入 XSS 风险）

• 忽视 POST 的幂等性

• 返回泛化的错误信息，缺少可操作的细节

结语

我知道死记定义并不能保证通过每一次技术面试。现实是，工程实践常常需要“打破”我们刚讨论的那些“严格”规则，面试官更在乎您的推理过程，而非背诵 RFC 的能力。对于高度专精的岗位，深入的领域知识或特定框架经验依然可能是关键因素。

但即便不被逐字问到，掌握这些 REST 基础依然重要。它们是理解现代 Web 运作的蓝图。无论是设计新系统还是排查生产故障，理解 401 与 403 的区别（正如前文所述）都能让您更快定位问题。您也会认识到，标准化 API 交互——而不仅是“能跑起来的代码”——才是高级工程师的标志。

如果您想更深入地构建这类系统，欢迎查看我们的 Python API 入门 课程。