¿qué es REST?

transferencia de Estado de representación

REST, o transferencia de Estado de representación, es un estilo arquitectónico para proporcionar estándares entre sistemas informáticos en la web, lo que facilita que los sistemas se comuniquen entre sí. Los sistemas compatibles con REST, a menudo llamados sistemas RESTful, se caracterizan por la forma en que son apátridas y separan las preocupaciones del cliente y el servidor. Vamos a entrar en lo que estos términos significan 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 conozca al otro. Esto significa que el código en el lado del cliente puede ser cambiado en cualquier momento sin afectar el funcionamiento del servidor, y el código en el lado del servidor se puede cambiar sin afectar a la operación del cliente.

mientras cada lado sepa qué formato de mensajes enviar a la otra, se pueden mantener modulares y separados., Separando las preocupaciones de la interfaz de usuario de las preocupaciones del almacenamiento de datos, mejoramos la flexibilidad de la interfaz entre 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 acceden a los mismos extremos REST, realizan las mismas acciones y reciben las mismas respuestas.,

Statelessness

Los sistemas que siguen el paradigma REST son apátridas, 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 mensajes anteriores. Esta limitación de la apatridia se aplica mediante el uso de recursos, en lugar de órdenes. Los recursos son los sustantivos de la Web: describen cualquier objeto, documento o cosa que pueda necesitar almacenar o enviar a otros servicios.,

debido a que los sistemas REST interactúan a través de 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 al 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 recuperar 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.

realizar solicitudes

REST requiere que un cliente realice una solicitud al servidor para recuperar o modificar datos en el servidor.,lient para pasar información sobre la solicitud

Una ruta a un recurso

Un cuerpo de mensaje opcional que contiene datos

verbos HTTP

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

• GET — recuperar 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)
• eliminar — eliminar un recurso específico por ID

puede obtener más información sobre estos verbos HTTP en el siguiente artículo de codecademy:

• ¿Qué es CRUD?,

encabezados y aceptar parámetros

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 entender o procesar. Las opciones para tipos de contenido son tipos MIME (o extensiones multipropósito de correo de Internet, sobre las que puede obtener más información en los documentos web de MDN.,los tipos MIME, utilizados para especificar los tipos de contenido en el campo Accept, consisten en un type y un subtype. Están separados por una barra diagonal (/).

por ejemplo, un archivo de texto que contenga HTML se especificaría con el tipo text/html. Si este archivo de texto contiene CSS en su lugar, se especificaría como text/css. Un archivo de texto genérico sería denotado como text/plain. Sin embargo, este valor predeterminado, text/plain, no es un valor general., Si un cliente espera text/css y recibe text/plain, no podrá reconocer el contenido.

otros tipos y subtipos de uso común:

por ejemplo, un cliente que accede a un recurso con id 23 en un articles recurso en un servidor puede enviar una solicitud GET como esta:

ed5d35ebb2″> el campo de encabezado en este caso está diciendo que el cliente aceptará el contenido entext/html oapplication/xhtml.,

Paths

Las solicitudes 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 qué está pasando.

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

una ruta como fashionboutique.com/customers/223/orders/12 es clara en lo que apunta, incluso si nunca ha visto esta ruta específica antes, porque es jerárquica y descriptiva., Podemos ver que estamos accediendo al pedido con id 12 para el cliente con id

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

si estamos intentando acceder a un único recurso, necesitaríamos añadir un id a la ruta.Por ejemplo:GET fashionboutique.com/customers/:id recupera el elemento en el customers recursos con la etiqueta id especificado.DELETE fashionboutique.com/customers/:id — elimina el elemento en la etiqueta customers recursos con la etiqueta id especificado.,

enviando respuestas

tipos de contenido

en los casos en que el servidor esté enviando una carga útil de datos al cliente, el servidor debe incluir un content-type en el encabezado de la respuesta. Este campo de encabezado 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, al igual que en el campo accept del encabezado de la solicitud., El content-type que el servidor envía 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 intenta acceder a un recurso con id 23 en un articles recursos con esta Petición:

El servidor puede enviar el contenido con el encabezado de respuesta:

Esto significaría que el contenido solicitado se está volviendo en el cuerpo de la respuesta con un content-type de text/html, que el cliente dijo que sería capaz de aceptar.,

Códigos de respuesta

Las respuestas del servidor contienen códigos de estado para alertar al cliente sobre el éxito de la operación. Como desarrollador, usted no necesita saber de cada código de estado (hay muchos de ellos), pero usted debe saber los más comunes y cómo se utilizan:

para cada verbo HTTP, hay códigos de estado esperados que un servidor debe devolver si tiene éxito:

• GET — return 200 (OK)
• POST — return 201 (CREATED)
• PUT — return 200 (OK)
• delete — devuelve 204 (sin contenido)si la operación falla, devuelve el código de estado más específico posible correspondiente al problema que se encontró.,

ejemplos de solicitudes y Respuestas

digamos que tenemos una aplicación que le permite ver, crear, editar y eliminar clientes y pedidos de una pequeña tienda de ropa alojada en fashionboutique.com. Podríamos crear una API HTTP que permita a un cliente realizar estas funciones:

si quisiéramos ver a todos los clientes, la solicitud se vería así:

un posible encabezado de respuesta se vería como:

seguido del customers data requested in application/json format.,

Crear un nuevo cliente mediante la publicación de los datos:

a continuación, El servidor genera un id para ese objeto y la devuelve al cliente, con un encabezado como:

Para ver un solo cliente lo conseguimos mediante la especificación de que el cliente id:

Una posible encabezado de respuesta sería:

seguido por los datos de la etiqueta customer recursos con la etiqueta id 23 application/json formato.,

Podemos actualizar ese cliente poniendo los nuevos datos:

un posible encabezado de respuesta tendría Status Code: 200 (OK), para notificar al cliente que el elemento con id 123 ha sido modificado.

también podemos eliminar a ese cliente especificando su id:

La respuesta tendría un encabezado que contendría Status Code: 204 (NO CONTENT), notificando al cliente que el elemento con id 123 se ha eliminado, y nada en el cuerpo.,

practica con descanso

imaginemos que estamos construyendo un sitio de colección de fotos. Queremos hacer una API para realizar un seguimiento de los usuarios, lugares y fotos de esos lugares. Este sitio tiene un index.html y un style.css. Cada usuario tiene un nombre de usuario y una contraseña. Cada foto tiene un lugar y un propietario (es decir, el usuario que tomó la foto). Cada lugar tiene un nombre y una dirección.,d=»229c60b6ce»>

Request-POST /venuesResponse-201 (CREATED)Content-type: application/json

Request-POST /venues/:id/photosResponse-201 (CREATED)Content-type: application/json

PUT Requests

Request-PUT /users/:idResponse-200 (OK)

Request-PUT /venues/:idResponse-200 (OK)

Request-PUT /venues/:id/photos/:idResponse-200 (OK)

DELETE Requests

Request-DELETE /venues/:idResponse-204 (NO CONTENT)

Request-DELETE /venues/:id/photos/:idResponse-204 (NO CONTENT)