manejo-de-errores
11.1: Los errores deben devolverse con el c贸digo de estado HTTP apropiado y un cuerpo de respuesta en formato JSON que incluya al menos los siguientes campos:
{
"error": {
"status": 400,
"error": "ValidationError",
"message": "Los datos proporcionados no son v谩lidos",
"code": "INVALID_USER_DATA",
"errors": [
{
"field": "email",
"message": "El formato del correo electr贸nico no es v谩lido"
}
]
},
"_meta": {
"timestamp": "2023-10-27T12:00:00Z",
"version": "1.0.0"
},
"_links": [
{
"rel": "self",
"href": "/v1/users",
"method": "POST"
}
]
}
11.2: Los c贸digos de error deben ser consistentes y estar documentados en la especificaci贸n OpenAPI.
11.3: Los mensajes de error deben ser descriptivos y 煤tiles para el cliente, pero no deben exponer informaci贸n sensible.
11.4: Para errores de validaci贸n, se debe incluir informaci贸n detallada sobre los campos que fallaron en el array errors.
11.5: Para errores de autenticaci贸n y autorizaci贸n, se deben usar los c贸digos de estado HTTP apropiados (401, 403) y proporcionar informaci贸n clara sobre el problema.
11.6: Los errores de servidor (500) deben ser gen茅ricos en producci贸n y no deben exponer detalles de implementaci贸n.
11.7: Se debe implementar un manejo consistente de errores en toda la API, siguiendo el mismo formato y estructura.
11.8: Los errores deben ser localizables, incluyendo mensajes en el idioma preferido del cliente cuando sea posible.
11.9: Se debe documentar todos los posibles c贸digos de error y sus significados en la especificaci贸n OpenAPI.
11.10: Los errores deben incluir un identificador 煤nico (traceId) en el campo _meta.traceId para facilitar el debugging y el soporte.