API Patterns Gonzoblasco

API Patterns

API design principles and decision-making for 2025. Learn to THINK, not copy fixed patterns.

🎯 Selective Reading Rule

Read ONLY files relevant to the request! Check the content map, find what you need.

📑 Content Map

🚀 Quick Decision

Who are the API consumers?
│
├── Public API / Multiple platforms ────→ REST + OpenAPI
├── Complex data / Multiple frontends ──→ GraphQL
├── TypeScript monorepo ────────────────→ tRPC
├── Real-time / Event-driven ───────────→ WebSocket + AsyncAPI
└── Internal microservices ─────────────→ gRPC or REST

First question ALWAYS: ¿Quién va a consumir esta API?

🔗 Related Skills

✅ Decision Checklist

Before designing an API:

• Asked user about API consumers?
• Chosen API style for THIS context? (REST/GraphQL/tRPC)
• Defined consistent response format?
• Planned versioning strategy?
• Considered authentication needs?
• Planned rate limiting?
• Documentation approach defined?

⚠️ Racionalizaciones Comunes

❌ Anti-Patterns

NUNCA:

• Defaults a REST sin evaluar contexto
• Verbos en endpoints REST (/getUsers → /users)
• Formatos de respuesta inconsistentes
• Exponer errores internos al cliente
• Saltear rate limiting

SIEMPRE:

• Elegir estilo API basado en consumidores
• Preguntar requisitos del cliente
• Documentar exhaustivamente
• Usar status codes apropiados

Script