Definición

El término API es una abreviatura de Application Programming Interfaces, que en español significa Interfaz de Programación de Aplicaciones. Una API es un conjunto de protocolos que permiten que diferentes componentes de software se comuniquen y transfieran datos. Las API son una conexión «neutral» entre una aplicación que hace una solicitud (cliente) y la aplicación que responde (servidor), con independencia del lenguaje de programación y de las especificidades de las aplicaciones que las API conecten.

Los desarrolladores utilizan API para cerrar las brechas entre pequeños y discretos fragmentos de código con el fin de crear aplicaciones que sean potentes, resistentes, seguras y capaces de satisfacer las necesidades del usuario. A pesar de que no puede verlos, las API están en todas partes—trabajando continuamente en segundo plano para impulsar las experiencias digitales que son esenciales para nuestras vidas modernas.

Historia

La historia de la Interfaz de Programación de Aplicaciones realmente comenzó en los años 60, muy lejos del uso de computadoras personales. Normalmente, se usaba una API como bibliotecas en los sistemas operativos.

En la década de los 70, las API experimentaron su primer gran salto en progreso gracias a los sistemas distribuidos. Surgieron métodos que permitieron el acceso remoto a la API de procedimientos al tiempo que evitaban la sobrecarga típica del programador mediante el empaquetado y desempaquetado de datos requerido para la interoperación entre diferentes tipos de computadoras.

Otro salto importante en la historia de la API se produjo a finales de los años 80 cuando la Programación Orientada a Objetos (POO) salió de la academia y se convirtió en un método por el cual las aplicaciones complejas podían organizarse en «objetos» que resumían los datos y los procedimientos.

En los años 90, los sistemas distribuidos se hicieron más comunes gracias a la introducción de las topologías comerciales WWW y cliente-servidor que eran mucho más avanzadas que sus predecesoras.

Una vez más en la historia de la API, vemos que el mundo de la OOP jugó un gran papel. Fue en los años 90 cuando surgieron nuevas técnicas de OOP que permitían el acceso remoto a instancias de objetos.

A principios de la década, Tim Berners-Lee también presentó el primer prototipo de navegador web. Esto también significó la primera página HTML también.

Luego, en 1995, JavaScript debutó. En ese momento, básicamente tenía la misma funcionalidad que HTML, pero sigue siendo importante en términos de la historia de la integración de la API porque fue un paso importante hacia la creación de activos del lado del cliente.

A fines de la década de los 90, cada vez más programadores comenzaron a aprovechar las nuevas capacidades disponibles por la ahora omnipresente WWW. Lo usaron para evitar problemas de administración de la capa de transporte, aprovechando las capacidades de marcado con el HTML principal y mucho más.

Las API web modernas tomaron forma por primera vez a principios de la década de 2000. La historia de las API desde ese período se puede dividir aproximadamente en las siguientes cinco fases:

Fase 1: API comerciales

A principios de la década de 2000, las API web surgieron como un nuevo método para que las nuevas empresas emergentes no solo hicieran que los productos y servicios estuvieran disponibles en línea, pero también para permitir a los socios y revendedores externos ampliar el alcance de sus plataformas. Esta era de API fue definida por Salesforce, eBay y Amazon, y estas compañías continúan dominando el campo de juego de API hoy en día.

Fase 2: API de redes sociales

Un cambio en el panorama de las API ocurrió a mediados de la década de 2000, como un nuevo grupo de empresas—como Flickr, Facebook, etc, y Twitter— se dio cuenta de que las API podrían cambiar la forma en que compartimos información entre nosotros. Si bien estas API no estaban tan intrínsecamente vinculadas a los ingresos como sus predecesoras comerciales, sin embargo, proporcionaron un valor significativo a sus organizaciones. Por ejemplo, Facebook lanzó la versión 1.0 de su API en agosto de 2006, lo que permitió a los desarrolladores acceder a los amigos, fotos, eventos e información de perfil de los usuarios de Facebook. Esta API jugó un papel crucial en el establecimiento de Facebook como una de las redes sociales más populares del mundo.

Fase 3: API en la nube

En 2006, Amazon presentó Amazon Simple Storage (S3), que marcó otro punto de inflexión en la historia de las API. S3 es un servicio de almacenamiento básico en el que los recursos son accesibles a través de API y CLI, y su modelo de pago por uso proporciona una forma rentable para que las organizaciones moneticen los activos digitales en la economía en línea. Apenas seis meses después, Amazon lanzó Amazon Elastic Compute (EC2), que permitió a los desarrolladores usar API web para implementar infraestructura que impulsaría la próxima generación de aplicaciones. Tanto S3 como EC2 siguen desempeñando un papel esencial en el desarrollo de aplicaciones en la actualidad.

Fase 4: API para aplicaciones móviles

El mundo fue introducido al iPhone de Apple y al Android de Google en 2007. La capacidad de llevar la web en nuestros bolsillos cambió radicalmente la forma en que vivimos, y estimuló una inversión masiva en aplicaciones móviles que funcionan con API.

Por ejemplo, Twilio lanzó su plataforma API-as-a-product en 2007, lo que permitió a los desarrolladores realizar y recibir llamadas telefónicas desde cualquier aplicación en la nube. Instagram lanzó su aplicación para compartir fotos para iPhone en octubre de 2010, y tuvo un millón de usuarios solo tres meses después. Instagram no proporcionó inicialmente una API, pero comenzó a trabajar en una a principios de 2011 en respuesta a la demanda de los usuarios. Estas compañías de API primero jugaron un papel esencial en la creación del plan de cómo se entregan las API hoy.

Fase 5: API para dispositivos conectados

Alrededor de 2010, algunos desarrolladores comenzaron a usar API para conectar objetos cotidianos, como cámaras, termostatos, altavoces, micrófonos y sensores, a la nube. Esta próxima generación de dispositivos, que incluye Fitbit, Nest, Alexa, puede enviar y recibir datos, contenido, medios y otros recursos digitales, cambiando aún más la forma en que interactuamos con el mundo que nos rodea.

API - cómo funcionan

¿Cómo funcionan las API?

Las API permiten que sus productos y servicios se comuniquen con otros, sin necesidad de saber cómo están implementados. Esto simplifica el desarrollo de las aplicaciones y permite ahorrar tiempo y dinero. Las API le otorgan flexibilidad; simplifican el diseño, la administración y el uso de las aplicaciones; y ofrecen oportunidades de innovación, lo cual es ideal al momento de diseñar herramientas y productos nuevos (o de gestionar los actuales).

A veces, las API se consideran como contratos, con documentación que representa un acuerdo entre las partes: si una de las partes envía una solicitud remota con cierta estructura en particular, esa misma estructura determinará cómo responderá el software de la otra parte.

Las API funcionan compartiendo datos entre aplicaciones, sistemas y dispositivos. Esto sucede a través de un ciclo de solicitud (request) y respuesta (response). La solicitud se envía a la API, que recupera los datos y los devuelve al usuario.

Aquí hay una descripción general de alto nivel de cómo funciona ese proceso.

1. Cliente API

El cliente API es responsable de iniciar la conversación enviando la solicitud al servidor API. La solicitud se puede activar de muchas maneras. Por ejemplo, un usuario puede iniciar una solicitud de API ingresando un término de búsqueda o haciendo clic en un botón. Las solicitudes de API también pueden ser activadas por eventos externos, como una notificación desde otra aplicación.

2. Solicitud API

Una solicitud de API se verá y se comportará de manera diferente según el tipo de API, pero generalmente incluirá los siguientes componentes:

  • Endpoint. Un endpoint de API es una URL dedicada que proporciona acceso a un recurso específico. Por ejemplo, el endpoint /articles en una aplicación de blogs incluiría la lógica para procesar todas las solicitudes relacionadas con los artículos.
  • Método (method). El método de la solicitud indica el tipo de operación que el cliente desea realizar en un recurso determinado. Las API REST son accesibles a través del estándar Métodos HTTP, que realizan acciones comunes como recuperar, crear, actualizar y eliminar datos.
  • Parámetros (params). Los parámetros son las variables que se pasan a un endpoint de API para proporcionar instrucciones específicas para que la API las procese. Estos parámetros se pueden incluir en la solicitud API como parte de la URL, en la cadena de consulta o en el cuerpo de la solicitud. Por ejemplo, el endpoint /articles de una API de blogs podría aceptar un parámetro “topic”, que usaría para acceder y devolver artículos sobre un tema específico.
  • Encabezados de la solicitud (request headers). Los encabezados de solicitud son pares clave-valor que proporcionan detalles adicionales sobre la solicitud, como su tipo de contenido o credenciales de autenticación.
  • Cuerpo de la solicitud (request body). El cuerpo de la solicitud es la parte principal de la solicitud e incluye los datos reales que se requieren para crear, actualizar o eliminar un recurso. Por ejemplo, si estuviera creando un nuevo artículo en una aplicación de blogs, el cuerpo de solicitud probablemente incluiría el contenido, el título y el autor del artículo.

3. Servidor API

El cliente API envía la solicitud al servidor API, que es responsable de manejar la autenticación, validar los datos de entrada y recuperar o manipular los datos.

4. Respuesta API

Finalmente, el servidor API envía una respuesta al cliente. La respuesta de API generalmente incluye los siguientes componentes:

  • Código de estado (status code). Los códigos de estado HTTP son códigos de tres dígitos que indican el resultado de una solicitud de API. Algunos de los códigos de estado más comunes incluyen 200 OK, lo que indica que el servidor devolvió con éxito los datos solicitados, 201 Creado, lo que indica que el servidor creó con éxito un nuevo recurso, y 404 Not Found, lo que indica que el servidor no pudo encontrar el recurso solicitado.
  • Encabezados de respuesta (response headers). Los encabezados de respuesta HTTP son muy similares a los encabezados de solicitud, excepto que se utilizan para proporcionar información adicional sobre la respuesta del servidor.
  • Cuerpo de respuesta (response body). El cuerpo de respuesta incluye los datos reales o el contenido que el cliente solicitó, o un mensaje de error si algo salió mal.

Para comprender cómo funciona el proceso de las API hagamos una analogía con el servicio de una cafetería.

  1. Un cliente (usuario) le dice al barista lo que quiere, es decir, hace su solicitud de pedido.
  2. El barista es como un cliente API, recibe el pedido del cliente y lo traduce en instrucciones fáciles de seguir en la barra, donde están otros baristas haciendo la preparación de bebidas o comida.
  3. El personal de la barra es como el servidor API porque realiza el producto (bebida o comida) de acuerdo con las especificaciones del cliente. Una vez realizado, se lo da al barista.
  4. El barista hace la entrega finalmente al cliente, lo que se traduciría como la respuesta a la solicitud.

Tipos de API

Hay muchos tipos diferentes de API y formas de categorizarlas. Por ejemplo, puede categorizar las API por quién tiene acceso a ellas. Este marco organizacional incluye:

  • API privadas. Las API privadas, también conocidas como API internas, se utilizan para conectar diferentes componentes de software dentro de una sola organización, y no están disponibles para uso de terceros. Por ejemplo, una aplicación de redes sociales puede tener una API privada que maneja el flujo de trabajo de inicio de sesión, otra API privada que maneja el feed y otra API privada que facilita la comunicación entre los usuarios. Algunas aplicaciones pueden incluir docenas o incluso cientos de API privadas.
  • API públicas. Las API públicas proporcionan acceso público a los datos, funcionalidades o servicios de una organización, que los desarrolladores externos pueden integrar en sus propias aplicaciones. Algunas API públicas están disponibles de forma gratuita, mientras que otras se ofrecen como productos facturables. Por ejemplo, una aplicación de comercio electrónico puede incorporar una API de pago público, como Huelga, para manejar el procesamiento de pagos sin tener que construir esa funcionalidad desde cero.
  • API de socios. Las API de socios permiten que dos o más empresas compartan datos o funcionalidades para colaborar en un proyecto. No están disponibles para el público en general y, por lo tanto, aprovechan los mecanismos de autenticación para garantizar que solo los utilicen los socios autorizados.

Las API le permiten habilitar el acceso a sus recursos y, al mismo tiempo, mantener la seguridad y el control. Usted decide cómo habilita el acceso y a quiénes se lo otorga.

Arquitecturas de API

Las API también se pueden categorizar por sus estilos de arquitectura, los cuales son variados. Entre los más importantes podemos encontrar:

1. REST

REST es la arquitectura API más popular para transferir datos a través de Internet. En un contexto RESTful, los recursos son accesibles a través de endpoints, y las operaciones se realizan en aquellos recursos con los métodos HTTP estándar como GET, POST, PUT y DELETE.

2. SOAP

SOAP, que significa Simple Object Access Protocol, utiliza XML para transferir mensajes altamente estructurados entre un cliente y un servidor. SOAP se utiliza a menudo en entornos empresariales o sistemas heredados, y aunque incluye características de seguridad avanzadas, puede ser más lento que otras arquitecturas API.

3. GraphQL

GraphQL es un lenguaje de consulta de código abierto que permite a los clientes interactuar con un único endpoint de API para recuperar los datos exactos que necesitan, sin encadenar varias solicitudes juntas. Este enfoque reduce el número de viajes de ida y vuelta entre el cliente y el servidor, lo que puede ser útil para aplicaciones que pueden ejecutarse en conexiones de red lentas o poco confiables.

4. Webhooks

Los webhooks se utilizan para implementar arquitecturas basadas en eventos, en las que las solicitudes se envían automáticamente en respuesta a desencadenadores basados en eventos. Por ejemplo, cuando ocurre un evento específico en una aplicación, como un pago que se realiza, la aplicación puede enviar una solicitud HTTP a una URL de webhook preconfigurada con los datos de eventos relevantes en la carga útil de la solicitud. El sistema que recibe el webhook puede procesar el evento y tomar la acción apropiada.

5. gRPC

RPC es el acrónimo de Remote Procedure Call (Llamada a Procedimiento Remoto) y gRPC son APIs creadas por Google. En las arquitecturas gRPC, un cliente puede llamar a un servidor como si fuera un objeto local, lo que facilita que las aplicaciones y sistemas distribuidos se comuniquen entre sí.

Beneficios de uso

Las API conectan varios sistemas de software, aplicaciones y dispositivos al permitirles comunicarse entre sí. Esto desbloquea muchos beneficios, que van desde experiencias de usuario mejoradas hasta una mayor eficiencia empresarial. Las ventajas más comunes de las API incluyen:

  • Automatización. Las API se pueden usar para automatizar el trabajo repetitivo y lento para que los humanos puedan enfocarse en tareas más complejas. Esto mejora la productividad, especialmente para desarrolladores y probadores.
  • Innovación. Las API públicas pueden ser utilizadas por equipos de ingeniería externos, lo que estimula la innovación y acelera el desarrollo al permitir a los desarrolladores reutilizar la funcionalidad existente para crear nuevas experiencias digitales.
  • Seguridad. Las API pueden proporcionar una capa adicional de protección contra infracciones no autorizadas al requerir autenticación y autorización para cualquier solicitud de acceso a datos confidenciales.
  • Eficiencia de costos. Las API proporcionan acceso a herramientas e infraestructura útiles de terceros, lo que ayuda a las empresas a evitar el gasto de construir sistemas internos complejos.

Casos de uso de API

Las API son extremadamente versátiles y admiten una amplia gama de casos de uso que incluyen:

1. Integración con sistemas internos y externos

Una de las razones más comunes por las que los desarrolladores recurren a las API es para integrar un sistema con otro. Por ejemplo, puede usar una API para integrar su sistema de gestión de relaciones con clientes (CRM) con su sistema de automatización de marketing, lo que le permitiría enviar automáticamente un correo electrónico de marketing cuando un representante de ventas agrega un nuevo cliente potencial al CRM.

2. Agregar o mejorar la funcionalidad

Las API le permiten incorporar funcionalidad adicional en su aplicación, lo que puede mejorar la experiencia de sus clientes. Por ejemplo, si está trabajando en una aplicación de entrega de alimentos, puede incorporar una API de mapeo de terceros para permitir a los usuarios rastrear su pedido mientras está en camino.

3. Conexión de dispositivos IoT

Las API son esenciales para el ecosistema de Internet de las cosas (IoT), que incluye dispositivos como relojes inteligentes, rastreadores de ejercicios, timbres y electrodomésticos. Sin las API, estos dispositivos no podrían conectarse a la nube, o entre sí, lo que los haría inútiles.

4. Creación de sistemas más escalables

Las API se utilizan para implementar arquitecturas basadas en microservicios, en las que las aplicaciones se construyen como una colección de pequeños servicios que se comunican entre sí a través de API privadas. Los microservicios se administran, implementan y, y aprovisionado independientemente uno del otro, lo que permite a los equipos escalar sus sistemas de una manera confiable pero rentable.

5. Reducción de costos

Las API ayudan a las organizaciones a reducir los costos operativos al automatizar tareas que requieren mucho tiempo, como enviar correos electrónicos, extraer informes y compartir datos entre sistemas. También pueden reducir los costos de desarrollo al permitir que los equipos reutilicen la funcionalidad existente, en lugar de reinventar la rueda.

6. Mejorar la seguridad y la gobernanza organizacional

Las API potencian muchos flujos de trabajo que son esenciales para la seguridad organizacional. Por ejemplo, las API hacen posible el inicio de sesión único (SSO), que permite a los usuarios usar un nombre de usuario y contraseña para múltiples sistemas. Las API también se utilizan para hacer cumplir y automatizar las reglas y políticas de gobierno corporativo, como el requisito de que los gastos se aprueben antes de que se reembolsen a los empleados.

Esta lista está lejos de ser exhaustiva, y seguirá creciendo a medida que los desarrolladores continúen creando soluciones innovadoras que cambien las formas en que vivimos, trabajamos e interactuamos entre nosotros.

Riesgos de seguridad en las API

Como cualquier cosa conectada a una red, las API son vulnerables a la explotación y al abuso. Entre los ataques comunes API se incluyen los siguientes:

  • Ataques basados en la autenticación. La autenticación es una parte fundamental para garantizar que las llamadas API se envían y reciben de fuentes legítimas.Sin embargo, los atacantes aún pueden saltarse estas medidas para llevar a cabo ataques, ya sea al interceptar tokens de autenticación, robar claves API o al utilizar otras tácticas para obtener credenciales confidenciales.
  • Aprovechamiento de vulnerabilidades. Las vulnerabilidades de las API —como problemas de autorización a nivel de objeto, problemas de autenticación del usuario, exposición excesiva de datos y otras de las OWASP API Security Top 10— se refieren a fallos en una API que pueden permitir a los atacantes acceder a ellas sin permiso.Al aprovechar estos fallos, los atacantes pueden llevar a cabo fugas de datos o utilizar las API para lanzar ataques más complejos.
  • Ataques DDoS. Los atacantes pueden inundar las API con tráfico volumétrico en un intento por interrumpir (o detener por completo) el servicio que presta.

La seguridad debe centrarse en estrategias y soluciones para comprender y mitigar las vulnerabilidades y los riesgos de seguridad únicos de las interfaces de programación de aplicaciones (API).