Restricciones arquitectónicas de la API REST

La famosa abreviatura significa «Representational State Transfer», que es un estilo de arquitectura de software. Su uso más común es facilitar el uso de servicios web con un enfoque estandarizado y universal.

Estos servicios web ofrecen sus recursos web en una representación textual y permiten que se lean y procesen mediante un protocolo sin estado. Las operaciones que un cliente puede realizar están predefinidas y son bien conocidas, basándose generalmente en los protocolos HTTP.

Las API y el software RESTful no se basan en ningún avance tecnológico o de programación. Ni siquiera son tan nuevos, ya que se concibieron por primera vez en el año 2000. La idea detrás de REST es imponer ciertas reglas a la API para obtener más rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad, portabilidad y fiabilidad.

Son muchas ventajas, pero quizá te preguntes: ¿cómo las consiguen las API REST? Sencillo: siguiendo seis restricciones. De hecho, estas reglas son las características más definitorias del estilo arquitectónico RESTful.

La función de una API es conectar dos piezas de software sin limitar sus propias funcionalidades. Este objetivo es una de las restricciones fundamentales de REST: el cliente (que realiza las solicitudes) y el servidor (que da las respuestas) permanecen separados e independientes.

Cuando se hace correctamente, el cliente y el servidor pueden actualizarse y evolucionar en direcciones diferentes sin que ello afecte a la calidad de su intercambio de datos. Esto es especialmente importante en diversos casos en los que un servidor tiene que atender a muchos clientes diferentes. Piensa en las API meteorológicas: tienen que enviar datos a montones de clientes diferentes (todos los tipos de dispositivos móviles son buenos ejemplos) desde una única base de datos.

Para que una API sea sin estado, debe gestionar las llamadas de forma independiente entre sí. Cada llamada a la API debe contener los datos y los comandos necesarios para completar la acción deseada.

Un ejemplo de API no sin estado sería si, durante una sesión, solo la primera llamada tuviera que contener la clave de la API, que luego se almacena en el lado del servidor. Las siguientes llamadas a la API dependen de esa primera, ya que proporciona las credenciales del cliente.

En el mismo caso, una API sin estado garantizará que cada llamada contenga la clave de API y que el servidor espere ver una prueba de acceso cada vez.

Las API sin estado tienen la ventaja de que una llamada errónea o fallida no afecta a las siguientes.

Aunque el cliente y el servidor cambian de diferentes maneras, es importante que la API siga facilitando la comunicación. Para ello, las API REST imponen una interfaz uniforme que puede adaptarse fácilmente a todo el software conectado.

En la mayoría de los casos, esa interfaz se basa en los protocolos HTTP. Además de establecer reglas sobre cómo pueden interactuar los clientes y el servidor, también tiene la ventaja de ser ampliamente conocida y utilizada en Internet. Los datos se almacenan e intercambian a través de archivos JSON debido a su versatilidad.

Para que la API sea fácil de entender y escalar, la arquitectura RESTful dicta que el diseño se estructure en capas que operan conjuntamente.

Con una jerarquía clara para estas capas, ejecutar un comando significa que cada capa realiza su función y luego envía los datos a la siguiente. Las capas conectadas se comunican entre sí, pero no con todos los componentes del programa. De esta forma, también se mejora la seguridad general de la API.

Si cambia el alcance de la API, se pueden añadir, modificar o eliminar capas sin comprometer otros componentes de la interfaz.

No es raro que las solicitudes de una API sin estado tengan una gran sobrecarga. En algunos casos, eso es inevitable, pero para solicitudes repetidas que necesitan los mismos datos, almacenar dicha información en caché puede marcar una gran diferencia.

El concepto es sencillo: el cliente tiene la opción de almacenar localmente ciertos datos durante un periodo de tiempo predeterminado. Cuando solicitan esos datos, en lugar de que el servidor los envíe de nuevo, se utiliza la versión almacenada.

El resultado es sencillo: en lugar de que el cliente envíe varias solicitudes complejas o costosas en un breve lapso de tiempo, solo tiene que hacerlo una vez.

A diferencia de las otras restricciones de las que hemos hablado hasta ahora, la última es opcional. La razón para que el «código bajo demanda» sea opcional es sencilla: puede suponer un gran riesgo de seguridad.

El concepto consiste en permitir que se envíe código o applets a través de la API y se utilicen para la aplicación. Como puedes imaginar, el código desconocido procedente de una fuente sospechosa podría causar daños, por lo que es mejor reservar esta restricción para las API internas, donde hay menos que temer de los hackers y de personas con malas intenciones. Otro inconveniente es que el código debe estar en el lenguaje de programación adecuado para la aplicación, lo cual no siempre es el caso.

La ventaja es que el «código bajo demanda» puede ayudar al cliente a implementar sus propias funciones sobre la marcha, con menos trabajo necesario en la API o el servidor. En esencia, permite que todo el sistema sea mucho más escalable y ágil.

El diseño RESTful se centra en la eficiencia y la escalabilidad en un mundo dominado por la web. Como es de imaginar, esto ha hecho que esta arquitectura sea muy popular, y es muy probable que veamos cómo se generaliza aún más en los próximos años.

La principal preocupación para muchos desarrolladores y expertos en seguridad es lo vulnerables que pueden ser las API web si se crean sin el debido cuidado. Por supuesto, los hackers han sido y seguirán siendo un problema para las API y el software en general. Aun así, no es que vayamos a dejar de usarlas. Más bien, depende de los expertos en seguridad encontrar nuevas formas de proteger nuestros programas.

Esa forma de pensar, junto con el objetivo de facilitar la vida a los desarrolladores, es lo que nos ha llevado a desarrollar WebScrapingAPI, una API REST de extracción de datos que se encarga de todo, desde la rotación de proxies hasta la renderización de JavaScript y la resolución de CAPTCHAs. ¡Échale un vistazo para ver de lo que es capaz una API REST!