JobCannon
全部技能

API Design Patterns

Designing clean, consistent, and developer-friendly APIs

⬢ 層級 2技術
高
薪資影響
9 個月
學習時長
中等
難度
12
職業
一覽

Senior backend/architect skill covering BFF pattern, API gateway architecture, idempotency keys, CQRS over APIs, async patterns (webhooks vs polling vs SSE), schema evolution, and saga choreography. Foundation for +$25k–$40k salary increase. 6–12 months to proficiency; 18 months to mastery of multi-service orchestration.

什麼是 API Design Patterns

API Design Patterns are proven architectures and practices for building APIs that developers love to use: RESTful conventions (HTTP verbs, status codes), BFF (Backend-for-Frontend) pattern, API gateway architecture, idempotency for safe retries, CQRS (Command Query Responsibility Segregation) for splitting reads and writes, async patterns (webhooks vs. polling vs. SSE), schema evolution without breaking clients, rate limiting strategies, and saga choreography for distributed transactions. Unlike basic REST API building (which most developers learn), patterns address production complexity: scaling, resilience, backward compatibility, and multi-service coordination. A junior backend builds an API that works; a senior architect builds APIs that scale to 1M+ QPS, handle partial failures gracefully, and don't break clients for 5 years. API Design Patterns is the bridge between monolith development and distributed systems; it's where system design meets implementation. Master this skill, and you can architect the communication layer for any system.

🔧 工具與生態
KongApigeeTykAWS API GatewayEnvoyIstioAsyncAPIAWS EventBridgeApache KafkaPostmanReadMeSpectral

💰 各地區薪資

地區初級中級高級
USA$125,000$160,000$220,000
UK£70,000£95,000£140,000
EU€75,000€105,000€150,000
CANADACA$130,000CA$170,000CA$235,000

❓ 常見問題

BFF (Backend for Frontend) vs API Gateway, are they the same?
No. BFF is a lightweight aggregator service that shapes data for a specific client (web, mobile, TV). API Gateway is the entry point enforcing rate limiting, auth, versioning, logging. Modern architecture: client → API Gateway → BFF → microservices. A single BFF talks to 5–10 backend services; API Gateway sits in front of all BFFs.
How do I implement idempotency keys for safe retries?
Client generates a UUID (idempotency key). Server stores {key → response} in cache (Redis, Memcached) for 24 hours. On duplicate request, return cached response instead of re-executing. Implement as middleware; decorate all mutation endpoints (POST, PUT, DELETE). Critical for payments, refunds, and account changes.
Polling vs webhooks vs SSE vs WebSocket, which pattern for what?
Polling: client asks every N seconds (cheapest for sparse data, ~30s+). Webhooks: server POSTs to client on event (fire-and-forget, idempotency required, backoff needed). SSE: one-way server→client stream over HTTP (good for live updates, auto-reconnect). WebSocket: bidirectional, stateful (real-time chat, multiplayer games). For notifications: webhooks. For feeds: SSE. For two-way: WebSocket. For batch jobs: polling.
CQRS over APIs, separate read and write endpoints?
Yes. /api/v1/users/{id} (read) lives on a read replica or cache. /api/v1/users/{id}/update (write) hits primary DB + event bus. Allows different scaling, caching, and retry strategies per operation. Not required for small systems; essential for >1M QPS.
Schema evolution without breaking clients, how?
Add-only: new optional fields never break old clients. Deprecation headers: `Deprecation: true`, `Sunset: 2026-12-31T00:00:00Z`. Versioning: /v2/ endpoint runs in parallel for 6 months. Coexist strategies: clients read extra fields without error, ignore unknown fields. Always default missing fields on read, never require.
Saga pattern for distributed transactions, orchestration vs choreography?
Orchestration: central service (saga coordinator) calls services A→B→C, compensates on failure. Choreography: services publish events; downstream services listen and act, compensate by publishing reverse events. Orchestration is easier to debug. Choreography scales better and is loosely coupled. For <5 services: orchestration. For >10 with independent teams: choreography.
API rate limiting, fixed window vs sliding window vs token bucket?
Fixed window (simplest): reset counts every minute (fairness issues at boundaries). Sliding window: track requests in a time window (expensive). Token bucket (recommended): refill N tokens/minute, burst allowed. For public APIs: token bucket at gateway level + per-user quotas at service level. IETF draft-6585: `RateLimit-Limit: 100`, `RateLimit-Remaining: 45`, `RateLimit-Reset: 1640995200`.

不確定這項技能適不適合你？

做一下職業匹配，我們會推薦合適的方向。

找到最適合我的技能 →

找到理想的職業方向

在 2,521 個職業中進行技能匹配。免費。

免費做職業匹配 →