Si eres desarrollador de software, en más de una ocasión tuviste que haber escuchado alguno de estos términos: «API», «Web Service», «Web API», «API REST», «API RESTful» o simplemente «servicio». Generalmente escuchamos decir «servicio REST» o «API REST» cuando obtenemos como respuesta un JSON y «servicio web» cuando obtenemos un XML, pero esto no siempre es así y puede generarnos confusión.
¿Qué es una API y cuál es su objetivo?
Una API es un conjunto de definiciones y protocolos que se utilizan para desarrollar e integrar el software de aplicaciones. La sigla significa Application Program Interface (Interfaz de Programación de Aplicación).
El primer punto que debemos aclarar es que una aplicación es una API cuando nos proporciona funcionalidades que permiten utilizar procesos de negocio o aplicaciones, a la vez que facilita la integración con otros recursos y sistemas, independientemente del framework, arquitectura o tipo de datos utilizado para su implementación.
Para comprender un poco más esta afirmación, revisemos un poco como ha sido el proceso de madurez de las APIs.
Inicios de las APIs
En los años 60’s las APIs se utilizaban como librerías de los sistemas con el objetivo de exponer funcionalidades que facilitaran el desarrollo, mantenimiento y control de estos localmente. En la década de los 70’s tuvieron su primera evolución gracias a los Sistemas Distribuidos ya que se implementaron mecanismos que permitían el acceso remoto a las APIs. El término «remoto» hace referencia a las APIs que están diseñadas para interactuar en una red de comunicaciones y puede acceder a recursos que están en otras computadoras o equipos.
Durante la década de los 90’s la programación orientada a objetos, la definición del protocolo HTTP, el apogeo de las páginas web y la implementación de infraestructuras cliente/servidor permitió que los desarrolladores aprovecharan las facilidades tecnológicas en la administración de la comunicación para mejorar la forma de implementar las APIs.
Para el año 2000, ya eran una parte importante en el desarrollo e integración de aplicaciones. Ese mismo año Roy Thomas Fielding publicaría su tesis doctoral «Architectural Styles and the Design of Network-based Software Architectures» donde definiría los principios de la arquitectura REST (acrónimo inglés de REpresentational State Transfer, Transferencia de Estado Representacional), la cual se utilizaría ampliamente en los siguientes años para el desarrollo de estas.
APIs en la actualidad
Actualmente el uso de APIs es casi obligatorio al desarrollar una aplicación que esté disponible en la nube. Por ejemplo sitios de renombre como Facebook, Instagram o Twitter ponen a disposición APIs REST públicas que reciben y devuelven datos JSON para que los desarrolladores puedan realizar integraciones o consumir sus datos. También, a nivel empresarial, por ejemplo en bancos o empresas del sector financiero, se tiene acceso a Servicios SOAP privados que devuelven documentos XML.
Adicionalmente las plataformas de servicios como Microsoft Azure o Amazon Web Services ofrecen una amplia variedad de utilidades que facilitan todo el ciclo de vida de desarrollo de aplicaciones. Algunos ejemplos de APIs que podemos encontrar:
- Análisis de audio/video.
- Computación y cálculo quántico.
- Inteligencia Artificial.
- Renderizado de modelos 3D en entornos de realidad aumentada.
- Métricas de estado y salud de infraestructura.
- Seguridad y prevención de ataques DDoS.
SOAP y REST
Son dos conceptos que están presentes en el diseño e implementación de APIs, pero sus enfoques son totalmente distintos:
SOAP (Simple Object Access Protocol, Protocolo Simple de Acceso a Objetos) es un protocolo estándar que permite el intercambio de información estructurada en entornos distribuidos descentralizados, utilizando mensajes XML que cumplen un formato establecido. En su especificación se determina que deben cumplirse requisitos de atomicidad, uniformidad, aislamiento, durabilidad (ACID) y seguridad; estos lineamientos vuelven a este protocolo el primer candidato a considerar para la implementación de APIs en sectores empresariales.
En el siguiente ejemplo tenemos el formato de un mensaje SOAP:
REST (REpresentational State Transfer, Transferencia de Estado Representacional) es un estilo de arquitectura para sistemas hipermedia distribuidos, que cumple con las siguientes pautas:
- Es una arquitectura cliente/servidor, compuesta por: Clientes, servidores y recursos.
- La comunicación entre cliente/servidor debe ser sin estado: Cada solicitud del cliente al servidor debe contener toda la información necesaria para ser procesada. El estado de la sesión se mantiene en el cliente.
- Los datos pueden almacenarse en caché con el objetivo de eliminar algunas interacciones cliente/servidor y mejorar la red.
- Define una interfaz uniforme entre componentes para que la información sea transferida de forma estandarizada. Esta es la característica principal que distingue el estilo arquitectónico REST de otros estilos basados en red.
- Posee restricciones de sistema en capas con el objetivo que cada componente no pueda «ver» más allá de la capa inmediata con la que está interactuando.
- Estilo de código bajo demanda, lo que permite que los servidores amplíen las funciones de los clientes al enviar código ejecutable. Esta es una característica opcional.
En el siguiente ejemplo tenemos la respuesta de la API REST de Twitter:
En la sección anterior, los términos «API REST» y «Servicios SOAP» fueron utilizados a propósito de esa forma con el objetivo de aclarar lo siguiente: Generalmente se suele asociar «SOAP» con la palabra «Servicio» o «Web Service» y «REST» con «API«. Como acabamos de ver, SOAP y REST son términos que no podemos comparar por su naturaleza (protocolo vs estilo arquitectónico), pero tienen en común que son utilizados para implementar APIs.
Podemos utilizar los términos «API SOAP», «Servicio SOAP». «API REST», «Servicio REST» o simplemente «Web Service» o «Servicio» para hacer referencia a una API, ya que su definición está regida por las capacidades que brinda para el desarrollo e interconexión del software de aplicaciones y no por su implementación particular.
Conclusión
Un aplicación es una API si brinda funcionalidades que permiten la reutilización de procesos de negocio o sistemas de forma local o externa, también si posee mecanismos que faciliten la comunicación e integración con sistemas. Una API no la define la implementación de un protocolo, formato o uso de tipo de datos o particular.
