Junto con X API v2, lanzamos una nueva estrategia de control de versiones que permite a los desarrolladores entender mejor cuándo esperar cambios en las API públicas de X y cuándo deberán migrar a nuevas versiones.
Los desarrolladores serán notificados sobre desaprobaciones (deprecations), retiros, cambios y adiciones a la X API a través de nuestros canales de comunicación, para que puedan planificar adecuadamente cómo incorporar estos cambios en su hoja de ruta de desarrollo. Todos los cambios en la API se documentarán en el registro de cambios (changelog).
Actualmente, la X API tiene tres versiones. Recomendamos encarecidamente utilizar X API v2 al planificar su integración, salvo que la funcionalidad necesaria para su caso de uso aún no esté disponible en v2.
Para obtener más información sobre cada versión, visite las siguientes páginas:
- X API v2
- Gnip 2.0 (Enterprise)
Estrategia de versionado
El versionado de la X API se representará mediante números de versión incluidos en la ruta de nuestros endpoints:
https://api.x.com/2/tweets
Nuestro objetivo es lanzar versiones principales de la X API según sea necesario, pero no con una frecuencia mayor que cada 12 meses. Se publicará una versión principal cuando se introduzcan cambios disruptivos en la API. Publicaremos guías de migración al lanzar una nueva versión principal para ayudar a los desarrolladores a pasar a la nueva versión.
Un cambio disruptivo requiere que los desarrolladores modifiquen su código para mantener la funcionalidad existente en su App. Los cambios no disruptivos serán aditivos y se implementarán en la versión más reciente cuando estén listos, sin requerir trabajo por parte del desarrollador, a menos que desee aprovechar la nueva funcionalidad.
Si es necesario implementar un cambio disruptivo a mitad de ciclo (por razones de seguridad o privacidad), este cambio se aplicará a la versión más reciente.
Cambios incompatibles
Estos cambios requieren que los desarrolladores modifiquen su código para mantener la funcionalidad existente de su aplicación.
- Incorporación de un nuevo parámetro obligatorio
- Eliminación de un endpoint existente
- Eliminación de cualquier campo en la respuesta (ya sea obligatorio u opcional)
- Eliminación de un parámetro de query
- Reestructuración del formato de entrada o salida (por ejemplo, convertir un campo de nivel superior en un subcampo o cambiar la ubicación de los errores para que aparezcan en línea)
- Cambio del nombre o del tipo de dato de un parámetro de entrada existente o de un valor de salida
- Cambio del nombre de un campo
- Cambio del nombre del recurso
- Cambio de un código de respuesta
- Cambio de tipos de error
- Cambios en los ámbitos de autorización existentes
Cambios no incompatibles
- Incorporación de un nuevo endpoint
- Incorporación de un nuevo parámetro opcional
- Incorporación de un nuevo campo en la respuesta
- Modificación del texto de los mensajes de error
- Disponibilidad de nuevos ámbitos (scopes)
- “Anulación” de fields (cambiar el valor a null por motivos de privacidad/seguridad como alternativa a eliminarlo por completo)
Obsolescencia y retiro
Antes que nada, esta es nuestra definición de lo que significan obsolescencia y retiro para la X API:
- Obsolescencia: La funcionalidad ya no cuenta con soporte por parte del equipo. No se publicará nueva funcionalidad relacionada con esa característica y, si hay errores o problemas con el producto, la probabilidad de que abordemos una corrección es extremadamente baja.
- Retiro: La funcionalidad dejará de estar disponible.
En la mayoría de los casos, en cuanto se publique una nueva versión, la versión anterior se marcará como obsoleta. Las versiones permanecerán en estado de obsolescencia durante un período de tiempo, tras el cual se retirarán.
Por favor, mantente informado para obtener más información sobre futuras obsolescencias y retiros.