RESPRESENTATIONAL STATE TRANSFER

REST, o REpresentational State Transfer, es un estilo arquitectónico (IT) para proporcionar estándares entre sistemas informáticos en la web, lo que facilita la comunicación entre los sistemas. Los sistemas compatibles con REST, a menudo llamados sistemas RESTful, se caracterizan por la forma en que no tienen estado y separan las preocupaciones del cliente y el servidor. Veremos qué significan estos términos y por qué son características beneficiosas para los servicios en la Web.

SEPARACIÓN DE CLIENTE Y SERVIDOR

En el estilo arquitectónico REST, la implementación del cliente y la implementación del servidor se pueden hacer de forma independiente sin que cada uno sepa del otro. Esto significa que el código en el lado del cliente se puede cambiar en cualquier momento sin afectar la operación del servidor, y el código en el lado del servidor se puede cambiar sin afectar la operación del cliente.

Mientras cada lado sepa qué formato de mensajes enviar al otro, se pueden mantener modulares y separados. Al separar las preocupaciones de la interfaz de usuario de las preocupaciones de almacenamiento de datos, mejoramos la flexibilidad de la interfaz en todas las plataformas y mejoramos la escalabilidad simplificando los componentes del servidor. Además, la separación permite a cada componente la capacidad de evolucionar de forma independiente.

Al usar una interfaz REST, diferentes clientes llamas a los mismos endpoints REST, realizan las mismas acciones y reciben las mismas respuestas.

CARENCIA DE ESTADO

Los sistemas que siguen el paradigma REST no tienen estado, lo que significa que el servidor no necesita saber nada sobre en qué estado se encuentra el cliente y viceversa. De esta manera, tanto el servidor como el cliente pueden entender cualquier mensaje recibido, incluso sin ver los mensajes anteriores. Esta restricción de la carencia de estado se impone mediante el uso de recursos, en lugar de comandos. Los recursos son los sustantivos de la Web: describen cualquier objeto, documento o elemento que necesites almacenar o enviar a otros servicios.

Debido a que los sistemas REST interactúan a través de las operaciones estándar en los recursos, no dependen de la implementación de interfaces.

Estas restricciones ayudan a las aplicaciones RESTful a lograr confiabilidad, rendimiento rápido y escalabilidad, como componentes que se pueden administrar, actualizar y reutilizar sin afectar el sistema en su conjunto, incluso durante el funcionamiento del sistema.

Ahora, exploraremos cómo ocurre realmente la comunicación entre el cliente y el servidor cuando implementamos una interfaz RESTful.

COMUNICACIÓN ENTRE CLIENTE Y SERVIDOR

En la arquitectura REST, los clientes envían solicitudes para recibir o modificar recursos, y los servidores envían respuestas a estas solicitudes. Echemos un vistazo a las formas estándar de hacer solicitudes y enviar respuestas.

HACIENDO LLAMADOS

REST requiere que un cliente realice una solicitud al servidor para recibir o modificar datos en el servidor. Un llamado (request) generalmente consiste en:

• Un verbo HTTP, que define qué tipo de operación realizar.
• Un encabezado, que permite al cliente pasar información sobre la solicitud.
• Una dirección hacia un recurso.
• Un cuerpo de mensaje opcional que contiene datos.

VERBOS HTTP

Hay 4 verbos HTTP básicos que usamos en solicitudes para interactuar con recursos en un sistema REST:

• GET
  • Recibir un recurso específico (por ID) o una colección de recursos.
• POST
  • Crear un nuevo recurso.
• PUT
  • Actualizar un recurso específico (por ID).
• DELETE
  • Elimina un recurso específico por ID.

ENCABEZADOS Y PARÁMETROS DE ACEPTACIÓN

En el encabezado de la solicitud, el cliente envía el tipo de contenido que puede recibir del servidor. Esto se denomina campo Accept y garantiza que el servidor no envíe datos que el cliente no pueda comprender o procesar. Las opciones para los tipos de contenido son Tipos MIME (o extensiones de correo de internet multipropósito).

Los «MIME types», utilizados para especificar los tipos de contenido en el campo Accept, consisten en un type y un subtype. Están separados por una barra (/).

Por ejemplo, un archivo de texto que contenga HTML se especificará con el tipo text/html. Si este archivo de texto contiene CSS, se especificará como text/css. Un archivo de texto genérico se denotaría como text/plain. Sin embargo, este valor predeterminado, text/plain, no es un «recibe todo». Si un cliente espera text/css y recibe text/plain, no podrá reconocer el contenido.

Otros tipos y subtipos de uso común:

• image:
  • image/png, image/jpeg, image/gif
• audio:
  • audio/wav, image/mpeg
• video:
  • video/mp4, video/ogg
• application:
  • application/json, application/pdf, application/xml, application/octet-stream

Por ejemplo, un cliente que accede a un recurso con id23 en un recurso de artículos en un servidor podría enviar una solicitud GET como esta:

GET /articles/23
Accept: text/html, application/xhtml

El campo Accept encabezado en este caso indica que el cliente aceptará el contenido en text/html o application/xhtml.

RUTAS

Las solicitudes (o requests) deben contener una ruta a un recurso en el que se debe realizar la operación. En las API RESTful, las rutas deben diseñarse para ayudar al cliente a saber lo que está sucediendo.

Convencionalmente, la primera parte de la ruta debe ser la forma plural del recurso. Esto mantiene las rutas anidadas simples de leer y fáciles de entender.

Un camino como fashionboutique.com/customers/223/orders/12 es claro a donde apunta, incluso si nunca antes ha visto este camino específico, porque es jerárquico y descriptivo. Podemos ver que estamos accediendo al pedido con id 12 para el cliente con id 223.

Las rutas deben contener la información necesaria para ubicar un recurso con el grado de especificación necesario. Cuando se hace referencia a una lista o colección de recursos, no es necesario agregar una ida una solicitud POST a una ruta fashionboutique.com/customers, no necesitaría un identificador adicional, ya que el servidor generará una id para el nuevo objeto.

Si estamos intentando acceder a un único recurso, necesitaríamos agregar una id a la ruta. Por ejemplo: GET fashionboutique.com/customers/:id recupera el artículo en el recurso de los customers con la id especificada. DELETE fashionboutique.com/customers/:id elimina el artículo en el recurso de los clientes con la id especificada.

RESPUESTAS

TIPOS DE CONTENIDO

En los casos en que el servidor envía una carga de datos al cliente, el servidor debe incluir un content-type en el encabezado de la respuesta. Este encabezado de tipo content-type alerta al cliente sobre el tipo de datos que está enviando en el cuerpo de respuesta. Estos tipos de contenido son tipos MIME, tal como se encuentran en el campo accept del encabezado de la solicitud. El content-type que el servidor devuelve en la respuesta debe ser una de las opciones que el cliente especificó en el campo accept de la solicitud.

Por ejemplo, cuando un cliente accede a un recurso con id 23 en un recurso articles con esta solicitud GET:

GET /articles/23 HTTP/1.1
Accept: text/html, application/xhtml

El servidor podría devolver el contenido con el encabezado de respuesta:

HTTP/1.1 200 (OK)
Content-Type: text/html

Esto significaría que el contenido solicitado se devuelve en el cuerpo de la respuesta con un content-type de text/html, que el cliente dijo que podría aceptar.

CÓDIGOS DE RESPUESTA

Las respuestas del servidor contienen códigos de estado para alertar al cliente sobre información sobre el éxito de la operación. Como desarrollador, no necesitas conocer todos los códigos de estado (hay muchos de ellos), pero debes conocer los más comunes y cómo se usan:

Para cada verbo HTTP, hay códigos de estado esperados que un servidor debe devolver al tener éxito:

• GET – devuelve 200 (OK)
• POST – devuelve 201 (CREATED)
• PUT – devuelve 200 (OK)
• DELETE – devuelve 204 (NO CONTENT) Si la operación falla, devuelve el código de respuesta más específico posible correspondiente al problema que se encontró.