Desarrollador Backend: pregunta de entrevista
¿Cómo versionas una API pública?
Versiona solo cuando un cambio rompe clientes existentes. Prefiere campos aditivos y lectores tolerantes; si el cambio es incompatible, publica nuevo contrato, ventana de migración y fecha de retirada.
Respuesta directa
Qué debe cubrir una buena respuesta
Cómo funciona
El versionado existe para que los clientes sigan funcionando mientras el contrato evoluciona. La mayoría de cambios pueden ser aditivos y tolerados: campos opcionales nuevos, endpoints nuevos, valores de enum nuevos cuando los clientes ignoran los desconocidos. Un cambio incompatible, como renombrar un campo, cambiar un tipo o alterar la semántica, recibe una versión nueva en la URL, una cabecera o un media type, además de un calendario de deprecación y métricas de uso por versión para retirar la vieja con evidencia y no por esperanza.
Ejemplo
Añadir un campo opcional es compatible; cambiar significado o forma requiere nueva versión o migración negociada. Cuando un campo de importe tuvo que pasar de float en dólares a entero en céntimos, v2 expuso amount_cents mientras v1 siguió sirviendo el float seis meses con el uso por cliente registrado en logs.
Errores frecuentes
- Subir la versión mayor en cada release, de modo que los clientes afrontan migraciones constantes.
- Quitar un campo de la versión antigua porque la nueva ya está disponible.
- Versionar sin medir qué clientes siguen llamando a la versión antigua.
Una estructura útil para responder
Responde desde tu propia experiencia.
No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.
Abre el espacio de trabajo de escritorio y ensaya una respuesta clara con tus propias palabras.