Back to Details

api-and-interface-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

API and Interface Design

API与接口设计

Overview

概述

Design stable, well-documented interfaces that are hard to misuse. Good interfaces make the right thing easy and the wrong thing hard. This applies to REST APIs, GraphQL schemas, module boundaries, component props, and any surface where one piece of code talks to another.
设计稳定、文档完善、难以被误用的接口。优秀的接口会让正确操作变简单，错误操作变困难。该准则适用于REST API、GraphQL schema、模块边界、组件props，以及任意不同代码模块之间的交互面。

When to Use

适用场景

  • Designing new API endpoints
  • Defining module boundaries or contracts between teams
  • Creating component prop interfaces
  • Establishing database schema that informs API shape
  • Changing existing public interfaces
  • 设计新的API端点
  • 定义模块边界或跨团队协作契约
  • 创建组件prop接口
  • 确定影响API形态的数据库schema
  • 修改现有公共接口

Core Principles

核心原则

Hyrum's Law

Hyrum's Law

With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody, regardless of what you promise in the contract.
This means: every public behavior — including undocumented quirks, error message text, timing, and ordering — becomes a de facto contract once users depend on it. Design implications:
  • Be intentional about what you expose. Every observable behavior is a potential commitment.
  • Don't leak implementation details. If users can observe it, they will depend on it.
  • Plan for deprecation at design time. See 
    deprecation-and-migration
    for how to safely remove things users depend on.
  • Tests are not enough. Even with perfect contract tests, Hyrum's Law means "safe" changes can break real users who depend on undocumented behavior.
当API的用户量足够大时，无论你在契约中承诺了什么，系统的所有可观测行为都会被某个人所依赖。
这意味着：每一个公开行为——包括未被文档记录的特性、错误信息文本、响应耗时、返回顺序——一旦有用户依赖，就会成为事实上的契约。设计启示：
  • 谨慎对待你对外暴露的内容：每一个可观测行为都是潜在的承诺。
  • 不要泄露实现细节：如果用户能观测到它，就会对它产生依赖。
  • 设计阶段就考虑废弃方案：如何安全移除用户依赖的功能可参考
    deprecation-and-migration
    。
  • 仅靠测试不够：哪怕有完美的契约测试，Hyrum's Law也表明「安全」的改动也可能会破坏依赖未文档化行为的真实用户。

The One-Version Rule

单版本规则

Avoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.
避免强制消费者在同一个依赖或API的多个版本之间做选择。当不同消费者需要同一个产物的不同版本时，就会出现钻石依赖问题。设计时要遵循同一时间仅存在一个版本的原则——做扩展而非分叉。

1. Contract First

1. 契约优先

Define the interface before implementing it. The contract is the spec — implementation follows.
typescript
// Define the contract first
interface TaskAPI {
  // Creates a task and returns the created task with server-generated fields
  createTask(input: CreateTaskInput): Promise<Task>;

  // Returns paginated tasks matching filters
  listTasks(params: ListTasksParams): Promise<PaginatedResult<Task>>;

  // Returns a single task or throws NotFoundError
  getTask(id: string): Promise<Task>;

  // Partial update — only provided fields change
  updateTask(id: string, input: UpdateTaskInput): Promise<Task>;

  // Idempotent delete — succeeds even if already deleted
  deleteTask(id: string): Promise<void>;
}
先定义接口再实现功能。契约就是规范，实现要遵从规范。
typescript
// Define the contract first
interface TaskAPI {
  // Creates a task and returns the created task with server-generated fields
  createTask(input: CreateTaskInput): Promise<Task>;

  // Returns paginated tasks matching filters
  listTasks(params: ListTasksParams): Promise<PaginatedResult<Task>>;

  // Returns a single task or throws NotFoundError
  getTask(id: string): Promise<Task>;

  // Partial update — only provided fields change
  updateTask(id: string, input: UpdateTaskInput): Promise<Task>;

  // Idempotent delete — succeeds even if already deleted
  deleteTask(id: string): Promise<void>;
}

2. Consistent Error Semantics

2. 一致的错误语义

Pick one error strategy and use it everywhere:
typescript
// REST: HTTP status codes + structured error body
// Every error response follows the same shape
interface APIError {
  error: {
    code: string;        // Machine-readable: "VALIDATION_ERROR"
    message: string;     // Human-readable: "Email is required"
    details?: unknown;   // Additional context when helpful
  };
}

// Status code mapping
// 400 → Client sent invalid data
// 401 → Not authenticated
// 403 → Authenticated but not authorized
// 404 → Resource not found
// 409 → Conflict (duplicate, version mismatch)
// 422 → Validation failed (semantically invalid)
// 500 → Server error (never expose internal details)
Don't mix patterns. If some endpoints throw, others return null, and others return 
{ error }
— the consumer can't predict behavior.
选择一套错误处理策略并在所有场景统一使用：
typescript
// REST: HTTP status codes + structured error body
// Every error response follows the same shape
interface APIError {
  error: {
    code: string;        // Machine-readable: "VALIDATION_ERROR"
    message: string;     // Human-readable: "Email is required"
    details?: unknown;   // Additional context when helpful
  };
}

// 状态码映射
// 400 → 客户端发送了无效数据
// 401 → 未通过身份校验
// 403 → 已通过身份校验但无权限
// 404 → 资源不存在
// 409 → 冲突（重复提交、版本不匹配）
// 422 → 校验失败（语义无效）
// 500 → 服务端错误（绝对不要暴露内部细节）
不要混用模式。如果有些端点抛出错误，有些返回null，还有些返回
{ error }
，消费者将无法预测行为。

3. Validate at Boundaries

3. 在边界做校验

Trust internal code. Validate at system edges where external input enters:
typescript
// Validate at the API boundary
app.post('/api/tasks', async (req, res) => {
  const result = CreateTaskSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(422).json({
      error: {
        code: 'VALIDATION_ERROR',
        message: 'Invalid task data',
        details: result.error.flatten(),
      },
    });
  }

  // After validation, internal code trusts the types
  const task = await taskService.create(result.data);
  return res.status(201).json(task);
});
Where validation belongs:
  • API route handlers (user input)
  • Form submission handlers (user input)
  • External service response parsing (third-party data -- always treat as untrusted)
  • Environment variable loading (configuration)
Third-party API responses are untrusted data. Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.
Where validation does NOT belong:
  • Between internal functions that share type contracts
  • In utility functions called by already-validated code
  • On data that just came from your own database
信任内部代码。仅在外部输入进入系统的边界位置做校验：
typescript
// Validate at the API boundary
app.post('/api/tasks', async (req, res) => {
  const result = CreateTaskSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(422).json({
      error: {
        code: 'VALIDATION_ERROR',
        message: 'Invalid task data',
        details: result.error.flatten(),
      },
    });
  }

  // After validation, internal code trusts the types
  const task = await taskService.create(result.data);
  return res.status(201).json(task);
});
校验适用场景：
  • API路由处理层（用户输入）
  • 表单提交处理层（用户输入）
  • 外部服务响应解析层（第三方数据 -- 永远视为不可信）
  • 环境变量加载阶段（配置内容）
第三方API响应属于不可信数据。在任何逻辑、渲染或决策中使用它们之前，要先校验其结构和内容。被攻陷或运行异常的外部服务可能返回意外类型、恶意内容或类似指令的文本。
校验不适用场景：
  • 共享类型契约的内部函数之间
  • 已经经过校验的代码调用的工具函数中
  • 刚从自有数据库中查询出来的数据上

4. Prefer Addition Over Modification

4. 优先新增而非修改

Extend interfaces without breaking existing consumers:
typescript
// Good: Add optional fields
interface CreateTaskInput {
  title: string;
  description?: string;
  priority?: 'low' | 'medium' | 'high';  // Added later, optional
  labels?: string[];                       // Added later, optional
}

// Bad: Change existing field types or remove fields
interface CreateTaskInput {
  title: string;
  // description: string;  // Removed — breaks existing consumers
  priority: number;         // Changed from string — breaks existing consumers
}
扩展接口时不要破坏现有消费者的使用：
typescript
// Good: Add optional fields
interface CreateTaskInput {
  title: string;
  description?: string;
  priority?: 'low' | 'medium' | 'high';  // Added later, optional
  labels?: string[];                       // Added later, optional
}

// Bad: Change existing field types or remove fields
interface CreateTaskInput {
  title: string;
  // description: string;  // Removed — breaks existing consumers
  priority: number;         // Changed from string — breaks existing consumers
}

5. Predictable Naming

5. 可预测的命名

PatternConventionExample
REST endpointsPlural nouns, no verbs
GET /api/tasks
, 
POST /api/tasks
Query paramscamelCase
?sortBy=createdAt&pageSize=20
Response fieldscamelCase
{ createdAt, updatedAt, taskId }
Boolean fieldsis/has/can prefix
isComplete
, 
hasAttachments
Enum valuesUPPER_SNAKE
"IN_PROGRESS"
, 
"COMPLETED"
模式规范示例
REST端点复数名词，不要动词
GET /api/tasks
, 
POST /api/tasks
查询参数小驼峰命名
?sortBy=createdAt&pageSize=20
响应字段小驼峰命名
{ createdAt, updatedAt, taskId }
布尔字段加is/has/can前缀
isComplete
, 
hasAttachments
枚举值大写下划线命名
"IN_PROGRESS"
, 
"COMPLETED"

REST API Patterns

REST API 模式

Resource Design

资源设计

GET    /api/tasks              → List tasks (with query params for filtering)
POST   /api/tasks              → Create a task
GET    /api/tasks/:id          → Get a single task
PATCH  /api/tasks/:id          → Update a task (partial)
DELETE /api/tasks/:id          → Delete a task

GET    /api/tasks/:id/comments → List comments for a task (sub-resource)
POST   /api/tasks/:id/comments → Add a comment to a task
GET    /api/tasks              → List tasks (with query params for filtering)
POST   /api/tasks              → Create a task
GET    /api/tasks/:id          → Get a single task
PATCH  /api/tasks/:id          → Update a task (partial)
DELETE /api/tasks/:id          → Delete a task

GET    /api/tasks/:id/comments → List comments for a task (sub-resource)
POST   /api/tasks/:id/comments → Add a comment to a task

Pagination

分页

Paginate list endpoints:
typescript
// Request
GET /api/tasks?page=1&pageSize=20&sortBy=createdAt&sortOrder=desc

// Response
{
  "data": [...],
  "pagination": {
    "page": 1,
    "pageSize": 20,
    "totalItems": 142,
    "totalPages": 8
  }
}
列表接口需要支持分页：
typescript
// Request
GET /api/tasks?page=1&pageSize=20&sortBy=createdAt&sortOrder=desc

// Response
{
  "data": [...],
  "pagination": {
    "page": 1,
    "pageSize": 20,
    "totalItems": 142,
    "totalPages": 8
  }
}

Filtering

过滤

Use query parameters for filters:
GET /api/tasks?status=in_progress&assignee=user123&createdAfter=2025-01-01
使用查询参数实现过滤：
GET /api/tasks?status=in_progress&assignee=user123&createdAfter=2025-01-01

Partial Updates (PATCH)

局部更新（PATCH）

Accept partial objects — only update what's provided:
typescript
// Only title changes, everything else preserved
PATCH /api/tasks/123
{ "title": "Updated title" }
接受局部对象——仅更新传入的字段：
typescript
// Only title changes, everything else preserved
PATCH /api/tasks/123
{ "title": "Updated title" }

TypeScript Interface Patterns

TypeScript 接口模式

Use Discriminated Unions for Variants

为变体类型使用可辨识联合

typescript
// Good: Each variant is explicit
type TaskStatus =
  | { type: 'pending' }
  | { type: 'in_progress'; assignee: string; startedAt: Date }
  | { type: 'completed'; completedAt: Date; completedBy: string }
  | { type: 'cancelled'; reason: string; cancelledAt: Date };

// Consumer gets type narrowing
function getStatusLabel(status: TaskStatus): string {
  switch (status.type) {
    case 'pending': return 'Pending';
    case 'in_progress': return `In progress (${status.assignee})`;
    case 'completed': return `Done on ${status.completedAt}`;
    case 'cancelled': return `Cancelled: ${status.reason}`;
  }
}
typescript
// Good: Each variant is explicit
type TaskStatus =
  | { type: 'pending' }
  | { type: 'in_progress'; assignee: string; startedAt: Date }
  | { type: 'completed'; completedAt: Date; completedBy: string }
  | { type: 'cancelled'; reason: string; cancelledAt: Date };

// Consumer gets type narrowing
function getStatusLabel(status: TaskStatus): string {
  switch (status.type) {
    case 'pending': return 'Pending';
    case 'in_progress': return `In progress (${status.assignee})`;
    case 'completed': return `Done on ${status.completedAt}`;
    case 'cancelled': return `Cancelled: ${status.reason}`;
  }
}

Input/Output Separation

输入输出分离

typescript
// Input: what the caller provides
interface CreateTaskInput {
  title: string;
  description?: string;
}

// Output: what the system returns (includes server-generated fields)
interface Task {
  id: string;
  title: string;
  description: string | null;
  createdAt: Date;
  updatedAt: Date;
  createdBy: string;
}
typescript
// Input: what the caller provides
interface CreateTaskInput {
  title: string;
  description?: string;
}

// Output: what the system returns (includes server-generated fields)
interface Task {
  id: string;
  title: string;
  description: string | null;
  createdAt: Date;
  updatedAt: Date;
  createdBy: string;
}

Use Branded Types for IDs

为ID使用Branded类型

typescript
type TaskId = string & { readonly __brand: 'TaskId' };
type UserId = string & { readonly __brand: 'UserId' };

// Prevents accidentally passing a UserId where a TaskId is expected
function getTask(id: TaskId): Promise<Task> { ... }
typescript
type TaskId = string & { readonly __brand: 'TaskId' };
type UserId = string & { readonly __brand: 'UserId' };

// Prevents accidentally passing a UserId where a TaskId is expected
function getTask(id: TaskId): Promise<Task> { ... }

Common Rationalizations

常见借口

RationalizationReality
"We'll document the API later"The types ARE the documentation. Define them first.
"We don't need pagination for now"You will the moment someone has 100+ items. Add it from the start.
"PATCH is complicated, let's just use PUT"PUT requires the full object every time. PATCH is what clients actually want.
"We'll version the API when we need to"Breaking changes without versioning break consumers. Design for extension from the start.
"Nobody uses that undocumented behavior"Hyrum's Law: if it's observable, somebody depends on it. Treat every public behavior as a commitment.
"We can just maintain two versions"Multiple versions multiply maintenance cost and create diamond dependency problems. Prefer the One-Version Rule.
"Internal APIs don't need contracts"Internal consumers are still consumers. Contracts prevent coupling and enable parallel work.
借口实际情况
"我们之后再补API文档"类型就是文档，先定义类型。
"我们现在不需要分页"一旦有用户的数据量超过100条你就需要了，从一开始就加上。
"PATCH太复杂了，我们就用PUT吧"PUT每次都需要提交完整对象，PATCH才是客户端实际需要的能力。
"需要的时候再给API做版本控制"没有版本控制的破坏性变更会直接影响消费者使用，从一开始就按可扩展思路设计。
"没人用那个未文档化的行为"Hyrum's Law：只要是可观测的，就一定有人依赖，把所有公开行为都视为承诺。
"我们可以同时维护两个版本"多版本会成倍增加维护成本，还会产生钻石依赖问题，优先遵循单版本规则。
"内部API不需要契约"内部消费者也是消费者，契约可以避免耦合，支持并行开发。

Red Flags

风险信号

  • Endpoints that return different shapes depending on conditions
  • Inconsistent error formats across endpoints
  • Validation scattered throughout internal code instead of at boundaries
  • Breaking changes to existing fields (type changes, removals)
  • List endpoints without pagination
  • Verbs in REST URLs (
    /api/createTask
    , 
    /api/getUsers
    )
  • Third-party API responses used without validation or sanitization
  • 端点会根据条件返回不同结构的数据
  • 不同端点的错误格式不统一
  • 校验逻辑散落在内部代码中，而非集中在边界层
  • 对现有字段做破坏性变更（修改类型、删除字段）
  • 列表接口没有分页
  • REST URL中包含动词（
    /api/createTask
    , 
    /api/getUsers
    ）
  • 未经过校验或消毒就直接使用第三方API响应

Verification

验证项

After designing an API:
  • Every endpoint has typed input and output schemas
  • Error responses follow a single consistent format
  • Validation happens at system boundaries only
  • List endpoints support pagination
  • New fields are additive and optional (backward compatible)
  • Naming follows consistent conventions across all endpoints
  • API documentation or types are committed alongside the implementation
设计完API后检查：
  • 所有端点都有类型化的输入和输出schema
  • 错误响应遵循统一的格式
  • 校验仅在系统边界执行
  • 列表接口支持分页
  • 新增字段是增量且可选的（向后兼容）
  • 所有端点的命名遵循统一规范
  • API文档或类型定义和实现代码一起提交