Junto con X API v2, presentamos una nueva estrategia de control de versiones que permite a los desarrolladores comprender 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, 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 registrarán en el registro de cambios (changelog).
Actualmente, la X API tiene tres versiones distintas. Recomendamos encarecidamente utilizar X API v2 al planificar su integración, salvo que alguna 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 (Empresarial)
Estrategia de versionado
El versionado de la X API se representará mediante números de versión declarados en la ruta de los endpoints:
https://api.x.com/2/tweets
Nuestro objetivo es publicar 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 que rompan la compatibilidad en la API. Publicaremos guías de migración al lanzar una nueva versión principal para ayudar a los desarrolladores a actualizarse a la nueva versión.
Un cambio que rompe la compatibilidad 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 quiera aprovechar la nueva funcionalidad.
Si es necesario implementar un cambio que rompa la compatibilidad a mitad de ciclo (por motivos 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 actual 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 consulta
- 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 errors para que sea en línea)
- Cambio del nombre o del tipo de datos de un parámetro de entrada existente o de un valor de salida
- Cambio del nombre de un campo
- Cambio del nombre de un recurso
- Cambio de un código de respuesta
- Cambio de tipos de error
- Cambios en los ámbitos de autorización existentes
Cambios no disruptivos
- Incorporación de un nuevo endpoint
- Incorporación de un nuevo parámetro opcional
- Incorporación de un nuevo campo de respuesta
- Modificación del texto en los mensajes de error
- Disponibilidad de nuevos scopes
- “Anulación” de fields (cambiar el valor a null por motivos de privacidad/seguridad como alternativa a eliminarlo por completo)
Obsolescencia y retiro
Ante todo, aquí está nuestra definición de lo que significan obsolescencia y retiro para la X API:
- Obsolescencia: La función ya no cuenta con soporte por parte del equipo. No se lanzará nueva funcionalidad relacionada con esa función y, si hay errores o problemas con el producto, las probabilidades de que exploremos una corrección son extremadamente bajas.
- Retiro: La función dejará de estar accesible.
En la mayoría de los casos, tan pronto como 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, tras el cual se retirarán.
Por favor, mantente informado para conocer más sobre futuras obsolescencias y retiros.