Teoría de la API REST

El primer módulo terminó con la creación de una solicitud HTTP, su envío y la obtención de una respuesta.

Haremos esto muchas más veces en el futuro. Enviaremos peticiones a servidores de terceros. Haremos aplicaciones que por sí mismas acepten dichas peticiones y devuelvan una respuesta. Crearemos una lógica compleja para procesar las peticiones.

Por lo tanto, sería bueno estudiar a fondo todo lo relacionado con estas solicitudes, para analizarlas en detalle. Para no limitarse a copiar la petición en algún sitio y repetirla, sino para averiguar realmente cómo funciona todo.

Esto es lo que haremos en el segundo módulo. Vamos allá.

Teoría general

Empecemos con la teoría.

Si has hecho los deberes en el primer módulo y has estudiado la documentación, te habrás dado cuenta del acrónimo API. En realidad, es la documentación de la API lo primero que deben estudiar los desarrolladores si quieren entender la interacción con algún servicio o aplicación en la red.

API

API- Interfaz de programación de aplicaciones. Es una descripción de las formas en que el cliente y el servidor pueden comunicarse entre sí. Abrimos la documentación de la API y aprendemos de ella cómo obtener los datos necesarios del servidor.

Siempre queremos que esta interacción sea sencilla y comprensible. Esto simplifica la tarea tanto para los desarrolladores (no es necesario reinventar la rueda cuando se diseña un nuevo servicio) como para los usuarios (un servicio es mucho más fácil de aprender si funciona según el mismo principio que los servicios conocidos anteriormente). Y aquí conviene recordar un nuevo término: REST.

REST

REST es el acrónimo de Representational State Transfer (Transferencia de Estado Representativa). Puede que no suene muy claro, pero en pocas palabras, REST es un estilo de interacción (intercambio de información) entre un cliente y un servidor.

No se trata de un conjunto rígido de reglas y requisitos. REST no obliga a utilizar ningún lenguaje de programación en particular, ni se ciñe a directrices estrictas. REST se denomina estilo arquitectónico y define 6 principios que debe cumplir la arquitectura de un sistema.

En consecuencia, una API desarrollada teniendo en cuenta los principios de REST se denomina API REST, y las propias aplicaciones se denominan RESTful

Vamos a crear precisamente esas aplicaciones RESTful, por lo que conviene hablar enseguida de los principios que van a cumplir.

Principios RESTful

Modelo cliente-servidor. Este principio define la separación del cliente y el servidor, la diferenciación de sus necesidades. El cliente no tiene que preocuparse de cómo se almacenan los datos, lo principal es que se emitan a petición. A su vez, el servidor no se preocupa de lo que el cliente hará con estos datos, de cómo procesarlos y mostrarlos. Esto les permite desarrollarse de forma independiente y mejora la escalabilidad del sistema.

No hay estado. Este principio significa que el servidor no debe "pensar" la respuesta basándose en la experiencia previa con este cliente. Cualquier petición se realiza de forma que contenga toda la información necesaria para su procesamiento, independientemente de las peticiones anteriores.

Almacenamiento en caché. Para minimizar los datos transmitidos, existe un mecanismo de almacenamiento en caché. Por ejemplo, si se muestra un logotipo en alguna página, no tiene sentido solicitarlo al servidor cada vez. No cambia tan a menudo, bastará con obtenerlo una vez y guardarlo en el ordenador del cliente, en la caché. Pero si necesitamos obtener información sobre la velocidad actual del coche, la caché no nos servirá de nada. Este principio determina que los datos transmitidos por el servidor sean designados como almacenables en caché o no.

Interfaz uniforme. Este principio define un formato único de interacción cliente-servidor. La estructura de todas las peticiones debe ser la misma. Los datos deben enviarse en la misma forma, independientemente de quién los solicite.

Sistema por capas. El cliente y el servidor no se comunican necesariamente de forma directa. La transmisión de datos puede pasar por varios nodos intermedios. En este caso, el sistema está diseñado para que ni el cliente ni el servidor sepan si están interactuando con la aplicación final o con un nodo intermedio. Esto permite equilibrar la carga de los servidores y aumentar la escalabilidad.

Código bajo demanda (opcional). Es el único principio que no es obligatorio. Según el mismo, el cliente puede ampliar su funcionalidad descargando código ejecutable desde el servidor (por ejemplo, scripts). En este caso, el código debe ejecutarse sólo bajo demanda.