Los 5 estilos de API más populares y qué los distingue

En lo que respecta a los casos de uso, cabe mencionar que las API pueden ser públicas, estar disponibles para socios o ser totalmente internas. Este primer factor diferenciador marca la pauta para muchas de las características y funcionalidades que habrá que desarrollar: cómo se almacenan y comparten los datos, cómo se gestionan las credenciales, cuánto tráfico debe soportar la API, etc.

Como verás, los siguientes estilos arquitectónicos pueden utilizarse en cualquiera de estos tres casos, pero algunas combinaciones resultan más adecuadas que otras.

Estas son, con diferencia, las API más comunes en la actualidad y también el estilo que hemos utilizado para desarrollar WebScrapingAPI. El acrónimo significa «Transferencia de Estado Representacional», y este estilo establece que, si tú, como cliente, realizas una solicitud, la API te devolverá una representación del estado del recurso que has solicitado.

Las API RESTful se basan en gran medida en la infraestructura HTTP. Dado que la web en general utiliza principalmente HTTP, las API REST ya cuentan con una ventaja, ya que son fáciles de comprender, integrar y utilizar.

Este estilo también se define mediante una serie de restricciones que la API debe respetar. Aunque a primera vista esto pueda parecer una molestia, las restricciones garantizan que la API se comporte de forma predecible y útil. Hay seis en total, y son las siguientes:

• Interfaz unificada
• Apátrida
• Almacenable en caché
• Cliente-servidor
• Sistema de capas
• Código bajo demanda

Hemos publicado un artículo completo sobre estas limitaciones en Medium, así que échale un vistazo para conocer los detalles más específicos sobre las API REST.

Si una API cumple algunas de estas restricciones, pero no todas, se puede considerar de tipo REST. En algunos casos, las restricciones pueden suponer más inconvenientes que ventajas, por lo que es posible que te encuentres con adopciones parciales de este estilo.

SOAP, o Protocolo simple de acceso a objetos, se basa en gran medida en XML. Para utilizarlo, hay que cumplir unas normas estrictas en cuanto a la estructura de los mensajes, las reglas de codificación y el manejo de las solicitudes y respuestas.

Aunque son muy precisas y completas, las API SOAP pueden resultar más difíciles de manejar debido a su lenguaje de marcado. Las solicitudes y las respuestas pueden llegar a ser bastante largas y complejas, lo que las convierte en una tarea tediosa si hay que escribir los comandos a mano.

Por el lado positivo, este estilo tiene la ventaja de que incorpora la gestión de errores. Si surge algún problema con la solicitud, la respuesta contendrá mucha información valiosa que puede ayudarte a localizar y corregir el error.

Este estilo se utiliza para consultar bases de datos desde aplicaciones del lado del cliente a través de HTTP. Sin embargo, en lugar de enviar varias solicitudes HTTP a distintos puntos de conexión, puedes enviar una única solicitud POST con toda la información necesaria. En esencia, el cliente describe lo que necesita una sola vez y la API hace todo lo posible por recuperar esos datos.

Un servidor que funciona con la arquitectura GraphLQ cuenta con un modelo (o esquema) predefinido para los datos que se pueden solicitar. Así pues, cuando se realiza una solicitud, el esquema sirve de guía sobre qué se puede solicitar, cómo debe estructurarse la información y cómo se puede interactuar con el servidor.

La ventaja de este sistema es que los usuarios saben exactamente qué pueden obtener, por lo que es muy improbable que se obtengan datos erróneos o se produzca un error. El principio fundamental es dar prioridad al cliente y ofrecerle la mejor experiencia posible.

Al igual que GraphLQ, las API de Falcor crean un archivo JSON virtual que actúa como contenedor de los datos que el cliente recibirá tras una solicitud. Este archivo virtual puede ampliarse con cada nuevo dato que el cliente necesite. Aunque esto resulta muy práctico, el archivo puede llegar a ser bastante grande con el tiempo.

Por suerte, no es necesario descargar todo el archivo JSON con cada solicitud. En su lugar, puedes especificar qué partes necesitas en cada momento y obtenerlas en la respuesta. Esto funciona porque el archivo JSON se publica en una URL y enlaza con diferentes recursos del backend. En esencia, puedes navegar por el archivo virtual para encontrar los datos que deseas.

Esta capa virtual entre el cliente y el servidor permite conectarlos entre sí, al tiempo que mantiene sus arquitecturas completamente independientes.

Cuando hay pocas limitaciones de las que preocuparse, gRPC debería ser una de tus primeras opciones a la hora de diseñar una API. Es independiente del lenguaje y de la plataforma, y bastante rápido gracias al uso de Protocol Buffers (protobufs) para serializar los datos en flujos binarios. A continuación, esos datos se transfieren a través de HTTP/2.

gRPC es ideal para sistemas distribuidos. El aspecto más importante de este estilo son los procedimientos. Se pueden ejecutar tanto en el equipo local como en dispositivos remotos. En ambos casos, llamar a un procedimiento es rápido y sencillo.

Una de las razones por las que las API están ganando popularidad son las ventajas que ofrecen los microservicios frente al modelo clásico de software de servicio único. De este modo, cada función o microservicio puede diseñarse, desarrollarse y actualizarse por separado sin afectar al resto de componentes. En ese sentido, gRPC es una solución ideal para integrarlo todo.

Además, dado que se puede iniciar un procedimiento de forma remota, también resulta ideal para conectar dispositivos móviles a servicios de backend.

Aunque este artículo te ha ofrecido una visión general de los estilos arquitectónicos de API más comunes, no basta para garantizar que elijas el más adecuado. Para nosotros, como equipo, fue fundamental contar con experiencia práctica de primera mano con el mayor número posible de ejemplos.

Cuando hablo de experiencia, me refiero tanto a mi experiencia como usuario como a mi experiencia como desarrollador. Al fin y al cabo, puede que haya un estilo con el que estés más familiarizado y que te resulte más fácil de implementar, pero tienes que ponerte en el lugar del usuario final y ver cómo le funciona.

Un estilo no es algo que se pueda elegir a mitad del desarrollo o cambiar más adelante. Es un conjunto de normas que determina cómo se configura la API. Por eso, es una decisión importante.

Un primer paso que puedes dar es leer la documentación de las API que ya están en el mercado y, a ser posible, probarlas. La experiencia previa en el desarrollo de API también sería una gran ventaja.

Si quieres saber cómo hemos convertido WebScrapingAPI en la potente herramienta de web scraping que es hoy en día, ¿por qué no echas un vistazo a nuestra documentación? Además, no todas las funciones actuales estaban presentes en el momento del lanzamiento. Opciones como el scraping de puntos finales de API REST o de archivos se añadieron a petición de nuestros usuarios, así que recuerda: el estilo arquitectónico está pensado para orientarte, pero es tu tarea convertir la API en algo que guste a la gente.