Cómo estandarizar errores en una API sin complicarlo?

[SofiaJ]

Últimamente me he encontrado con un dilema en mi trabajo diario. Estoy desarrollando una API interna y, aunque funciona, siento que el código para manejar los errores se está volviendo un desastre repetitivo. Cada endpoint tiene su propia manera de devolver los estados y mensajes, y ya es difícil mantenerlo. Me pregunto si alguien más ha pasado por esto y cómo abordaron la estandarización de este aspecto, sin que se convierta en una sobreingeniería.

[CamilaL]

Para el manejo de errores conviene un contrato mínimo que funcione como verdad de la API. Un cuerpo de respuesta con code y message y tal vez un detalle, y que todos los endpoints devuelvan ese mismo formato mediante un middleware que traduce cualquier excepción. Así reduces repetición y facilitas pruebas

[SophiaH]

Mi impresión es que la obsesión por estandarizar errores a veces es sobreingeniería. si el equipo ya entiende lo que pasa los mensajes pueden ser simples y claros, no hace falta un framework enorme

[AaronZM]

Estoy cansado de ver cada endpoint con su formato de error, el manejo de errores se vuelve una pesadilla y no es necesario

[Andrew14]

Quizá el truco es pensar en un contrato para el manejo de errores que sirva a quien consume la API y al equipo que escribe la lógica sin convertirlo en una carga enorme. ¿tiene sentido empezar por algo pequeño?

[Luke57]

Los lectores de la API interna buscan consistencia y mensajes que no hagan pensar dos veces. El manejo de errores estandarizado actúa como una guía para el usuario de la API sin perder la voz del equipo

[David84]

Cuidado con exponer detalles sensibles en el manejo de errores y con complicar el UI de las respuestas. Un enfoque sobrio, con codes bien pensados y logs claros, puede funcionar sin ser una jaula