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

En cuanto a los casos de uso, cabe mencionar que las API pueden ser públicas, estar disponibles para socios o ser completamente internas. Este primer factor diferenciador establece el estándar 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 tienen más sentido que otras.

Estas son, con diferencia, las API más comunes en la actualidad y también el estilo que utilizamos para crear WebScrapingAPI. El acrónimo significa REpresentational State Transfer (Transferencia de Estado Representacional), y el estilo dicta 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 tienen una ventaja, ya que son fáciles de entender, integrar y utilizar.

Este estilo también se define por un conjunto de restricciones que la API debe respetar. Aunque esto pueda parecer una molestia al principio, las restricciones garantizan que la API se comporte de una manera predecible y útil. Hay seis en total, y son las siguientes:

• Interfaz uniforme
• Sin estado
• Almacenable en caché
• Cliente-servidor
• Sistema en capas
• Código bajo demanda

Hemos publicado un artículo completo sobre estas restricciones 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 de uso, las restricciones pueden suponer más problemas que beneficios, 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 con estándares estrictos en cuanto a la estructura de los mensajes, las reglas de codificación y el manejo de 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 respuestas pueden llegar a ser bastante largas y complejas, lo que las convierte en una tarea tediosa si se escriben los comandos manualmente.

Por el lado positivo, este estilo tiene la ventaja de contar con un manejo de errores integrado. Si te encuentras con un problema en la solicitud, la respuesta contendrá mucha información valiosa que puede ayudarte a encontrar 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 diferentes puntos finales, puedes enviar una sola «consulta» POST con todo lo que necesitas. 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 opera bajo la arquitectura GraphLQ cuenta con un modelo (o esquema) predefinido para los datos que se pueden solicitar. Así, cuando realizas una solicitud, el esquema actúa como una guía sobre lo que puedes pedir, cómo debe estructurarse la información y cómo puedes interactuar con el servidor.

La ventaja de este sistema es que los usuarios tienen una idea clara de lo que pueden obtener, por lo que es muy improbable que se recuperen datos erróneos o se produzca un error. El principio subyacente es poner al cliente en primer plano y ofrecerle la mejor experiencia.

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 se puede ampliar con cada nuevo dato que el cliente necesite. Aunque esto añade comodidad, el archivo puede llegar a ser bastante grande con el tiempo.

Por suerte, no es necesario recuperar 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 bajo una URL y enlaza con diferentes recursos en el backend. Básicamente, puedes navegar por el archivo virtual en busca de los datos que desees.

Esta capa virtual entre el cliente y el servidor ayuda a conectar ambos, al tiempo que mantiene sus arquitecturas completamente independientes.

Cuando hay pocas restricciones 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 datos en flujos binarios. A continuación, esos datos se transfieren a través de HTTP/2.

gRPC es muy adecuado para sistemas distribuidos. El aspecto más importante de este estilo son los procedimientos. Puedes ejecutarlos en la máquina local y 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 esta forma, cada función o microservicio puede diseñarse, desarrollarse y actualizarse por separado sin afectar a otros componentes. En ese sentido, gRPC es una excelente solución para integrarlo todo.

Además, dado que se puede iniciar un procedimiento de forma remota, también es una buena opción 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 es suficiente para garantizar que elijas el adecuado. Para nosotros, como equipo, fue esencial tener experiencia de primera mano con tantos ejemplos como fuera posible.

Por experiencia, me refiero tanto a la de usuario como a la de desarrollador. Al fin y al cabo, quizá haya un estilo con el que estés más familiarizado, por lo que sería 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 reglas que dicta cómo toma forma la API. Como tal, 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 la creación de API también sería una gran ventaja.

Si quieres ver cómo convertimos WebScrapingAPI en la potente herramienta de web scraping que es hoy, ¿por qué no echas un vistazo a nuestra documentación? Tampoco todas sus 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 darte una orientación, pero es tu trabajo convertir la API en algo que le encante a la gente.