Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo proporcionar a las API un sistema de información existente

 

Cómo-proporcionar-API-con-un-sistema-de-información-existente-nordic-apis-arnaud-lauret

En un artículo anterior , alentamos a todas las empresas a unirse a la revolución digital y proporcionar API. Pero cuando se enfrenta a un Sistema de información (SI) existente , los pasos para exponer un proceso comercial con una API se vuelven mucho más complejos. Un SI puede estar repleto de procesos organizativos y estructuras de datos preexistentes que, si se exponen directamente, pueden generar una experiencia de usuario muy deficiente y posiblemente un punto muerto total.

Por lo tanto, el diseño de API para que funcionen con un IS preexistente no puede tomarse a la ligera. En este artículo, analizaremos qué factores de usabilidad considerar y qué complejidades evitar, demostrando que proporcionar API que funcionen con un IS existente no es una quimera condenada al fracaso.

Un sistema de información existente NO es una buena API

Un sistema de información puede ayudar a una empresa al permitir formas de administrar datos y procesos comerciales. Dado que las API son otro método para manejar datos, algunos arquitectos adoptan la postura de que proporcionar API equivale a exponer el sistema de información tal como está . Sin embargo, exponer un sistema de información tal como es no es una buena idea ya que el SI puede ser:

  1. Complejo
  2. Inseguro
  3. Lento para evolucionar
Leer ¿Deberían todas las empresas considerar la posibilidad de proporcionar API?

Razón n. ° 1: el sistema de información existente es demasiado complejo

Es un bárbaro y cree que las costumbres de su tribu y su isla son las leyes de la naturaleza.

George Bernard Shaw, César y Cleopatra

Después de años de evolución, un SI puede sobresalir en el cumplimiento de las necesidades de su empresa. Pero después de todos estos años de evolución, un SI se vuelve complejo, para personas externas e incluso internas , no apto para la exposición directa como API. Un SI es naturalmente complejo porque refleja la organización, los detalles funcionales, la tecnología y la historia de una empresa.

Con todo este bagaje, un consumidor se molesta cuando usa una API que depende demasiado de un IS interno. Como caso de estudio, examinaremos una API hipotética que permite a un cliente realizar un pedido para comprar un producto con una API que imita la forma en que podría comportarse un SI.

Complejidad organizacional

El SI de una empresa es un reflejo de la organización de la empresa que la mayoría de los usuarios finales no necesitan conocer. Al realizar un pedido, un consumidor de API no debería tener que lidiar con detalles organizativos internos como:

  • Dirigir el pedido a una sucursal específica . Si la dirección de envío está en Europa, el ordenante no debería tener que especificar la dirección de la sucursal alemana en lugar de la sucursal estadounidense.
  • Tratar con las ubicaciones de procesamiento . El envío de un pedido será procesado por dos departamentos en los EE. UU. Y uno en Alemania.

Complejidad funcional

Los usuarios externos no pueden estar tan familiarizados con un SI como los empleados que han trabajado durante años en una empresa. A menudo, incluso estos empleados no conocen todas las reglas funcionales de la empresa. Por lo tanto, al realizar un pedido, los consumidores de API no deberían tener que lidiar directamente con detalles funcionales como:

  • Detalles que determinan los costos de envío . Cuando el pedido se envía desde Alemania, el costo de envío se basa en el peso y el tamaño, pero cuando se envía desde EE. UU., Los costos de envío se basan únicamente en el peso.
  • Disponibilidad basada en la ubicación de la sucursal . Si un artículo no está en stock en Alemania pero sí en stock en EE. UU., Finalmente se puede realizar un pedido a través de la sucursal de EE. UU.

Complejidad Tecnológica

El SI de una empresa puede ser un SI heterogéneo compuesto de componentes heterogéneos que proponen interfaces heterogéneas. Esto puede tomar la forma de varios protocolos y métodos de comunicación (síncronos, asíncronos, HTTP, RPC, RMI, Corba,…), diferentes tipos de formatos de datos (XML, JSON, binarios, texto,…), diferentes representaciones de los datos de la empresa. y manejo heterogéneo de errores. Al realizar un pedido, los consumidores de API no deberían tener que preocuparse por detalles tecnológicos como:

  • Pasos adicionales innecesarios . Un pedido se inicia llamando a un servicio XML RPC que luego indica a qué sistema llamar (americano o alemán).
  • Incongruencias entre estructuras de datos . Una orden europea y una orden americana no comparten las mismas estructuras de datos, convenciones de nomenclatura, controles o manejo de errores.
  • Limitaciones molestas para la entrada de datos . Una orden europea se transmite a la sucursal alemana enviando un mensaje binario a través de MQSeries, cuya estructura es un reflejo de una tabla DB2 que limita el nombre del campo a una longitud de 6 y el valor del campo a una longitud de 32.
  • Procesos de solicitud molestos . Un pedido estadounidense se transmite a la sucursal de EE. UU. Mediante la publicación de datos CSV en una URL.

Complejidad histórica

El SI de una empresa se forja después de numerosos proyectos, cambios organizativos y cambios tecnológicos. Estas evoluciones generan procesos que satisfacen las necesidades de la empresa, pero son un lastre desde la perspectiva de un extraño. Inmerso en los antecedentes históricos de una empresa, la lógica de un SI a menudo no es comprensible desde el punto de vista del usuario. Teniendo en cuenta estos detalles históricos perpetuados, al realizar un pedido, los consumidores de API no necesitan:

  • Conozca el razonamiento detrás de procesos específicos . Al transmitir un pedido a la sucursal alemana, el número de artículos se indica en el campo productDesignation porque era más rápido usar este campo no utilizado en lugar de agregar uno nuevo.
  • Realice acciones repetitivas para adaptarse a la estructura histórica de solicitudes . Al transmitir un pedido a la sucursal de EE. UU., Y debido a que el servicio de entrega se divide en dos subservicios, los datos CSV deben publicarse en dos URL diferentes.
Más información sobre cómo equilibrar la complejidad y la simplicidad en el diseño de API

Razón n. ° 2: el sistema de información existente no es seguro

Un barco está seguro en el puerto, pero para eso no son los barcos.

William GT Shedd

Protegido durante años en un entorno cerrado también puede conducir a un SI que no es lo suficientemente seguro para la exposición al aire libre. Lo siguiente puede generar grandes problemas de seguridad:

  • Falta de IAM (gestión de identidades y accesos)
  • Riesgos de inconsistencia
  • Componentes débiles

Falta de IAM

Al exponer un SI al exterior, una empresa debe asegurarse de que maneja la gestión de identidad y acceso para autorizar y autenticar a los usuarios, así como sus permisos en todas las interacciones con la API. No sería seguro otorgar acceso completo a la lista de pedidos de la empresa a cualquier consumidor de API, permitiendo que cualquier consumidor acceda o modifique cualquier pedido. Más bien, una API debe exponer solo lo que necesita exponerse .

Riesgos de inconsistencia

Un SI puede depender demasiado de aplicaciones frontend caseras (cliente enriquecido, aplicaciones web) para garantizar la consistencia del sistema. Por ejemplo, supongamos que al realizar un pedido en la sucursal de EE. UU., Los datos CSV deben publicarse en dos URL diferentes en un orden determinado dentro de un período de tiempo determinado. De lo contrario, los datos del pedido serán incoherentes y, por lo tanto, imposibles de procesar. No sería seguro dejar que un consumidor de API externo manejara esto.

Componentes débiles

Es probable que algunos componentes de SI existentes no acepten un nivel más alto de solicitud. Un uso indebido o una celebridad repentina de la API puede provocar su ruptura o, peor aún, una ruptura completa de IS paralizando a toda la empresa.

Razón # 3 El sistema de información existente tarda en evolucionar

Los que no se mueven, no notan sus cadenas.

Rosa Luxemburgo

Debido a su complejidad en el corazón de la empresa, un SI existente no se puede modificar fácilmente y, por lo tanto, su evolución es lenta . Dado que es un proceso clave que involucra cuestiones organizativas, técnicas y funcionales en toda la empresa, si nuestro negocio de comercio electrónico genérico quisiera simplificar el proceso de pedido, podría llevar meses o incluso años corregir todos los componentes e inquietudes.

Cómo transformar un IS existente en una buena API

DESCANSO en el frente, JABÓN en la parte posterior. Solo ten cuidado con la policía de la moda de cortes de pelo ...

El salmonete API, Mark O'Neil

Una empresa no debe exponer su IS existente tal como está , pero eso no significa que un IS existente no pueda usarse como motor para impulsar las API. Este motor se ocultará detrás de una nueva capa: la capa API . Los principales objetivos de la nueva capa de API son:

  • Simplificar IS
  • IS seguro
  • Acelerar IS
Banner básico-01

La capa de API simplifica IS

Si no puede explicárselo a un niño de seis años, no lo comprende usted mismo.

Albert Einstein

Una API no debe ser un reflejo del SI de la empresa; una API debe ser una representación de su negocio desde el punto de vista del usuario final. Esta representación debe simplificar y uniformizar las interfaces de SI desde el punto de vista técnico y funcional.

Teniendo en cuenta la usabilidad , podemos reemplazar nuestra dolorosa cinemática de pedidos con algo más simple como POST / pedidos . Podemos construir una interfaz comprensible sin consideraciones innecesarias sobre asuntos internos organizativos, funcionales o técnicos. La capa de API se encargará de todos los asuntos de transformación y orquestación para ofrecer una interfaz simplificada.

La capa de API asegura IS

Al exponer una API, una empresa no puede depender de los consumidores para asegurar IS. La capa API es el último hombre en pie para proteger el SI existente de la empresa y, por lo tanto, debe ser una barrera de seguridad frente a él. La capa de API deberá asegurar:

  • Acceso : La capa de API tendrá que implementar un sistema IAM desde cero o basado en uno existente dependiendo del manejo de seguridad de IS existente. Este sistema IAM tendrá que controlar qué usuarios consumidores, qué API, qué usuario puede acceder a qué datos, y más.
  • Consistencia de datos : si el SI existente no asegura la consistencia de datos , la capa API tendrá que hacerlo. El orden complejo que se colocó anteriormente en este artículo implicó llamar a dos URL diferentes dentro de un cierto período de tiempo para evitar la inconsistencia de los datos; este tipo de complejidad debe ser manejado por la capa de API.
  • Infraestructuras : la capa de API protege las infraestructuras. Algunos de los componentes de SI existentes necesitan ayuda para cumplir con las expectativas de rendimiento y / o protección para garantizar que no se rompan. La capa de API puede proteger o mejorar las infraestructuras existentes agregando algunas capacidades como el almacenamiento en caché o la limitación .

La capa de API acelera IS

La capa de API debe brindar la capacidad de exponer rápidamente las API y hacerlas evolucionar. Debe componerse con componentes de SI existentes o con componentes totalmente nuevos sin verse retenido por la falta de capacidad de evolución de SI preexistente.

Construyendo la capa de API

Para transformar con éxito un IS existente en una API, la capa de API debe ayudar a una empresa a, al menos, manejar fácilmente IAM, la transformación y composición de servicios, la limitación y el almacenamiento en caché. Pero, ¿cómo implementas estas funcionalidades? Dadas las necesidades de la capa de API, la gestión de API es la solución perfecta para exponer un IS existente como API.

Gestión de API

Crear una arquitectura de API centralizada que haga que el proceso de composición, protección y administración de interfaces de alto rendimiento sea significativamente más simple y consistente.

Definición de gestión de API, la academia de API

La gestión de API se compone de dos partes:

  • Una puerta de enlace que maneja:
    • Seguridad
    • Transformación
    • Composición
    • Estrangulamiento
    • Almacenamiento en caché
  • Una oferta de portal:
    • Documentación
    • Inscripción de desarrollador
    • Analítica
    • Monetización

Elegir la (s) solución (es)

Hay muchas soluciones comerciales y de código abierto que pueden satisfacer todas o partes individuales de sus necesidades de arquitectura de administración de API. Al elegir soluciones para construir la capa de API , una empresa tendrá que considerar el rendimiento y la escalabilidad con SaaS frente a la informática local. Cualquiera que sea la solución, al crear una capa de API nunca pierda el enfoque: exponer la API debe ser rápido y simple .

Aprenda a utilizar plantillas para el diseño de API basado en documentación

Mirando más allá del SI existente

La capa API no es la panacea, no puede transformar un Peel P50 en un Bugatti Veyron . Las capacidades de almacenamiento en caché y limitación de la capa de API a veces pueden no ser suficientes para dar como resultado una API que ofrezca rendimiento y escalabilidad para cumplir con todas las expectativas.

Pero tener un SI existente no significa que una empresa siempre tenga que usarlo. A veces, para manejar componentes realmente débiles o responder a nuevas necesidades, la mejor manera de lidiar con un SI existente será eludirlo con nuevas soluciones que coexistan con el IS existente de una empresa dentro de la capa API a través de la puerta de enlace.

Existe una solución API o SaaS

En lugar de crear soluciones personalizadas, existen muchas soluciones que pueden ayudar a las empresas a proporcionar API fácilmente. Servicios como Restlet API Spark permiten crear una API a partir de una hoja de Google, o Context.io permite crear una API a partir de correos electrónicos. Como último recurso, puede que sea el momento de crear aplicaciones con una pila completamente nueva. Ahora hay muchos marcos que facilitan la creación de aplicaciones con API, como el marco Play , un marco Java o Scala, o Loopback , un marco Node.js.

Conclusión: no dejes que tu SI existente te detenga

No solo creemos que todas las empresas deberían considerar la posibilidad de proporcionar API , creemos que todas las empresas pueden proporcionar API. Sin embargo, la integración de una API con un SI existente conlleva desafíos. Como dijimos, exponer directamente un IS podría conducir a una API que:

  • Es inutilizable por especialistas en SI no internos debido a su complejidad.
  • Es peligroso por su falta de seguridad.
  • No coincide con el tiempo de comercialización esperado debido a su lentitud para evolucionar

Para evitar estas preocupaciones:

  • No permita que su API exponga su IS tal cual .
  • Minimizar la complejidad superflua
  • Utilice una capa de API para simplificar, asegurar y acelerar el IS
  • Considere la administración de API y las soluciones de terceros

Publicar un comentario

0 Comentarios