Versionado y obsolescencia de la API
Conozca cómo Inblog admite la API v1, anuncia futuras obsolescencias y planifica el fin del soporte.
Inblog versiona su API REST en la ruta de la URL para que las automatizaciones puedan usar un contrato predecible.
Soporte actual
v1 es la versión de la API REST actualmente compatible. Use los endpoints bajo /api/v1/... y el documento OpenAPI para crear integraciones.
Mantenemos la compatibilidad hacia atrás dentro de v1 para las operaciones compatibles. Podemos añadir campos de respuesta y otras mejoras que no rompen la compatibilidad sin crear una nueva versión de URL. No se ha anunciado ninguna fecha de obsolescencia o fin de soporte para v1.
La API no envía actualmente las cabeceras de respuesta Deprecation o Sunset para v1 solo porque exista esta política. Su ausencia significa que no se ha anunciado una señal de retirada.
Señales futuras del ciclo de vida
Si se programa la retirada de una versión compatible, Inblog puede usar estas cabeceras de respuesta:
Deprecationindica que la versión está obsoleta y puede incluir la fecha en que la obsolescencia entra en vigor.Sunsetindica la fecha prevista después de la cual la versión dejará de recibir soporte.
Son señales distintas: la obsolescencia anuncia un cambio en el ciclo de vida, mientras que Sunset identifica el fin de soporte previsto. Cuando estén presentes, registre ambas cabeceras y consulte la documentación o la guía de migración enlazada.
Periodo de aviso
Nuestra política normal es ofrecer un aviso mínimo de 180 días antes de eliminar v1 o realizar un cambio incompatible en una versión de API compatible. Es un mínimo conservador, no una promesa de que cada cambio ocurrirá exactamente con ese calendario.
Una vulnerabilidad de seguridad, una obligación legal o una situación de emergencia puede exigir un aviso más corto o un cambio inmediato. En esas condiciones, comunicaremos el impacto y las medidas disponibles tan pronto como sea posible.
Recomendaciones para clientes
- Fije las solicitudes a
/api/v1en lugar de inferir la versión a partir de las cabeceras de respuesta. - Trate los campos añadidos como compatibles y ignore los campos que su cliente no utilice.
- Supervise las cabeceras
DeprecationySunset, las notas de versión y esta política al planificar migraciones. - Use el documento OpenAPI como fuente legible por máquinas del contrato actual.
Enlaces relacionados
Última actualización 2026-08-25