Skip to main content Skills Marketplace Descubre y explora habilidades de IA creadas por la comunidad.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Copiar promptMostrar detalles del prompt Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.
npx skills add https://github.com/miles990/claude-software-skills --skill api-designEl comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.
¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.
Descargar Zip Descargando... Explorador de archivos
4 archivos Ocupaciones relacionadas SOC
Basado en la clasificación ocupacional SOC
name api-design description RESTful, GraphQL, gRPC, and API best practices domain software-design version 1.0.0 tags ["rest","graphql","grpc","websocket","openapi","versioning"] triggers {"keywords":{"primary":["api","rest","restful","graphql","grpc","endpoint","openapi"],"secondary":["swagger","websocket","webhook","versioning","rate limit","pagination"]},"context_boost":["backend","microservice","integration","http"],"context_penalty":["frontend","ui","css"],"priority":"high"} collaboration {"prerequisites":[],"delegation_triggers":[{"trigger":"Implementation of API endpoints","delegate_to":"backend","context":"Framework-specific implementation patterns"},{"trigger":"Data model for API responses","delegate_to":"database","context":"Schema design, query requirements"},{"trigger":"API contract testing","delegate_to":"testing-strategies","context":"Contract tests, integration tests"}],"receives_context_from":[{"skill":"backend","receives":["Framework capabilities","Middleware available","Authentication mechanism"]},{"skill":"database","receives":["Available data structures","Query performance characteristics"]}],"provides_context_to":[{"skill":"backend","provides":["Endpoint specifications","Request/response formats","Error code conventions"]},{"skill":"frontend","provides":["API documentation","Authentication flow","Rate limiting rules"]},{"skill":"testing-strategies","provides":["API contract specifications","Expected behaviors"]}]}
API Design
Overview
Design principles for building APIs that are intuitive, consistent, and scalable. Covers REST, GraphQL, gRPC, and real-time protocols.
RESTful API Design
Resource Naming
✅ Good (nouns, plural):
GET /users # List users
GET /users/123 # Get user
POST /users # Create user
PUT /users/123 # Update user
DELETE /users/123 # Delete user
❌ Bad (verbs, actions):
GET /getUsers
POST /createUser
POST /users/123/delete
Nested Resources
# Hierarchical relationship
GET /users/123/orders # User's orders
GET /users/123/orders/456 # Specific order
# Alternative: Query parameter for filtering
GET /orders?userId=123 # Filter orders by user
# Rule: Nest max 2 levels deep
❌ /users/123/orders/456/items/789/reviews
✅ /order-items/789/reviews
HTTP Methods & Status Codes
Method Purpose Success Error GET Read 200 404 POST Create 201 400, 409 PUT Replace 200 400, 404 PATCH Partial update 200 400, 404 DELETE Remove 204 404
interface ApiResponse <T> {
data : T;
meta ?: {
page : number ;
limit : number ;
total : number ;
};
}
interface ApiError {
error : {
code : string ;
message : string ;
?: ;
};
}
details
object
Pagination
GET /users?page=2 &limit=20
GET /users?cursor=eyJpZCI6MTIzfQ&limit=20
{
"data" : [...],
"meta" : {
"nextCursor" : "eyJpZCI6MTQzfQ" ,
"hasMore" : true
}
}
Filtering & Sorting
GET /products?category=electronics&minPrice=100 &maxPrice=500
GET /products?sort=-createdAt,name
GET /users?age[gte]=18 &age[lte]=65
GET /users?status[in ]=active,pending
GET /users?name[like]=john*
GraphQL Design
Schema Design type User {
id : ID!
email : String!
name : String!
posts( first : Int, after : String) : PostConnection!
createdAt : DateTime!
}
type Post {
id : ID!
title : String!
content : String!
author : User!
comments : [ Comment! ] !
}
type PostConnection {
edges : [ PostEdge! ] !
pageInfo : PageInfo!
}
type PostEdge {
node : Post!
cursor : String!
}
type Query {
user( id : ID! ) : User
users( first : Int, after : String, filter : UserFilter) : UserConnection!
}
type Mutation {
createUser( input : CreateUserInput! ) : CreateUserPayload!
updateUser( id : ID! , input : UpdateUserInput! ) : UpdateUserPayload!
}
input CreateUserInput {
email : String!
name : String!
password : String!
}
type CreateUserPayload {
user : User
errors : [ Error! ]
}
Resolver Patterns
const userLoader = new DataLoader (async (ids : string []) => {
const users = await db.users .findMany ({ where : { id : { in : ids } } });
return ids.map (id => users.find (u => u.id === id));
});
const resolvers = {
Post : {
author : (post, _, { loaders } ) => loaders.user .load (post.authorId ),
},
};
const resolvers = {
User : {
email : (user, _, { currentUser } ) => {
if (currentUser.id !== user.id && !currentUser.isAdmin ) {
return null ;
}
return user.email ;
},
},
};
Error Handling
type CreatePostResult = Post | ValidationError | NotAuthorizedError
type CreatePostPayload {
post : Post
errors : [CreatePostError !]
}
union CreatePostError = ValidationError | RateLimitError
gRPC Design
Protocol Buffers syntax = "proto3";
package users.v1;
service UserService {
rpc GetUser(GetUserRequest) returns (GetUserResponse);
rpc ListUsers(ListUsersRequest) returns (ListUsersResponse);
rpc CreateUser(CreateUserRequest) returns (CreateUserResponse);
// Streaming
rpc WatchUsers(WatchUsersRequest) returns (stream UserEvent);
rpc BatchCreateUsers(stream CreateUserRequest) returns (BatchCreateResponse);
}
message User {
string id = 1;
string email = 2;
string name = 3;
google.protobuf.Timestamp created_at = 4;
}
message GetUserRequest {
string id = 1;
}
message GetUserResponse {
User user = 1;
}
message ListUsersRequest {
int32 page_size = 1;
string page_token = 2;
UserFilter filter = 3;
}
message ListUsersResponse {
repeated User users = 1;
string next_page_token = 2;
}
When to Use gRPC Use Case REST GraphQL gRPC Public API ✅ ✅ ❌ Mobile apps ✅ ✅ ⚠️ Microservices ⚠️ ❌ ✅ Real-time ❌ ⚠️ ✅ Browser clients ✅ ✅ ⚠️
API Versioning
Strategies # URL versioning (most common)
GET /v1/users
GET /v2/users
# Header versioning
GET /users
Accept: application/vnd.api+json; version=2
# Query parameter
GET /users?version=2
Breaking vs Non-Breaking Changes Non-Breaking (safe):
✅ Add new optional field
✅ Add new endpoint
✅ Add new optional query parameter
✅ Expand enum values (if client ignores unknown)
Breaking (requires new version):
❌ Remove field
❌ Rename field
❌ Change field type
❌ Make optional field required
❌ Change URL structure
Deprecation Strategy
app.get ('/v1/users' , ...);
res.setHeader ('Deprecation' , 'true' );
res.setHeader ('Sunset' , 'Sat, 01 Jun 2025 00:00:00 GMT' );
res.setHeader ('Link' , '</v2/users>; rel="successor-version"' );
Real-time APIs
WebSocket
wss.on ('connection' , (ws ) => {
ws.on ('message' , (data ) => {
const message = JSON .parse (data);
switch (message.type ) {
case 'subscribe' :
subscriptions.add (ws, message.channel );
break ;
case 'unsubscribe' :
subscriptions.remove (ws, message.channel );
break ;
}
});
});
const ws = new WebSocket ('wss://api.example.com/ws' );
ws.send (JSON .stringify ({
type : 'subscribe' ,
channel : 'orders:user:123'
}));
ws.onmessage = (event ) => {
const data = JSON .parse (event.data );
handleUpdate (data);
};
Server-Sent Events (SSE)
app.get ('/events' , (req, res ) => {
res.setHeader ('Content-Type' , 'text/event-stream' );
res.setHeader ('Cache-Control' , 'no-cache' );
res.setHeader ('Connection' , 'keep-alive' );
const sendEvent = (data : object ) => {
res.write (`data: ${JSON .stringify(data)} \n\n` );
};
eventEmitter.on ('update' , sendEvent);
req.on ('close' , () => {
eventEmitter.off ('update' , sendEvent);
});
});
const source = new EventSource ('/events' );
source.onmessage = (event ) => {
const data = JSON .parse (event.data );
handleUpdate (data);
};
API Documentation
OpenAPI (Swagger) openapi: 3.0 .3
info:
title: User API
version: 1.0 .0
paths:
/users:
get:
summary: List users
parameters:
- name: limit
in: query
schema:
type: integer
default: 20
responses:
'200':
description: Success
content:
application/json:
schema:
type: object
properties:
data:
type: array
items:
$ref: '#/components/schemas/User'
components:
schemas:
User:
type: object
required: [id , email , name ]
properties:
id:
type: string
format: uuid
email:
type: string
format: email
name:
type: string
Security Best Practices Practice Implementation Authentication Bearer tokens, API keys Rate limiting X-RateLimit-* headers Input validation Schema validation (Zod, Joi) CORS Whitelist allowed origins HTTPS Always in production Request IDs X-Request-ID for tracing
res.setHeader ('X-RateLimit-Limit' , '100' );
res.setHeader ('X-RateLimit-Remaining' , '95' );
res.setHeader ('X-RateLimit-Reset' , '1640000000' );
Related Skills
[[architecture-patterns]] - API Gateway, microservices
[[security-practices]] - Authentication, authorization
[[documentation]] - API documentation tools
Sharp Edges(常見陷阱)
SE-1: 破壞性變更 (Breaking Changes)
嚴重度 : critical
情境 : 修改現有 API 導致客戶端崩潰,沒有適當的版本控制
原因 : 刪除欄位、改變欄位類型、修改必填性、重新命名
症狀 :
客戶端突然出現錯誤
舊版 App 無法使用
用戶投訴「昨天還能用,今天就壞了」
檢測 : \-.*field|rename.*property|required.*true.*→.*false|type.*string.*→.*number
解法 : 使用 API 版本控制、只做 additive changes、設定 deprecation 期限
SE-2: 過度取得 (Over-fetching)
嚴重度 : medium
情境 : API 回傳太多客戶端不需要的資料
原因 : 「反正都有就回傳」的心態、沒有考慮不同使用場景
症狀 :
API 響應很大但客戶端只用其中一小部分
行動裝置載入緩慢
頻寬浪費
檢測 : select\s*\*|findMany\(\)|findAll\(\)(?!.*select)
解法 : 使用 fields selection、GraphQL、按需求設計 endpoint
SE-3: 取得不足 (Under-fetching)
嚴重度 : medium
情境 : 需要呼叫多個 API 才能取得完整資料
原因 : 過度細分 endpoint、沒有考慮常見使用場景
症狀 :
前端需要 5+ 個 API 呼叫才能渲染一個頁面
複雜的前端資料整合邏輯
N+1 API 請求問題
檢測 : Promise\.all\(.*fetch.*fetch.*fetch|\.then\(.*fetch
解法 : 設計聚合 endpoint、使用 include/expand 參數、考慮 BFF pattern
SE-4: 不一致的錯誤格式
嚴重度 : high
情境 : 不同 endpoint 回傳不同格式的錯誤,客戶端難以統一處理
原因 : 沒有統一的錯誤處理規範、不同開發者各自實作
症狀 :
有的錯誤用 error,有的用 message,有的用 errors
HTTP status code 使用不一致
客戶端需要寫很多 if-else 處理不同錯誤格式
檢測 : res\.json\(\{.*error|res\.json\(\{.*message|res\.status\(500\).*error
解法 : 定義統一的錯誤回應格式、使用 global error handler、建立錯誤碼系統
SE-5: 缺乏 Rate Limiting
嚴重度 : critical
情境 : API 沒有請求頻率限制,容易被濫用或攻擊
原因 : 「先做出來再說」、不了解風險
症狀 :
DDoS 攻擊導致服務癱瘓
單一用戶耗盡所有資源
雲端帳單爆炸
檢測 : app\.use\((?!.*rateLimit)|router\.(?!.*limit)|express\(\)(?!.*rate)
解法 : 實作 rate limiting middleware、使用 Redis 追蹤請求、設定合理的限制
Validations
V-1: 禁止 HTTP status 200 回傳錯誤
類型 : regex
嚴重度 : high
模式 : res\.json\(\s*\{\s*error|res\.send\(\s*\{\s*error|\.json\(\{.*success:\s*false
訊息 : Error responses should use appropriate HTTP status codes (4xx/5xx)
修復建議 : Use res.status(400).json({ error: ... }) for client errors
適用 : *.ts, *.js
V-2: API 路徑使用動詞
類型 : regex
嚴重度 : medium
模式 : (get|create|update|delete|fetch|remove|add)\/|\/get|\/create|\/update|\/delete
訊息 : REST API paths should use nouns, not verbs (use HTTP methods instead)
修復建議 : Change /getUsers to GET /users, /createUser to POST /users
適用 : *.ts, *.js
V-3: 缺少輸入驗證
類型 : regex
嚴重度 : critical
模式 : req\.body\.\w+(?!.*validate|.*schema|.*zod|.*joi|.*yup)
訊息 : Request body accessed without apparent validation
修復建議 : Add validation with Zod/Joi before using request data
適用 : *.ts, *.js
V-4: 硬編碼 HTTP status code
類型 : regex
嚴重度 : low
模式 : res\.status\(\d{3}\)
訊息 : Consider using named status codes for readability
修復建議 : Use HttpStatus.OK or constants instead of magic numbers
適用 : *.ts, *.js
V-5: 缺少 API 版本控制
類型 : regex
嚴重度 : medium
模式 : app\.(get|post|put|delete)\s*\(\s*['"]\/(?!v\d|api\/v\d)
訊息 : API route missing version prefix
修復建議 : Add version prefix: /api/v1/users or use header-based versioning
適用 : *.ts, *.js