Header Ads Widget

Ticker

6/recent/ticker-posts

Control de versiones simultáneo en toda la plataforma: cómo implementar la sincronicidad de API a SDK

 

control de versiones simultáneo en toda la plataforma

En el ámbito de las API, una de las prácticas más gratificantes que puede realizar un desarrollador es unificar la funcionalidad de su sistema . Tener actualizaciones, versiones de bibliotecas y documentación dispares puede dañar al usuario a través de la confusión y la obsolescencia, puede dañar al proveedor con actualizaciones aproximadas y puede dañar la API en sí debido a bajas tasas de adopción y retención. Es mucho mejor tener todo sincronizado.

La implementación simultánea de versiones en toda la plataforma elimina gran parte de los problemas de sincronización involucrados en el alojamiento de una API. Este es un proceso para mantener todo el sistema constante en términos de actualizaciones, documentación y bibliotecas. El resultado final mejora la experiencia del usuario, la seguridad y aumenta el potencial económico.

En este artículo, vamos a discutir exactamente cuál es la diferencia entre una API y un SDK, qué es el control de versiones y cómo afecta el espacio del usuario. Además, analizaremos en profundidad cómo el control de versiones inteligente afecta la experiencia del usuario y el índice de seguridad de una API, y cómo implementar esta sincronicidad sin problemas.

Definición de control de versiones

El control de versiones es el proceso mediante el cual se actualiza un sistema, y ​​estas actualizaciones se registran históricamente en un servidor o cliente para permitir la actualización de revisiones anteriores. Puede saber cuándo el control de versiones es parte del ciclo de desarrollo cuando una API, programa o servicio indica su número de versión, a menudo 0.01–0.99 para compilaciones beta y alfa, luego la versión 1.0 y superior para versiones públicas o de lanzamiento.

Los beneficios de un sistema de control de versiones son enormes. En primer lugar, el control de versiones es una herramienta de control de código fuente . Ya hemos hablado sobre el control de fuente , pero vale la pena repetirlo: poder unificar la experiencia del usuario detrás de una única versión oficial, le permite rastrear errores de manera más efectiva, desarrollar nuevas funciones con mayor facilidad y garantizar una experiencia cohesiva en múltiples propiedades.

Un gran beneficio adicional proviene de este estricto control de fuente:

  • La sincronización de versiones le permite permanecer dentro de los límites de las estrictas leyes relativas a la privacidad en todo el mundo al garantizar que todos los usuarios estén utilizando un sistema actualizado con revisiones internas, minimizando su riesgo como desarrollador.
  • Mantener las versiones unificadas evita que los usuarios utilicen versiones anteriores menos seguras, lo que a su vez reduce la posibilidad de ingeniería inversa y "piratería" general de su servicio y sistema .
  • Permite una documentación más estricta y precisa, la columna vertebral de cualquier API eficaz
  • Ayuda a mantener la función configurada para todos los consumidores de API.
Relacionado: ¿Qué idiomas deberían admitir mis bibliotecas auxiliares?

Control de versiones como UX: un estudio de caso

Veamos un ejemplo del mundo real de lo importante que es realmente el control de versiones y, por extensión, la sincronicidad entre API y SDK. Un sistema de control de versiones exitoso significa intrínsecamente que no se notará, así que veamos un sistema que falló.

En agosto de 2013, el proveedor de seguridad TrendMicro detalló un exploit en Java que rompió la seguridad de todo el ecosistema . El exploit apuntó a CVE – 2013–2463 , lo que permitió que los ataques remotos afectaran a la CIA de un sistema (CIA significa confidencialidad, integridad y disponibilidad, la explicación estándar de seguridad para sistemas integrados en red ).

Los grandes problemas con este exploit eran qué sistema afectaba y qué base de usuarios afectaba. Confinado a Java 6, una versión anterior de Java, el proveedor dejó el problema sin parchear, ya que el soporte para esa versión había terminado. Sin embargo, en ese momento, casi el 50% de los usuarios de Java utilizaban Java 6 para su sistema. Es posible que el soporte haya terminado, pero el uso no.

Debido a una falla en el soporte de versiones, y más específicamente en la unificación de parches, el proveedor dejó un gran exploit abierto de par en par, que afecta al 50% de la base total de usuarios. Con el tiempo, surgieron soluciones de terceros, pero el hecho de que el problema existiera es un testimonio de la importancia del concepto de control de versiones.

Para obtener un ejemplo más detallado de dónde ha fallado el control de versiones, consulte nuestro artículo titulado Zero Day Flash Exploits, Versioning y API Space .

Amor y matrimonio: unión de API y SDK

API-SDK-matrimonio-nordic-apis

Entonces, dado lo fundamentalmente importante que es la unificación de versiones , es posible que se pregunte cómo exactamente puede vincular la sincronicidad. Hay algunos enfoques y en gran medida se dividen en tres campos de pensamiento. La forma en que codifique, lo que presente sus sistemas y cómo se utilicen determinará cuál es el mejor enfoque.

¿Cuál es la diferencia entre una API y un SDK?

Antes de profundizar en los diversos enfoques para combinar API y SDK, primero debemos comprender qué significan estos términos.

Una API (Application Program Interface) es la interfaz que permite a los desarrolladores de software escribir programas. Es un conjunto de protocolos que definen cómo deben interactuar los servicios y los sistemas.

Un SDK (Software Development Toolkit) va un paso más allá de una API, por lo general facilita y agiliza el trabajo de los desarrolladores. Los SDK, que a menudo proporcionan bibliotecas de código , aplicaciones de referencia y documentación, son kits de herramientas útiles compuestos por todas las herramientas y API necesarias para crear una aplicación o microservicio.

Estas definiciones a menudo se superponen, lo que puede dificultar la diferenciación de las dos. La mejor manera de entenderlo es pensar en ese antiguo adagio matemático: "cada cuadrado es un rectángulo, pero no todo rectángulo es un cuadrado". En nuestro caso, cada SDK es una API, pero no todas las API son SDK.

Para ver un ejemplo del mundo real, consulte la suite Java SDK / API . La API es una colección de todos los lenguajes utilizados por Java para compilar y ejecutar conjuntos de código dados. Por otro lado, el SDK contiene la API en sí, así como el compilador, el tiempo de ejecución y los diversos servicios y ganchos diversos que deben vincularse al sistema.

Entonces, dada su superposición y sus propósitos a menudo dispares, ¿cómo unimos los SDK y las API ? A continuación se muestran algunos enfoques.

1: Sincronicidad a través de un ecosistema unificado

El ecosistema unificado es engañosamente simple: lanzar una sola aplicación nativa, donde el SDK y la API son uno y el mismo, con un servidor central que maneja el control de versiones. Este es el enfoque común para juegos y muchas aplicaciones multiplataforma. Es relativamente simple de manejar, pero es estrictamente efectivo en una situación multiplataforma singular .

Como ejemplo, imagine que desarrollamos una aplicación de presupuesto que utiliza un servidor API para manejar cálculos y sincronizar las revisiones de archivos de un dispositivo a otro. Al construir nuestra API, nos unificamos al tener el código nativo de la aplicación envuelto por un código específico del dispositivo utilizando un servicio o API adicional.

Un ejemplo de este tipo de sincronicidad es la API de Under Armour . Al empaquetar el código nativo en un contenedor para iOS y Android, una aplicación o API singular que utiliza la API de Under Armour se puede versionar en dispositivos que utilizan la misma aplicación central.

2: Sincronicidad a través de la actualización paralela

Curiosamente, la API de Under Armour en sí sigue un enfoque de sincronicidad diferente al que proporciona a otras aplicaciones y API. Un vistazo rápido a su política de control de versiones muestra una estrategia establecida en actualización paralela .

La actualización paralela puede no parecer una sincronicidad a primera vista; después de todo, en esta estrategia, una API puede tener varias versiones eliminadas del SDK y las diferencias pueden ser muy diferentes entre las dos. Sin embargo, la sincronicidad no tiene por qué ser una relación de uno a uno; todo lo que requiere la sincronicidad es que el proveedor gestione los cambios conjuntamente de alguna manera.

En consecuencia, la política de control de versiones de Under Armour establece los siguientes requisitos:

  • Todos los recursos de la API tienen la misma versión y se incrementarán juntos
  • Mantenga la versión sin cambios al introducir un cambio irreversible
  • Incrementar la versión secundaria (por ejemplo, 7.0 a 7.1) al introducir un cambio importante
  • Incrementar la versión principal (por ejemplo, de la 7.1 a la 8.0) al introducir una funcionalidad sustancial
  • Versión API y SDK de forma independiente, por ejemplo, la API V7.0 está encapsulada en la versión V2.0 del SDK
  • Permitir que existan varias versiones de API o SDK con diferentes funcionalidades

Esta estrategia es brillante en su ejecución:

  • Al requerir que los recursos de la API se incrementen juntos, creamos una situación en la que todas las API tienen versiones dependientes unas de otras, lo que garantiza que los sistemas que se comunican entre sí estén siempre sincronizados.
  • Incrementar por separado para las versiones que introducen cambios importantes en la funcionalidad central y funcionalidades útiles adicionales permite a los usuarios optar por nuevas características y sistemas mientras retienen la distribución central y, por lo tanto, la seguridad de la API central.
  • La encapsulación de los SDK versionados por separado con incrementos de API versionados permite la sincronicidad entre las versiones del SDK internamente, al tiempo que mantiene solo los datos del SDK más relevantes empaquetados con la API más relevante.
  • Permitir que existan diferentes versiones de API y SDK, siempre que su funcionalidad sea diferente, permite la sincronicidad entre API y SDK según el usuario, eliminando la sobrecarga del desarrollador en esa parte del proceso.

3: Sincronicidad a través de la actualización en serie

Se puede encontrar una solución adicional diametralmente opuesta a la actualización paralela de Under Armour. En la actualización en serie , tanto el SDK como la API se actualizan simultáneamente y se lanzan en una versión en serie.

Por ejemplo, imaginemos una API llamada APIu. Esta API es una API de unificación para cálculos de servidor para juegos, sistemas de procesamiento y proveedores de SaaS. APIu como API tiene su propia jerarquía de versiones y, en consecuencia, el SDK, conocido como SDKu, también tiene la suya propia.

A medida que la API se desarrolla a través de 1.0, el SDK también se actualiza a través de 1.0. A medida que se actualizan los dos, se sigue una regla simple: no actualice el SDK a menos que la API también se esté actualizando, y viceversa.

Con el tiempo, terminas con un sistema que se parece mucho a esto:

API v1.0 - SDK v1.0
API v2.0 - SDK v2.0

La actualización en serie tiene algunos beneficios importantes. Por un lado, no hay problema con los diferentes incrementos y variaciones en la API base y el SDK. Además, otorga mucho más control, ya que cada versión de API se examina con respecto a la versión del SDK y se garantiza la integración.

Sin embargo, hay un ENORME inconveniente: es increíblemente lento. La actualización paralela permite un desarrollo rápido, ya que el SDK y la API se desarrollan por separado y se incrementan para permitir cambios experimentales y posiblemente innovadores. Si bien esto hace que el sistema sea más complicado, lo hace mucho más rápido en comparación con la actualización en serie, que es lenta y engorrosa.

¿Cuál es su estrategia de desarrollo? Leer: 3 estrategias para desarrollar microservicios

Soluciones de terceros

Sin embargo, como siempre, existe una gran variedad de soluciones de terceros . Estas soluciones toman la API existente y generan un SDK a partir del código. Esto es excelente para los desarrolladores en términos de control de versiones, ya que utiliza una fuente estricta en forma de base de API para generar un SDK perfectamente unificado.

Logo-restituido

Un gran ejemplo de este tipo de solución es RESTUnited . Al utilizar un generador simple, RESTUnited puede generar bibliotecas de API REST de SDK en PHP, Python, Ruby, ActionScript, C #, Android, Objective-C, Scala y Java.

Si un desarrollador creara intencionalmente estos SDK, se requeriría mucho tiempo y errores, y el control de versiones sería una molestia. Sin embargo, al generar este código utilizando un servicio de este tipo, el SDK se puede mantener perfectamente en versión con la API; después de todo, el SDK en este caso se deriva directamente de la API, lo que significa que, por diseño, tiene que estar integrado en -versión.

apimatic-logo

Similar a RESTUnited, APImatic es otro servicio de generación de SDK. La principal diferencia aquí, sin embargo, es que APImatic es posiblemente más flexible que RESTUnited, utilizando varios conjuntos de características adicionales para permitir la generación de SDK personalizable y restricciones más flexibles.

Asegurando-la-fortaleza-API-blog-post-CTA-01

El problema con los SDK generados

Si bien la generación automática de SDK puede parecer una perspectiva maravillosa, la verdad es que hay muchos problemas con este enfoque en comparación con los SDK codificados a mano.

Lo más evidente es que la generación de SDK requiere que su API sea funcionalmente perfecta. La falta de definiciones de modelo, la falta de códigos de error y más podrían causar definiciones de SDK incorrectas. Si bien esto puede tener poco impacto en la API, en un SDK, podría inutilizar todo el documento.

La generación de código es una bolsa mixta en primer lugar. Debido a que no existe un enfoque de diseño estándar de la industria aceptado por los desarrolladores de API (aunque grupos como Open API Initiative han logrado avances significativos en esta dirección ), los generadores de SDK tienen que usar suposiciones comunes y partir de allí, en lugar de desarrollar implementaciones específicas de SDK dadas. los rigores de la API. Esto conduce a un SDK de orientación general, en lugar de específico.

Todo esto puede ser motivo suficiente para considerar uno de los estándares de control de versiones mencionados anteriormente integrados con los SDK creados; Sin embargo, si su equipo se siente cómodo con su diseño y ha sido examinado según los principios de diseño comunes, la generación de SDK podría ser una solución aceptable.

Conclusión

Hablando fundamentalmente, el problema que nos ocupa no es mantener la sincronicidad entre versiones, sino más bien, a un nivel superior, unificar la experiencia de su base de usuarios y brindar un ecosistema de seguridad . Si bien el control de versiones y la sincronicidad son ciertamente parte de eso, el hecho es que si sigue un método de documentación consistente , se adhiere a las especificaciones de diseño y codifica con una alta calidad, muchos de los enfoques mencionados anteriormente vendrán de forma natural.

Hemos dicho muchas veces antes que un sistema es tan seguro como su parte más débil ; esto también se refleja en la experiencia del usuario. La experiencia del usuario es tan buena como su parte más débil, y permitir que su experiencia se desvíe debido a simples diferencias en las versiones es posiblemente una de las cosas más fáciles de corregir en el vasto mundo de posibles fallas en el espacio API.

Publicar un comentario

0 Comentarios