Estandarizador de Respuestas de Error de API

Prompt Template

Eres un experto en diseno de APIs que crea experiencias de error amigables para desarrolladores. Disena un sistema estandarizado de respuestas de error.

Tipo de API: {{tipo_de_api: REST/GraphQL}}
Stack: {{stack}}
Formato actual de errores: {{actual: inconsistente/basico/ninguno}}
Consumidores de la API: {{consumidores: frontend/movil/terceros}}
Documentacion: {{documentacion: OpenAPI/ninguno/personalizada}}

## Formato de Respuesta de Error
```json
{
  "error": {
    "code": "RESOURCE_NOT_FOUND",
    "message": "El usuario solicitado no fue encontrado.",
    "details": [],
    "request_id": "req_abc123",
    "documentation_url": "https://api.ejemplo.com/docs/errors#RESOURCE_NOT_FOUND"
  }
}
```

## Catalogo de Errores
| Codigo de Error | Estado HTTP | Template de Mensaje | Cuando Usar |
| VALIDATION_ERROR | 400 | Campo {field} {reason} | Entrada invalida |
| UNAUTHORIZED | 401 | Autenticacion requerida | Token faltante/invalido |
| FORBIDDEN | 403 | Permisos insuficientes | Token valido, rol incorrecto |
| NOT_FOUND | 404 | {resource} no encontrado | Recurso no existe |
| CONFLICT | 409 | {resource} ya existe | Creacion duplicada |
| RATE_LIMITED | 429 | Limite de tasa excedido, reintentar despues de {seconds} | Demasiadas solicitudes |
| INTERNAL_ERROR | 500 | Ocurrio un error inesperado | Excepcion no manejada |

## Implementacion
```{{idioma}}
// Jerarquia de clases de error
// Middleware/handler de errores
// Funciones auxiliares para errores comunes
```

## Guia de Integracion para Clientes
- Como el frontend debe manejar cada codigo de error
- Estrategia de reintentos por tipo de error
- Mapeo de mensajes orientados al usuario

## Consideraciones de Seguridad
- Nunca exponer stack traces en produccion
- No revelar si un recurso existe en errores de autenticacion
- Politica de divulgacion de informacion de rate limit

Tips

• Consistent error formats save frontend developers hours of special-case handling
• Include request_id in every error response for debugging - without it production errors are needles in haystacks
• The security considerations section prevents information leakage that attackers exploit
• Document every error code publicly so API consumers can handle them programmatically