认证和授权

JWT (JSON Web Token) 认证

JWT 可以理解成一张“数字身份证”，里面装着用户的身份信息。

它还能用来校验内容是不是真的、有没有被篡改。

// JWT 的结构
// Header.Payload.Signature
// 登录流程
POST /api/auth/login
{
  "email": "user@example.com",
  "password": "password123"
}
// 响应
{
  "success": true,
  "data": {
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
    "user": {
      "id": 123,
      "name": "张三",
      "email": "user@example.com"
    }
  }
}
// 后续请求携带 Token
GET /api/users/profile
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

OAuth 2.0 集成

OAuth 2.0 常用于第三方登录场景。

用户先跳转到授权页面，完成授权后，再通过回调获取应用 Token。

// 第三方登录流程
GET /api/auth/google/redirect
// 重定向到 Google 授权页面
// 回调处理
GET /api/auth/google/callbackcode=authorization_code
// 返回应用 Token
API 限流和配额
请求频率限制
ja vascript// 响应头中包含限流信息
HTTP/1.1 200 OK
X-RateLimit-Limit: 1000        // 每小时限制1000次请求
X-RateLimit-Remaining: 999     // 剩余请求次数
X-RateLimit-Reset: 1642694400  // 重置时间戳
// 超出限制时的响应
HTTP/1.1 429 Too Many Requests
{
  "success": false,
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "请求过于频繁，请稍后再试",
    "retryAfter": 3600  // 建议等待时间（秒）
  }
}

API 限流和配额

请求频率限制是保障 API 稳定性的重要手段。

通过响应头，客户端可以知道限制总量、剩余次数和重置时间。

如果超出限制，服务端会返回 429 Too Many Requests，并提示等待时间。

数据缓存策略

HTTP 缓存头

HTTP 缓存头可以减少重复请求，提升接口响应效率。

常见方式包括设置 Cache-Control 和 ETag，并配合条件请求使用。

// 设置缓存策略
GET /api/users/123
Cache-Control: public, max-age=3600  // 缓存1小时
ETag: "a1b2c3d4e5f6"                // 资源版本标识
// 条件请求
GET /api/users/123
If-None-Match: "a1b2c3d4e5f6"
// 如果资源未变化
HTTP/1.1 304 Not Modified

Redis 缓存示例

Redis 缓存适合高频读取的数据场景。

• 先检查缓存是否命中
• 未命中时查询数据库
• 再将结果写入缓存

// 缓存策略伪代码
async function getUser(userId) {
  // 1. 先检查缓存
  const cached = await redis.get(`user:${userId}`);
  if (cached) {
    return JSON.parse(cached);
  }
// 2. 缓存未命中，查询数据库
  const user = await database.findUser(userId);
// 3. 将结果缓存
  await redis.setex(`user:${userId}`, 3600, JSON.stringify(user));
return user;
}

微服务架构中的 API

服务间通信

API 网关模式

在微服务架构中，API 网关负责统一接入和路由分发。

它可以根据不同路径，将请求转发到对应服务。

// API 网关路由配置
{
  "routes": [
    {
      "path": "/api/users/*",
      "service": "user-service",
      "url": "http://user-service:3001"
    },
    {
      "path": "/api/orders/*", 
      "service": "order-service",
      "url": "http://order-service:3002"
    }
  ]
}

GraphQL vs REST

REST API 的局限性

REST API 在获取关联数据时，往往需要多次请求。

这样会增加请求次数，也会提升前后端交互成本。

// REST: 需要多次请求获取相关数据
GET /api/users/123        // 获取用户信息
GET /api/users/123/posts  // 获取用户发布的文章
GET /api/posts/456/comments // 获取文章评论

GraphQL 的优势

GraphQL 的优势在于一次请求即可获取所需数据。

这能减少多次请求带来的开销，让数据获取更灵活。

// GraphQL: 一次请求获取所需数据
query {
  user(id: 123) {
    name
    email
    posts {
      title
      comments {
        content
        author
      }
    }
  }
}