Si somos puristas y nos vamos a la definición que nos provee la Real Academia Española y la Asociación de Academias de la Lengua Española sobre el Vocabulario o Glosario de Términos, para este caso gramaticales es un recurso didáctico se ponen a disposición de los docentes de lengua de todos los países hispanohablantes. Los objetivos fundamentales de esta obra son los siguientes:
Si asemejamos esto al mundo de la integración se podría definir como:
Bajo estas premisas de lo que consideramos como vocabulario de términos, y aterrizándolo en la plataforma de MuleSoft – Anypoint Platform sobre las APIs, nos encontramos con lo que se denomina API Fragments.
Un API Fragment es un documento que tiene una versión y un identificador, pero no es en sí mismo un API Spec completa. Es una parte de un API Spec, por lo que su comprensión comienza en el nivel de especificación de API.
Un API Spec consiste en un plan de cómo debería verse estructuralmente su API, como el plano de una casa. En definitiva, se trata del contrato que estandariza el intercambio de datos entre los diferentes servicios. Es decir, sirve para estandarizar el Modelo de Datos...
Un API Spec proporciona una comprensión integral de cómo se comporta una API y se vincula con otras API. También explica cómo funciona la API y los resultados que se esperan al usar la API.
Un API Spec documenta lo que hace una API y la llamada y respuestas esperadas que pueden esperar de ella. Es una parte clave del desarrollo de API porque puede ayudarle a aislar los posibles fallos o problemas de diseño antes de escribir una línea de código.
Una forma de crear API de manera más eficiente es reutilizar partes o fragmentos de un API Spec, para que estos no tengan un formato diferente entre los diferentes servicios que dispongamos. Por ejemplo, que un recurso tenga siempre la misma estructura modelo entre los diferentes servicios que intercambian información de este, haciendo único el modelo de datos en todas las capas, desde el front-end al back-end.
Es por eso que podemos considerar a los API Fragments de MuleSoft como un diccionario, un vocabulario de términos al que consultar y con los cuales formar la especificación de nuestras APIs en la capa de Integración.
Dicha colección o vocabulario de términos es más que recomendable que se dividan en pequeños módulos y se externalicen en API Fragments la capa de integracion con APIs en lo que a Anypoint Platform se refiere, los API Spec de esos recursos, parámetros, esquemas… En definitiva, de este modelo de datos.
La gran ventaja de los API Fragments es que podemos reutilizarlo en todas las API Spec que requieran de él, consiguiendo así una cohesión y coherencia en toda la capa de APIs en nuestro modelo API Led. Además, con ello conseguimos que el diseño y la creación de una especificación API reutilizable sean aún más rápidas y sencilla, pues no se comienza desde cero.
¿Cuántas veces hemos llegado a un proyecto en el que la misma entidad está definida de manera diferente según qué API, endpoint, operación, etc., donde uno o más parámetros tienen un nombre diferente?
Pongamos algunos ejemplos:
name | fullName |
creditCardType | creditCardModel |
User | client |
*** | *** |
Para estos casos, existen los Modelos Comunes de Datos también conocidos como “Canonical Data Model (CDM)”. Este modelo de datos ha de ser estandarizado y consensuado dentro de la entidad comercial, para seguidamente hacerlo extensible en todas las capas, desde el front-end al back-end.
Podríamos definir los CDMs como un tipo de modelo de datos que tiene como objetivo presentar entidades y relaciones de datos de la forma más simple posible para integrar procesos en varios sistemas y bases de datos.
Hay muchos casos en los cuales podemos encontrarnos con un Modelo Común de Datos estandarizado en el sector, que nos indica cuáles son las entidades principales que se han de tener en cuenta y sus parámetros como pueden ser:
Gracias a los API Fragments, podemos aterrizar estos modelos de datos en las APIs para poder ser reutilizados internamente en un API Spec, cerciorándonos así que tendremos un Modelo Común de Datos cross a todas las APIs, ya esté basado en algún estándar común a un sector, o sea propio de la entidad.
Gracias a estas dos herramientas integradas en Anypoint Platform, el Anypoint Design Center y el Anypoint Exchange, los usuarios podrán aprovechar verdaderamente los fragmentos de API, pues nos ofrecen las capacidades que hacen que la reutilización tenga el peso y la importancia que se merecen.
Anypoint Exchange ayuda a los usuarios a facilitar el componente de reutilización de Anypoint Platform. A medida que los usuarios comienzan a definir fragmentos de API, pueden publicarse en Exchange y luego ponerse a disposición para su descubrimiento en toda la organización en Anypoint Design Center. Una vez que utilizan los activos, los usuarios también pueden calificarlos o dejar comentarios y preguntas.
La estrecha integración del diseñador del API y Anypoint Exchange es realmente fundamental para crear un flujo de trabajo eficiente y necesario para cerrar la brecha en la entrega de TI. Sin la conexión entre el diseñador de API y Exchange. La coherencia y visibilidad que proporcionan las herramientas hacen posible la reutilización, el aumento de la productividad y la eficiencia.
Debido a la agilidad que nos brindan los API Fragments a la hora de enfrentarnos a una nueva integración y/o API en su fase de diseño de la especificación, creo que es una gran característica que nos brinda MuleSoft con la que poder disponer de un Diccionario de Vocabulario de Términos reutilizables con el que poder tener una coherencia y cohesión cross a toda la entidad en términos de un Modelo de Datos Común (CDM).
Además, los API Fragments no solo nos brindan esta coherencia y cohesión, sino que al juntarlo con las herramientas de Anypoint Platform del Design Center y Exchange, se ven potenciadas en cuanto a la coherencia y visibilidad que nos proporcionan haciendo posible la reutilización, el aumento de la productividad y la eficiencia ante una nueva integración, caso de uso y/o API, pudiendo definir un Ciclo de Vida de una API y un flujo de trabajo mucho más cercano y eficiente necesario para cerrar la brecha en la entrega de TI.