Restricciones arquitectónicas de la API Rest

Sorin-Gabriel Marica el 08 dic 2022

Las API tienen muchas formas y tamaños. Aunque muchos desarrolladores agradecen a las API haberles facilitado el trabajo de cientos de formas distintas, no muchos se toman el tiempo de aprender más sobre estas interfaces.

Lo entendemos. El tiempo es limitado, y entender lo que define una API REST puede no ser útil para todo el mundo. No lo vamos a negar, pero hay una razón por la que casi todo el mundo debería aprender esto: es condenadamente interesante. Además, si quieres diseñar o trabajar con una API, merece la pena saber más sobre ella.

Así que, en este artículo, echaremos un vistazo bajo el capó de las API REST y comprenderemos cómo sus principios de diseño las han convertido en el software estable que son hoy en día.

Qué significa ser RESTful

La famosa abreviatura significa "Representational State Transfer", que es un estilo arquitectónico 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 leerlos y procesarlos con un protocolo sin estado. Las operaciones que puede realizar un cliente son predefinidas y conocidas, basadas 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 nuevas, ya que se idearon 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 ¿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.

Las seis limitaciones arquitectónicas de las API REST

1. Arquitectura cliente-servidor

El trabajo de una API es conectar dos piezas de software sin limitar sus propias funcionalidades. Este objetivo es una de las principales restricciones de REST: el cliente (que hace las peticiones) 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 distintas direcciones sin que ello repercuta en la calidad de su intercambio de datos. Esto es especialmente importante en los casos en los que un servidor tiene que atender a muchos clientes distintos. Pensemos en las API meteorológicas: tienen que enviar datos a montones de clientes distintos (todo tipo de dispositivos móviles son buenos ejemplos) desde una única base de datos.

2. Apátridas

Para que una API sea apátrida, tiene que gestionar las llamadas independientemente unas de otras. Cada llamada a la API debe contener los datos y comandos necesarios para completar la acción deseada.

Un ejemplo de API sin estado sería que, durante una sesión, sólo la primera llamada tuviera que contener la clave de la API, que luego se almacena en el 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 la API y el servidor espera ver una prueba de acceso cada vez.

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

3. Interfaz uniforme

Aunque el cliente y el servidor cambien de forma distinta, es importante que la API pueda seguir 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 que establece reglas sobre cómo pueden interactuar los clientes y el servidor, también tiene la ventaja de ser ampliamente conocido y utilizado en Internet. Los datos se almacenan e intercambian a través de archivos JSON debido a su versatilidad.

4. Sistema de capas

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

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 este modo, también se mejora la seguridad general de la API.

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

5. Cacheabilidad

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

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

El resultado es sencillo: en lugar de que el cliente envíe varias solicitudes difíciles o costosas en un breve espacio de tiempo, sólo tiene que hacerlo una vez.

6. Código a la carta

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 para la seguridad.

El concepto es permitir que el código o los applets se envíen a través de la API y se utilicen para la aplicación. Como puedes imaginar, el código desconocido de una fuente sospechosa podría hacer algún daño, así que esta restricción es mejor dejarla para las API internas, donde tienes menos que temer a los hackers y a la gente con malas intenciones. Otro inconveniente es que el código tiene que estar en el lenguaje de programación apropiado para la aplicación, lo que no siempre es el caso.

La ventaja es que el "código a la carta" 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.

¿Son las API REST el camino hacia el futuro?

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

La principal preocupación de muchos desarrolladores y expertos en seguridad es lo explotables que pueden ser las API web si se crean sin el cuidado adecuado. 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 llevó a desarrollar WebScrapingAPI, una API REST de extracción de datos que se encarga de todo, desde la rotación de proxy hasta el renderizado de Javascript y la resolución de CAPTCHAs. Compruébelo para ver lo que puede hacer una API REST.