Un endpoint resiliente no rompe apps viejas
Publicado el 24 de septiembre de 2026
𝗨𝗻 𝗲𝗻𝗱𝗽𝗼𝗶𝗻𝘁 𝗿𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝘁𝗲 𝗻𝗼 𝗿𝗼𝗺𝗽𝗲 𝗮𝗽𝗽𝘀 𝘃𝗶𝗲𝗷𝗮𝘀
¿Cambiaste un campo de una respuesta JSON y de repente empezaron a fallar apps que ni sabías que seguían activas? A mí me pasó 😅
En uno de los sistemas que mantengo tenía que evolucionar un endpoint: nuevos campos, lógica distinta, todo lo necesario para la versión nueva del cliente. El problema es que no todos los usuarios actualizan al mismo tiempo — había 𝗰𝗹𝗶𝗲𝗻𝘁𝗲𝘀 corriendo versiones viejas de la app que iban a seguir ahí por meses.
En un sistema 𝘄𝗲𝗯 esto casi no existe: el 𝗺𝗶𝘀𝗺𝗼 deploy actualiza frontend y backend juntos, así que los endpoints nuevos llegan al 𝗺𝗶𝘀𝗺𝗼 𝗺𝗼𝗺𝗲𝗻𝘁𝗼 para todos. Con 𝗮𝗽𝗽𝘀 𝗶𝗻𝘀𝘁𝗮𝗹𝗮𝗱𝗮𝘀 no hay ese lujo: el backend cambia hoy, pero el cliente viejo puede seguir ahí por semanas o meses hasta que el usuario actualice (o nunca lo haga).
Ahí entendí que un endpoint no es solo código, es un 𝗰𝗼𝗻𝘁𝗿𝗮𝘁𝗼 con quien lo consume. Si lo rompo, no rompo mi backend — rompo la experiencia de alguien que ni siquiera sabe que existo. Lo que me funcionó:
→ 𝗖𝗮𝗺𝗯𝗶𝗼𝘀 𝗮𝗱𝗶𝘁𝗶𝘃𝗼𝘀 primero: agregar campos, nunca eliminar ni renombrar los que ya existen
→ 𝗩𝗲𝗿𝘀𝗶𝗼𝗻𝗮𝗱𝗼 explícito (/v1, /v2) cuando el cambio sí rompe el 𝗰𝗼𝗻𝘁𝗿𝗮𝘁𝗼
→ 𝗗𝗲𝗽𝗿𝗲𝗰𝗮𝗿 con aviso y fecha, nunca de un día para otro
→ Monitorear qué versiones siguen recibiendo tráfico real antes de decidir cuándo apagar algo
La 𝗿𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝗰𝗶𝗮 de un endpoint no se mide solo en uptime — se mide en cuántas versiones distintas de tus consumidores puede sostener sin que nadie se entere del cambio 🔥
¿Ustedes cómo manejan la compatibilidad hacia atrás en sus APIs? ¿Versionado, feature flags, algo más? Cuéntenme 👇
¡Sigan volando, Campeones! ✈️