En 2002 un alto dirigente de Amazon —el mismísimo Jeff Bezos, según la mayoría de las fuentes; Allan Vermeulen, CTO de Amazon en aquel momento, según otras— lanzó una circular interna dirigida a todos los equipos de desarrollo de Amazon. Esa circular terminaría cambiando para siempre las dinámicas de desarrollo web y de software, dando comienzo al actual paradigma basado en APIs/microservicios.
Poco tiempo antes, los expertos de la compañía habían decidido que una estrategia que girase en torno a software monolítico no resultaría lo bastante ágil para las necesidades cada vez más complejas de Amazon: necesitaban dividir sus servicios en componentes más pequeños y que luego éstos se comunicaran entre sí.
Pero, ¿qué es una API?
'API' son las siglas de 'Application Programming Interface', que vendría a traducirse como 'interfaz de programación de aplicaciones', y designa al conjunto de reglas y protocolos que permiten la comunicación entre dos aplicaciones para realizar alguna función de las mismas.
Una consecuencia de esto es que las APIs hacen posible no tener que reinventar la rueda con cada nueva aplicación; así, las tiendas online recurren a contactar vía API con los grandes servicios de pago (como PayPal) en lugar de tener que implementar su propio sistema.
A servicios como PayPal les interesa desarrollar APIs públicas que multipliquen su uso y popularidad. También sería el caso de Twitter, cuando una aplicación 'cliente' de terceros permite que la red social llegue, por ejemplo, a sistemas operativos minoritarios no compatibles con la app oficial.
La circular de marras
El texto completo de la ya conocida como 'API Mandate' ('Orden API') es el siguiente:
Todos los equipos expondrán a partir de ahora sus datos y funcionalidad a través de interfaces de servicio.
Los equipos deben comunicarse entre sí a través de estas interfaces.
No se permitirá ninguna otra forma de comunicación entre procesos: nada de vinculación directa, ni lecturas directas del depósito de datos de otro equipo, ni modelo de memoria compartida, ni ninguna clase de puertas traseras: la única comunicación permitida será mediante llamadas a la interfaz de servicio a través de la red.
No importa qué tecnología utilicéis: HTTP, Corba, Pubsub, protocolos personalizados? da igual.
Todas las interfaces de servicio, sin excepción, deberán diseñarse desde cero para que sean externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores en el mundo exterior. Sin excepciones.
Cualquiera que no haga esto será despedido.
Un aspecto fundamental del valor de una API reside en su 'efecto red': siendo un conjunto de 'bloques de construcción digitales', cuanto mayor sea el número de funcionalidades que proporcione más cosas valiosas permitirá crear.
El término 'API' (que data de mediados del s. XX) no aparece ni una sola vez en todo el documento, pero todas las claves del actual concepto de API están ahí: Exposición de datos, externalización de uso, interacciones estandarizadas, 'agnosticismo' tecnológico (es decir, que el funcionamiento sea independiente del protocolo / software / sistema operativo usado)…
De este modo, Amazon no sólo revolucionó su infraestructura interna, sino que al popularizarla, logró crear un nuevo nicho de mercado… que ellos mismos cubrieron un año más tarde con el lanzamiento de AWS: esta plataforma, entre otros muchos servicios, incluye la posibilidad de proporcionar funcionalidad API a las aplicaciones de sus clientes.
Por cierto: en varios sitios webs encontrarás referencias a la existencia de un séptimo punto del documento que supuestamente reza "Gracias; ¡Que tengas un buen día!", pero se trata de una broma insertada por el ex-empleado de Amazon que hizo pública la circular por primera vez hace 11 años en Google+. Él mismo dejó claro que, por el contrario, el sexto punto no era ninguna broma.
Comments