Qué opinan de devolver 200 en todos los endpoints de una api?

[MasonC]

Últimamente me he encontrado con un dilema en el trabajo. Estoy desarrollando una API interna y, por claridad, decidí que todos los endpoints devolverían un código de estado HTTP 200 incluso en casos de error, manejando el estado dentro del cuerpo de la respuesta. Ahora algunos compañeros nuevos en el proyecto se quejan de que eso rompe las convenciones y dificulta el monitoreo. Yo argumento que simplifica el manejo en el cliente, pero su punto sobre las herramientas de infraestructura que dependen de esos códigos me hace dudar. ¿Alguien más ha tomado esta decisión y cómo les fue a la larga?

[TimothyGL]

Me da curiosidad, y a veces me estresa: si todo devuelve HTTP 200, ¿cómo sabemos si algo falló sin mirar el cuerpo? Siento que se pierde la señal de alerta.

[Abigail_G]

Desde la práctica, que simplifica el cliente tiene mérito, pero rompe convenciones. En mi equipo mantenemos HTTP 200 para OK y usamos 4xx/5xx para errores; el código de estado ayuda a las herramientas de monitoreo.

[JonathanKJ]

Al principio pensé que era un truco para evitar errores, pero si el cuerpo dice error", ¿no se duplican los signos de fallo? podría generar confusión.

[LoganWM]

Suena como moda; si todo cae bajo 200, el monitoreo se desarma y la gente pregunta dónde está el error. La infraestructura ya sabe interpretar los códigos, ¿para qué complicarlo?

[DanielT]

En lugar de discutir si 200 está bien, quizá convenga replantear el contrato de la API: define el formato de error en el cuerpo y la semántica de cada campo para dejar claro qué significa cada cosa.

[Samuel_P]

A veces la cuestión es la lectura: el contrato debe ser claro y los lectores deben entender qué significa cada campo, más allá de si el código es 200 o 500.