Guía para principiantes sobre APIs

Es posible que ya hayas visto la abreviatura “API” decenas de veces. Si alguna vez pagaste en línea o usaste un agregador de datos, ya usaste esa API misteriosa. Sin embargo, ¿qué es exactamente? En este artículo, analizamos qué son las APIs, qué protocolos de API existen y qué tipos de APIs hay.

¿Qué es una API y cómo funciona?

Una interfaz de programación de aplicaciones es un intermediario de software que permite que distintas aplicaciones se comuniquen. Las APIs pertenecen principalmente al backend de los sistemas, por lo que no ves su funcionamiento y, a menudo, no sabes que las estás usando en ese momento. 

Por ejemplo, visitas tu sitio de noticias favorito y ves el pronóstico del tiempo de hoy. Probablemente, otros sitios web similares te ofrecen la misma información. Sin embargo, ¿de dónde obtienen esos datos? Obviamente, las agencias de noticias no tienen sus propias estaciones meteorológicas para hacer pronósticos. En cambio, obtienen datos de un centro de meteorología. Al mismo tiempo, un sitio web debe ofrecerte un pronóstico preciso y relevante para tu ubicación, y miles de visitantes de decenas de lugares visitan ese medio de noticias en particular al mismo tiempo que tú. Los desarrolladores o administradores del sitio web no pueden ofrecer ni actualizar manualmente los pronósticos para cada visitante. En cambio, usan una API. Cada vez que abres este sitio web para leer noticias, usa una API para “llamar” a una app de meteorología y conocer el clima de tu ubicación, y te muestra la respuesta de la app. Es similar a tomar tu teléfono y marcar el número de tu amigo para comunicarte con él. Una API es un equivalente de un “número de teléfono” que las apps usan para contactarse entre sí.

Las APIs son populares y se usan ampliamente por buenas razones. En primer lugar, simplifican el proceso de desarrollo. Los desarrolladores no tienen que reinventar la rueda; en cambio, pueden usar la misma API para muchos proyectos. Esto acelera el proceso de desarrollo y, en consecuencia, ahorra tiempo y costos. Con las APIs, las apps no se entrometen en los procesos de las demás; solo obtienen los datos necesarios. Como resultado, esto beneficia la seguridad, reduce la probabilidad de errores y contribuye al funcionamiento fluido de los programas. 

Además, las APIs permiten que diferentes sistemas se comuniquen independientemente de sus tecnologías y estructuras subyacentes. Para los usuarios, las APIs significan una amplia lista de funciones.

Cuando hablamos de APIs, nos referimos principalmente a APIs web, es decir, aquellas que requieren una conexión a internet. Sin embargo, algunas APIs se usan dentro de un solo sistema y dispositivo (por ejemplo, el sistema operativo de una computadora) y nunca necesitan una conexión a internet. En este artículo, nos enfocamos en las APIs web.

Componentes de las APIs

Veamos un poco más de cerca lo que ocurre detrás de escena. ¿De qué se compone esta pieza de código llamada API?

La idea principal detrás de cualquier API es la interoperabilidad. En otras palabras, cualquier plataforma que admita el formato elegido debe poder interactuar con una API de la misma manera. Por eso, incluso con distintos desarrolladores y varios protocolos en uso, los componentes clave de las APIs son los mismos.

Cliente de API

Un cliente de API es cualquier app, navegador o software que realiza solicitudes. Diferentes factores pueden activar a un cliente para que envíe una solicitud. Por ejemplo, las acciones de un usuario, como actualizar una página o presionar un botón, podrían activar a un cliente para que envíe una solicitud. Las condiciones que ocurren en el extremo y se basan en lógica automatizada, como consultas a bases de datos, también podrían servir como activadores.

Solicitud de API

Las solicitudes de API deben seguir el mismo estándar. Normalmente contienen cinco elementos principales:

Endpoints

En lo que respecta a las APIs, los endpoints son URLs a las que diriges tus solicitudes. Para saber qué endpoints están disponibles y qué formato debes usar, debes revisar cuidadosamente la documentación de la API, donde el proveedor de la API especifica todos los detalles. Por lo general, los endpoints contienen el nombre de dominio y la versión de una API que usas. También pueden contener diversos parámetros de consulta. Nuevamente, la documentación de la API incluye información sobre los parámetros disponibles.

Método

En tu solicitud, debes decirle a un servidor qué quieres que haga. Por lo tanto, un método es un comando para un servidor que le indica qué hacer. Los métodos difieren según el protocolo de API que uses. Por ejemplo, el protocolo REST aprovecha métodos HTTP como GET, POST, PUT, PATCH y DELETE. Otros protocolos tienen sus propios métodos. Si vas a usar una API, lee su documentación, donde el proveedor aclara qué protocolo y métodos utiliza esa API en particular.

Parámetros

Junto con los parámetros de consulta, también existen parámetros de ruta, parámetros de encabezado y parámetros del cuerpo de la solicitud. Son necesarios para la autenticación, filtrar tu solicitud y pasar los detalles necesarios a un servidor receptor. Mientras que el método le indica al servidor qué hacer, por ejemplo, recuperar datos, los parámetros ayudan a especificar qué debe entregarte.

Encabezados

Los encabezados en una solicitud de API cumplen una función clásica: proporcionan datos adicionales sobre la solicitud y los formatos de respuesta deseados, detalles de autorización para demostrar que tienes permiso para realizar las acciones solicitadas, y detalles sobre cómo almacenar en caché solicitudes y respuestas.

Cuerpo de la solicitud

Ese es el núcleo de tus solicitudes, donde proporcionas todos los datos principales mediante parámetros de solicitud. Para entenderlo mejor, imagina un paquete. Los endpoints son el lugar al que quieres que se envíe tu paquete. Los parámetros y encabezados son otros datos de envío, como el nombre y el número de teléfono del destinatario, con detalles adicionales, como si tu paquete contiene objetos frágiles o si la entrega está pagada o debe pagarla el destinatario. El cuerpo de la solicitud es como un paquete, el contenido de la caja, las cosas que envías. Como se mencionó, el cuerpo de la solicitud contiene diferentes parámetros que un proveedor de API especifica en la documentación.

Servidor de API

El servidor de API es una plataforma, software, base de datos o cualquier elemento al que enviamos nuestras solicitudes. Proporciona la API, almacena todos los datos de la API y realiza las acciones que especificamos en nuestras solicitudes.

Respuesta de API

Donde hay una solicitud, también hay una respuesta. Una respuesta es lo que un servidor envía ante tu solicitud. Las respuestas también constan de varios componentes básicos.

Código de estado

El código de estado indica si nuestra solicitud fue exitosa y si un servidor pudo procesarla. Los códigos en los 200 significan que una solicitud fue exitosa, los 300 significan redirección, los 400 implican que hubo problemas con una solicitud y los 500 significan que hubo un problema del lado del servidor.

Encabezados de respuesta

Los encabezados de respuesta son similares a los encabezados de solicitud. Envían cookies a un cliente y proporcionan detalles sobre el cuerpo de la respuesta.

Cuerpo de la respuesta

El cuerpo de la respuesta comprende una serie de pares clave/valor que proporcionan los datos solicitados. Sin embargo, el cuerpo de la respuesta no es un componente necesario de una respuesta de API. Si quisieras que un servidor recuperara algunos datos y te los enviara, obtendrías una respuesta. Al mismo tiempo, si intentas eliminar o reemplazar datos en un servidor, no verás un cuerpo de respuesta; solo obtendrás un código de estado.

Protocolos de API

Un protocolo es un conjunto de reglas que define cómo funciona una API. Se usan varios protocolos para las APIs.

REST

REST (o RESTful, The Representational State Transfer) es el protocolo de API más usado. Sin embargo, es más un estilo arquitectónico que un protocolo. Se basa en el protocolo HTTP para transferir datos en formatos JSON o XML. Las solicitudes son independientes entre sí y las respuestas pueden almacenarse en caché. La simplicidad y la escalabilidad son las principales ventajas de REST, y por eso es la opción principal para servicios web y aplicaciones móviles.

Por otro lado, puede ocurrir una obtención excesiva o insuficiente, por lo que un cliente recibe más datos de los solicitados o, por el contrario, no recibe todos los datos necesarios. Además, como REST usa el protocolo HTTP, puede no ser adecuado para todos los tipos de datos, aplicaciones y entornos. REST también presenta preocupaciones de seguridad; puede tener vulnerabilidades si no se mantiene correctamente.

SOAP

Simple Object Access Protocol, o SOAP, es mucho más estricto y complejo que REST. Usa el estándar de datos XML y puede admitir varios protocolos para transferir datos, incluidos HTTP y SMTP. Admite funciones de seguridad avanzadas como WS-Security. Se usa principalmente para casos que requieren seguridad y formalidad por encima de la usabilidad para una gran audiencia, como servicios financieros o aplicaciones empresariales como Salesforce.

RPC

El protocolo de llamada a procedimiento remoto maneja datos en formatos JSON y XML. Sin embargo, difiere drásticamente de REST y SOAP porque llama a un método en lugar de a una fuente de datos. La respuesta de RPC indica que una acción se activó o falló. Como llamar a un servidor RPC cambia el estado de un servidor, es necesario contar con un alto nivel de seguridad entre proveedores y usuarios. Con todo eso, las APIs RPC suelen ser privadas. Sin embargo, RPC se basa en el protocolo HTTP/2 para transferir datos, que no es compatible de forma nativa con la mayoría de los navegadores, por lo que podrías necesitar equipo adicional para asegurarte de que funcione correctamente.

GraphQL

Aunque GraphQL se llama protocolo, es un lenguaje de consulta. A diferencia de REST, que tiene numerosos endpoints, GraphQL generalmente tiene solo uno. GraphQL permite realizar múltiples solicitudes en una sola consulta. Los usuarios pueden especificar qué datos necesitan, evitando la obtención excesiva o insuficiente. Por otro lado, GraphQL presenta algunos desafíos con el almacenamiento de datos en caché. Además, los proveedores deben proporcionar documentación extensa para informar a los usuarios qué parámetros existen para que puedan hacer una consulta.

Tipos de APIs

Hay varias formas de categorizar las APIs: por su público objetivo o por estructura. Si hablamos del público, pueden ser públicas, de socios y privadas, o pueden ser compuestas, unificadas, de microservicios y monolíticas si las evaluamos por estructura.

APIs públicas

También llamadas abiertas o externas, las APIs públicas están diseñadas para una audiencia amplia. No tienen restricciones o tienen pocas; incluso si requieren autenticación o registro, es un proceso sencillo, y los usuarios no necesitan tener ninguna calificación para usar esa API. Sin embargo, las APIs abiertas aún pueden requerir pagos o limitar funciones para cuentas gratuitas. Por ejemplo, Google Maps API es una API pública.

API privada

Este tipo de API también se llama API interna. Está dirigida a un grupo pequeño de usuarios, como personas dentro de una empresa. Los usuarios necesitan permiso para acceder a esas APIs. Deben ser seguras, por lo que la autenticación puede tomar tiempo y ser compleja.

API de socios

Las APIs de socios están entre las públicas y las privadas. Su principal caso de uso es compartir datos entre dos compañías o empresas, por lo que estas APIs aún requieren autenticación y son seguras. También están dirigidas a un grupo de usuarios, pero ese grupo es más grande que en el caso de las APIs privadas. La información compartida mediante estas APIs es importante y definitivamente no está destinada a una audiencia amplia, pero aun así no es tan secreta como los datos compartidos mediante APIs privadas.

Además, a veces se menciona un cuarto tipo: OpenAPI Standard. Sin embargo, no es otro tipo de API, sino un marco para escribir APIs públicas. Su nombre original era Swagger, y esta herramienta proporciona pautas, por lo que escribir una API y luego usarla se vuelve más simple y rápido. Sin embargo, también es inexacto llamar ” open APIs” a las APIs públicas, ya que no todas las APIs públicas siguen el estándar. Además, las APIs privadas pueden usar el estándar OpenAPI incluso sin estar disponibles públicamente.

APIs monolíticas

Estas APIs se crean como una única base de código que concede acceso a una fuente compleja. Sus ventajas incluyen funcionalidad predecible y estabilidad. Por otro lado, son difíciles de escalar o actualizar, ya que muchos datos están conectados y los cambios podrían causar consecuencias impredecibles.

APIs de microservicios

Por el contrario, las APIs de microservicios hacen que cada API sirva a un propósito diferente y específico. Es fácil actualizarlas o desactivar partes que ya no se necesitan sin afectar a todo el sistema. Sin embargo, las APIs de microservicios producen una enorme cantidad de solicitudes individuales.

APIs compuestas

Aquí es donde entran en juego las APIs compuestas. Pueden dirigirse a múltiples endpoints en una sola llamada, identificando el conjunto de llamadas más efectivo, proporcionándote los datos necesarios y evitando código duplicado.

APIs unificadas

Las APIs unificadas son similares a las compuestas; en lugar de solicitar diferentes endpoints en una sola API, solicitan varias APIs. La elección depende de tus necesidades.

Pruebas y monitoreo de APIs

Como cualquier otro software, las APIs requieren pruebas y monitoreo para garantizar estabilidad, seguridad y rendimiento de alto nivel. Puedes probar APIs manualmente o realizar pruebas automatizadas. Hay varios tipos de pruebas de API:

• pruebas funcionales: para garantizar que un servidor responda a las solicitudes y que las respuestas y los formatos de datos sean correctos;
• pruebas de carga: ayudan a validar si una API funciona correctamente cuando ocurren picos de tráfico;
• pruebas de seguridad: necesarias para garantizar que no queden brechas para estafadores;
• pruebas de regresión: cuando se realizan cambios, las pruebas de regresión son necesarias para asegurarse de que no ocurran consecuencias inesperadas e indeseadas;
• pruebas de tolerancia a fallos: útiles para verificar cómo responde un sistema a solicitudes potencialmente dañinas, como aquellas que pueden derivar en un ataque DDoS.

Los desarrolladores realizan pruebas de API tanto durante las etapas de desarrollo como de implementación.

Para concluir

Una API es otra herramienta que te ayuda a aprovechar al máximo las tecnologías. Aunque a menudo la usas sin siquiera darte cuenta, muchas funciones de tu sitio web o app favorita son posibles gracias a las APIs. A su vez, DataImpulse siempre está aquí para explicar las tecnologías en un lenguaje claro, para que te sientas cómodo. Además, potenciar una herramienta con otra puede darte el mejor resultado. Por ejemplo, las pruebas de API se vuelven mucho más productivas con proxies. Además, desarrollamos nuestra API, para que puedas usarla para revender nuestros proxies y ganar dinero con nosotros. Para saber más, escríbenos a [email protected] o presiona el botón “Pruébalo ahora” en la esquina superior derecha de la pantalla.