Header Ads Widget

Ticker

6/recent/ticker-posts

Estrategia de control de versiones continua para API internas


Recientemente, ha habido un debate sobre cuáles son las mejores prácticas para versionar una API. Muchas API web públicas se retiran a medida que las nuevas versiones las reemplazan, pero si le preguntaras a Roy Fielding, creador de REST, es posible que te diga que no versiones tu API en absoluto .

Algunas empresas están tomando el asunto en sus propias manos y buscando formas innovadoras de manejar el engorroso proceso de mantener actualizadas sus interfaces de programación de aplicaciones de una manera que tenga sentido para su modelo de negocio. Estas nuevas estrategias ponen más énfasis en la evolución que en la depreciación .

El enfoque de control de versiones típico v1, v2, v3, etc. se centra en lanzar grandes actualizaciones para mejorar la experiencia de la API. Pero la desventaja de este método es que provoca un cambio importante en el lado del cliente. Para las empresas de API internas que tienen un control granular sobre sus diversos clientes web, de escritorio y móviles, el control de versiones continuo podría ser una estrategia más atractiva.

En este artículo, revisaremos cómo se versionan típicamente las API web públicas dentro de nuestro dominio y discutiremos por qué las empresas pueden querer considerar una estrategia de control de versiones continua para manejar API complejas que están sujetas a una evolución iterativa continua. Dirigido por el orador de Platform Summit Konstantin Yakushev , usaremos Badoo como un caso de estudio para echar un vistazo a un enfoque alternativo para el control de versiones. Beneficios como la negociación de características y permitir pistas de desarrollo experimental podrían hacer que la estrategia de control de versiones continuo sea una ventaja, especialmente para los sistemas API privados.

Vea a Konstantin Yakushev de Badoo presente en la Cumbre de la Plataforma Nórdica de APIs:

Control de versiones típico de API públicas

En la mayoría de los escenarios públicos , un servicio de API se actualiza mediante la creación de una v2 completamente nueva y la desaprobación de la v1 original. Se realiza un seguimiento de los problemas con la versión 1: tal vez un pedido de producto esté mal escrito, la lógica empresarial haya cambiado o desee presentar nuevas funciones a sus consumidores. Todas estas ediciones se acumulan y se introducen en una v2 que resuelve estos problemas, pero introduce un cambio radical completo con la versión anterior.

Una API con un punto final como, por http//api.example.com/orders lo general, se reelabora con una extensión de URI a algo como http//api.example.com/v2/ordersLuego, se programa la jubilación de la versión 1 , generalmente de acuerdo con una política de obsolescencia . Aunque esta es la norma, hay algunos aspectos negativos importantes de este enfoque:

  • Línea de tiempo larga : en lugar de ediciones incrementales, con el control de versiones, debe esperar a que se agrupen todos los cambios. Esto significa que no puede ser ágil para responder a solicitudes y comentarios específicos de los usuarios .
  • Rompiendo : Te guste o no, lanzar una v2 es inherentemente romper la conexión, y requerirá que todos los clientes eventualmente actualicen sus conexiones.
  • Comunicación : se debe invertir tiempo y recursos para comunicar los cambios de API. Con una versión 2, se debe actualizar la documentación y se deben enviar a los consumidores avisos de cronología de obsolescencia.
  • Fielding como factor amigo : Roy Fielding define la capacidad de evolución como la capacidad de cambiar con el tiempo en respuesta a las necesidades cambiantes de los usuarios o un entorno cambiante sin volver a empezar. En realidad, va en contra de la propia recomendación de Roy Fielding de versionar su API, diciendo que es "solo una forma educada de eliminar las aplicaciones implementadas".

Muchas estrategias de control de versiones típicas se centran demasiado en la construcción de URL, que para Yakushev es " el paso menos importante, en mi opinión ". En cambio, puede ser mejor considerar todo el proceso desde un punto de vista más holístico. Cuando miramos el proceso de actualización de la API, vemos que tal vez no existe la versión 2 ; después de todo, muchas veces se recupera mucho y es posible que no valga la pena el esfuerzo de actualizar todos los clientes para introducir una versión completamente nueva.

Relacionado: Diseño de una verdadera máquina de estados REST

Estrategias de control de versiones continuas de Badoo

Cuando las empresas de API primero iteran constantemente con el control de versiones continuo , los problemas enumerados anteriormente se disuelven. Para ver cómo funciona esto en la práctica, consideremos algunos casos de uso específicos de Badoo, la red y aplicación internacional de citas.

Badoo ha estado desarrollando una API interna desde 2010. Nunca han tenido un cambio importante, ya que se han estado actualizando gradualmente durante todo este tiempo. Konstantin admite francamente que la API no es estrictamente RESTful, sino de estilo RPC y basada en Protobuf para clientes móviles, y basada en JSON para sus clientes web.

Con casi 600 comandos y más de 1200 clases, la API recibe alrededor de 9 actualizaciones cada semana y admite 5 tipos de clientes ( iOS, Android, Windows, Desktop Web y Mobile Web ) con una compatibilidad con versiones anteriores de clientes anteriores.

Echemos un vistazo a la estrategia de API interna de Badoo para ver cómo han utilizado una mentalidad de control de versiones continuo para actualizaciones específicas para evitar cambios importantes e importantes.

Cambiar el proceso de verificación

Yakushev describe cómo Badoo necesitaba reelaborar su proceso de verificación. En el pasado, si un usuario se registraba con su cuenta social, recibía una marca de verificación social asociada a su cuenta. A medida que pasaba el tiempo, los diseñadores querían tener controles más rigurosos. Por ejemplo, si un usuario tuviera que verificar con la verificación de foto, debería recibir una insignia diferente.

El problema era que la verificación original tenía una lógica binaria que afectaba a otros aspectos de la aplicación: los usuarios estaban verificados (verdadero) o no (falso). Dado que ese fue el caso, agregar una nueva complejidad de verificación significó instituir un cambio dramático en el comportamiento de su API.

El equipo de Badoo pudo resolver este problema utilizando una  API similar a GraphQL para enumerar los campos aceptables para los clientes. Ahora, cuando los clientes solicitan el estado de verificación, reciben más opciones personalizables. Permitir que los clientes negocien nuevos campos es una forma en que Badoo puede actualizar su API mientras mantiene la consistencia del punto final. Los clientes antiguos pueden utilizar campos antiguos, mientras que los clientes nuevos utilizan campos nuevos.

Lea también: ¿GraphQL es el final de las API de estilo REST?

Actualización de las CTA de banner para clientes específicos

Sin embargo, Yakushev reconoce desafíos más difíciles para mantener su API actualizada y consistente en varios clientes. Para cambios importantes, aconseja lanzar nuevas funciones en el servidor y hacer que los clientes finalicen explícitamente los tipos admitidos.

Por ejemplo, Badoo necesita ofrecer varios banners de llamado a la acción para diferentes tamaños de pantalla e interacciones específicas del dispositivo. Sin embargo, si se introduce un nuevo tipo de banner, cuando el cliente solicita banners, el servidor podría enviar un banner antiguo o desconocido. El control de versiones típico no es lo suficientemente flexible aquí.

Para resolver este problema, Badoo presentó una lista de tipos de banners admitidos para decidir fácilmente qué banners se mostrarán al cliente. Ahora, los banners específicos del cliente, como la lógica deslizable solo para dispositivos móviles, se pueden emparejar con el dispositivo receptor correcto utilizando la misma API, aunque con estado.

Uso de banderas y negociación de funciones para evitar el control de versiones

¿Qué pasa con los cambios de alto nivel más complejos en la lógica empresarial ? Yakushev explica cómo todos los perfiles de Badoo tienen un feed de fotos adjunto. Con el tiempo, el equipo de diseño quiso mezclar videos con las fotos y agregar un botón de reproducción para ver los videos desde la vista de cuadrícula.

Para resolver el problema sin versionar toda la API, Badoo introdujo una matriz de cambios admitidos . De esta manera, el cliente sabe que el servidor puede enviar videos junto con fotos. Un enfoque similar puede funcionar en muchos otros casos: básicamente, usted publica los cambios detrás de una marca de versión y hace que el cliente controle estas marcas.

Ejecución de funciones experimentales

Un beneficio del enfoque práctico de Badoo para todo el ciclo de vida de la API es la capacidad de ejecutar funciones experimentales rápidas en plataformas seleccionadas. Para hacer esto, crean una API experimental de superconjunto que solo se usa en una plataforma seleccionada, como el teléfono Windows, ya que tiene poco uso. Tener múltiples pistas de desarrollo permite probar nuevas funciones y monitorear el compromiso.

Cómo podría aplicarse el control de versiones continuo en su caso

Dependiendo de la situación, el control de versiones continuo podría ser un poderoso aliado para desarrollar y escalar API web ágiles. En lugar de provocar un cambio radical, se agregan campos para nuevas funciones y el cliente tiene una lista de elementos admitidos para enviar al servidor. Yakushev recomienda cubrir los nuevos cambios con indicadores de cambio y dejar que el servidor controle las funciones de activación y desactivación.

Al final del día, los desarrolladores de clientes y los propietarios de productos están contentos. Una estrategia de control de versiones iterativa puede ejercer presión adicional sobre los desarrolladores de back-end, pero es posible que les guste la capacidad de dividir su trabajo en pistas paralelas para superconjuntos de API y funciones experimentales.

En la práctica, Badoo tiene casi 260 indicadores de funciones y 160 funciones negociables. La implementación de la negociación de características en este nivel de complejidad se logra más fácilmente dentro de un escenario interno, donde la comunicación entre los equipos está unida y tanto los desarrolladores de clientes como los desarrolladores de API están trabajando hacia un objetivo final similar.

En la discusión de preguntas y respuestas se descubrió que el control de versiones continuo puede no ser un método ideal para los proveedores de API públicas . Dado que dentro del control de versiones continuo, los nuevos campos esencialmente equivalen a nuevas características, algunos creen que este nivel de negociación de características solo es aceptable cuando usted controla tanto la API como los clientes. Es posible que aún sea necesario pensar en realizar un control de versiones continuo dentro de un escenario de API pública ; sin embargo, es una propuesta atractiva.

Recurso adicional: Konstantin Yakushev creó esta página web dedicada a su charla. Échale un vistazo para ver enlaces a discusiones típicas sobre versiones y más sobre la API de Badoo.

¿Ha logrado un control de versiones continuo para su API pública? ¡Comparte tu historia a continuación!

Publicar un comentario

0 Comentarios