Como el principio de Abstracción de las APIs beneficia a los proveedores de servicios
Cuando el punto final de una API es arquitectónicamente el punto en el que la aplicación que consume API está esencialmente desacoplada del servicio consumido, proporciona al proveedor de API una cantidad significativa de flexibilidad a la hora de proporcionar su servicio.
Hemos estado utilizando la electricidad y tomas eléctricas como una metáfora para las API, y la comparación se encuentra aquí, también: siempre y cuando la compañía eléctrica sigue suministrando el estándar 220v o 110v como servicio a la toma de pared, puede cambiar cualquiera o todos la infraestructura que se necesita para entregar ese servicio. La fuente de energía se puede cambiar de una planta de carbón a un parque eólico. Los cables en la calle se pueden cambiar de arriba a tierra. Los sistemas que supervisan la red eléctrica se pueden actualizar. Los camiones que dan servicio a la red pueden ser reemplazados. Mientras la compañía eléctrica suministre energía a dispositivos consumidores de electricidad basados ??en el estándar, la empresa puede tomar las decisiones de negocio que quiera para poder servir de una manera eficiente, respetuosa con el medio ambiente y costo-efectiva.
Del mismo modo, debido a que un punto final de API desacopla suficientemente la aplicación consumidora de la infraestructura que proporciona un servicio, el proveedor de servicios tiene una tremenda flexibilidad cuando se trata de cómo ofrece su servicio. Por ejemplo, si la infraestructura detrás de la API implica servidores físicos en un centro de datos, el proveedor de servicios puede cambiar a servidores virtuales que se ejecutan en la nube de empresas como Amazon o Rackspace.
Si el software que se ejecuta en dichos servidores (como el software de procesamiento de tarjetas de crédito) está escrito en Java, por ejemplo, en un servidor de aplicaciones Java basado en Oracle, el proveedor de servicios puede migrar esa base de código a Node.js ) en Windows Azure. Mientras las especificaciones de lo que el proveedor de servicios está entregando al punto final permanecen sin cambios, los cambios en la infraestructura detrás del punto final deben pasar desapercibidos para las aplicaciones que dependen de esa API.
Al igual que un contrato legal entre dos partes, este acuerdo entre lo que la aplicación consumidora espera ver en el punto final y lo que el proveedor de API proporciona en el punto final se denomina a menudo “contrato API”. un cambio material al punto final del API, el contrato es esencialmente incumplido y las aplicaciones consumidoras que dependen de ese API se romperán probablemente a menos que el proveedor de API dé a los desarrolladores una advertencia justa del cambio inminente.
Volviendo a la metáfora de la electricidad, si la compañía eléctrica cambia algo sobre la especificación de su servicio eléctrico – por ejemplo, cambia la velocidad a la que la corriente alterna direcciones de 60Hz a 50Hz – podría poner en peligro sus dispositivos.
Autor: Diego San Esteban
