Header Ads Widget

Ticker

6/recent/ticker-posts

¿Le funcionaría una estrategia de API experimental?

 


El diseño de API es un tema complejo, lo que funciona para algunos proveedores no funciona para otros. Parece que cada año se desarrollan nuevos enfoques y surgen nuevas ideas sobre cómo encajan las API en la estrategia general de la plataforma. Estamos viendo que esto ocurre específicamente en la banca , ya que las tendencias del mercado obligan a formas más ágiles de dar vida al software innovador.

El ciclo tradicional es construir, recopilar comentarios, iterar y luego recopilar comentarios. El problema es que este ciclo es ineficiente y cada etapa se desarrolla casi de forma aislada. Un proceso de diseño más experimental podría frenar esta ineficiencia, y eso es lo que la gente de Capital One DevExchange está intentando.

Hoy, vamos a discutir un enfoque de prueba y diseño de API que Capital One ha denominado una " estrategia de API experimental " en una publicación de blog de DevExchange . Veremos cómo definen una API experimental y pensaremos en los diversos beneficios e inconvenientes de su implementación. También notaremos algunas situaciones potenciales que podrían beneficiarse de las API experimentales.

¿Qué es una API experimental?

Una API experimental es exactamente lo que parece: una API destinada a facilitar el trabajo experimental. Por lo general, es un servicio simulado que utiliza datos simulados para el procesamiento y el desarrollo; esto es similar al enfoque utilizado por los desarrolladores de base de código del servidor cuando usan datos artificiales en un servidor de ensayo para cargar pruebas y crear nuevos servicios de forma iterativa.

La idea aquí es involucrar a la comunidad y, en muchos casos, la API experimental también permitirá datos reales (aunque de naturaleza limitada) para la funcionalidad y el procesamiento experimentales. Esto permite que la comunidad interactúe con el código base y genere nuevas adiciones y funciones a través de comentarios informados y específicos .

Esta retroalimentación informada es un beneficio principal detrás de las API experimentales en Capital One. Les permite probar e iterar las API de Money Movement y Virtual Card Numbers .

“Las API experimentales son servicios simulados que utilizan datos simulados para imitar las funciones de la API. Están diseñados con el objetivo de obtener comentarios tempranos de la comunidad sobre la conveniencia y el diseño de la API antes del lanzamiento del producto ".

Al evitar un ciclo de vida tradicional, los desarrolladores de software pueden crear un ciclo de desarrollo holístico que recopile comentarios de forma dinámica a medida que ocurre cada iteración en el proceso de construcción. A diferencia de un ciclo tradicional, las API experimentales podrían brindar un ciclo de desarrollo más efectivo. Sin embargo, estos beneficios no están completamente asegurados o garantizados, hablaremos de eso en un momento.

Relacionado: La promesa de la banca abierta: un estudio de caso de Nordea

Beneficios de un enfoque de API experimental

El beneficio obvio detrás de un enfoque de API experimental es la baja latencia entre la construcción y la prueba. Dado que la información y la respuesta se recopilan durante el proceso de construcción e iteración, la retroalimentación es mucho más dinámica . Esto tiene la respuesta final de hacer que el desarrollo se base en la respuesta del consumidor , en lugar de una guía generalizada.

"Con estas API, estamos ampliando una relación más íntima con los desarrolladores y socios potenciales".

Además, las brechas en la cobertura y la función se pueden identificar a través de esta retroalimentación, lo que permite desarrollar un código más completo . El hecho de que todo se tome de manera integral también permite una mayor cantidad de compatibilidad , lo que permite que las características coexistan en equilibrio en lugar de tener que codificarlas más adelante para llenar un vacío en la función.

Este tipo de enfoque de diseño también puede ayudar a reducir el alcance del proyecto, evitando el deslizamiento de características. A menudo, el problema surge porque el desarrollador piensa que se necesita algo cuando el usuario aún no lo ha identificado como tal, o porque el contenido adicional en sí mismo requiere más sistemas codificados para admitirlo. Al ceñirse estrictamente a los comentarios de los usuarios y restringir el desarrollo a lo que se solicita, el proveedor podría aliviar esto.

Además, este enfoque es ideal para realizar pruebas . Dado que la mayor parte de los datos no son reales o están muy limitados, se pueden evitar muchas de las amenazas de seguridad inherentes a las pruebas con datos reales.

Lea también: Cómo diseñar API sin fricción

Inconvenientes de un enfoque experimental

Si bien existen muchos beneficios potenciales al adoptar un enfoque experimental, también hay muchos posibles aspectos negativos que deben considerarse. Dependiendo de los comentarios de los usuarios para la iteración, se obtiene un producto más personalizado, pero también puede crear un bucle infinito de iteración constante si no hay una fecha de finalización establecida y una limitación de recursos comprendida.

La limitación del esfuerzo para la nueva función no solo debe ser entendida por el desarrollador, sino que también debe comunicarse claramente al usuario; en otras palabras, el usuario que utiliza la API experimental debe ser plenamente consciente de que no se utilizarán todos los comentarios. , y que algunas características deberán permanecer en su lugar considerando la seguridad y eficacia de los sistemas en cuestión.

Si bien el uso de datos falsos ayuda mucho en términos de seguridad, exponer la API a medida que se crea y evoluciona su enfoque de seguridad también puede crear una verdadera hoja de ruta para una exposición futura . Los posibles atacantes del mañana habrán observado la evolución de la seguridad desde el primer día y serán conscientes de las complejidades y excentricidades que de otro modo no habrían sido expuestas. Si bien esta no es realmente una razón sólida para ignorar el enfoque por completo (en muchos casos, el desarrollo de la seguridad puede ofuscarse de manera efectiva hasta el punto en que no es un problema), debe considerarse una vulnerabilidad si no se aborda.

Además, existe la evidente expansión de la dependencia del control de versiones que debería reconocerse. Una API experimental es esencialmente una gran cantidad de compilaciones versionadas apiladas juntas en un ciclo de vida de desarrollo activo, por lo que todo tiene que ser versionado, rastreado, actualizado, etc. con mayor frecuencia que los enfoques de desarrollo tradicionales. Esto puede abrumar fácilmente a los equipos de desarrolladores más pequeños y provocar la pérdida del control de versiones a medida que el desarrollo se vuelve más complejo.

Más sobre estrategia bancaria: Creación de un marco de microservicios en CIBC

Establezca metas para evitar un alfa eterno

Cuando hablamos de una estrategia de API experimental, debemos considerar la idea del alfa eterno . Sin el control de iteración y los objetivos adecuados, este tipo de desarrollo es esencialmente una compilación alfa eterna de su producto final. Si bien esto se discutió un poco dentro del concepto de creep, el problema es mucho más fundamental: ¿en qué momento se crea un producto mínimo viable y en qué momento es hora de cancelar el desarrollo o separar las funciones en un nuevo microservicio?

Esto será diferente para cada desarrollador, por lo que es difícil dar consejos aquí sobre ese tema en particular. Dicho esto, tener cualquier tipo de directriz y objetivo final ayudará a mitigar gran parte de este problema potencial. Tenga un plan establecido sobre lo que constituye la diferencia entre la API experimental y la API de lanzamiento , y quién va a usar qué.

Podría tener sentido aislar la API experimental de la base de usuarios por completo y, en su lugar, solicitar comentarios para el desarrollo y, en algunos casos, podría tener sentido hacer que la versión sea una compilación experimental. Independientemente, en cierto punto, necesitará establecer el alcance y decidir qué hace exactamente que un alfa se transforme en una beta y una beta en un candidato de lanzamiento.

Un enfoque bifurcado

Un método de implementar un API experimental es tener tanto una rama de lanzamiento y la rama experimental . Una rama de lanzamiento es una compilación estable, que solo cambia a partir de los resultados del experimento. La otra rama debería ser la experimental, en constante evolución y cambio, utilizando nuevos métodos y datos de usuario limitados combinados con métodos existentes y datos falsos.

Este enfoque permite a las empresas y socios utilizar la API estable para funciones básicas, pero también permite a los usuarios optar por usar la rama experimental para una funcionalidad adicional, asumiendo, por supuesto, que entienden que no es estable, que podría romperse y que no está cerca de su lanzamiento. . Esto también evita el problema del alcance, ya que el producto mínimo viable ya está allí, y todo lo demás es iteración para agregar más funcionalidad.

Juzgar lo apropiado

Por supuesto, habiendo dicho todo esto, hubo algunas "banderas" específicas que sugieren si una API experimental es un enfoque apropiado o no. Por un lado, cualquier API que trabaje con información de alta seguridad , especialmente PHI , al menos querrá usar nada más que datos falsos para la API experimental, si no evita el enfoque por completo. Incluso con datos falsos, el uso de una API experimental expondrá la seguridad subyacente al sistema en sí y podría exponer cómo se almacenan, exponen y procesan los datos.

Para las API que se vinculan con otros sistemas de API, es posible que los proveedores deseen ocultar parte de esa interacción, ya que citar puntos finales internos que pueden no estar documentados puede ser preocupante para los socios en cuestión. En estos casos, la exposición es más preocupante para las API de los socios, pero no obstante, contribuye en gran medida a la inseguridad en todas las API de la red.

Las API que pretendan ser lean también deben evitar el desarrollo experimental. El problema aquí es que las API de bajo financiamiento o aquellas que se enfocan en lean por diseño necesariamente significan que el alcance tiene que estar muy bien definido y limitado, y los enfoques experimentales van en contra de eso.

Las API centradas en la comunidad que se centran en las necesidades de la comunidad en lugar de en casos comerciales específicos podrían beneficiarse de este enfoque de desarrollo, ya que da como resultado una mayor velocidad y eficacia de desarrollo. Además, las API basadas en soluciones de vanguardia podrían obtener enormes beneficios de este enfoque, ya que es posible que no esté claro cómo aplicar la tecnología o solución específica para la situación dada a menos que la comunidad se exprese y brinde comentarios.

Finalmente, quizás el argumento más fuerte para este tipo de desarrollo es la API de empresa a empresa . Con una API experimental, las empresas asociadas y su comunidad pueden indicar lo que quieren, lo que funciona, lo que no, etc., lo que puede unificar los sistemas heredados y modernos (asumiendo que usted se está ofuscando de la manera que necesita por seguridad).

El pensamiento de diseño de API se vuelve experimental

Para Capital One, sus API experimentales son parte de su proceso de pensamiento de diseño , que definen como "una práctica en el desarrollo de productos que centra las necesidades de los usuarios en los productos que está intentando crear". Esto ayuda a crear prototipos sin contratos, pruebas de usuario tempranas y comentarios iterativos.

En última instancia, el concepto detrás de una API experimental es un enfoque prometedor que debe combinarse con una situación sensata. Si bien una API experimental podría tener enormes beneficios para muchos proveedores, no todos se beneficiarán de este tipo de enfoque de desarrollo. De hecho, muchos proveedores ultrafinos podrían sufrir este tipo de implementación.

Dicho esto, si los requisitos de su organización y el espíritu de diseño de API coinciden con este enfoque, y la API experimental es apropiada en su caso particular, adoptarla puede resultar en grandes ganancias en eficacia, velocidad de desarrollo y funcionalidad general.

Publicar un comentario

0 Comentarios