Parte 1: ¿Qué es REST? En esta parte veremos más de cerca cómo se produce la comunicación entre el cliente y el servidor. A lo largo del camino, revelaremos nuevos términos y les daremos explicaciones. Para que todo quede claro, analizaremos la comunicación cliente-servidor usando el ejemplo de alguna aplicación RESTful. Digamos que estamos desarrollando una aplicación web que es capaz de almacenar información sobre los clientes y sus pedidos. Aquellos. nuestro sistema es capaz de manipular algunas entidades: crearlas, editarlas, eliminarlas y proporcionar información sobre ellas. Estas entidades serán:
clientes - clientes;
pedidos - pedidos de clientes;
artículos - bienes.
En la arquitectura REST, los clientes envían solicitudes al servidor para obtener o modificar datos, y los servidores envían respuestas a los clientes a sus solicitudes.
Peticiones
Las solicitudes de los clientes casi siempre se realizan a través de HTTP. En general, las solicitudes HTTP constan de varios componentes:
método HTTP;
título;
URI;
cuerpo de la solicitud.
A continuación veremos cada componente con más detalle.
URI y recursos
Los datos que los clientes obtienen o modifican a través de solicitudes se denominan recursos. La base de la interacción cliente-servidor es la manipulación de recursos. Los recursos en REST son cualquier cosa a la que se le pueda dar un nombre. En cierto sentido, son como clases en Java. En Java podemos crear una clase para cualquier cosa. Lo mismo ocurre en REST: un recurso puede ser cualquier cosa: un usuario, un documento, un informe, un pedido. Todo esto puede ser una abstracción de alguna entidad o algo concreto, por ejemplo, un archivo: una imagen, un video, una animación, un archivo PDF. Para nuestro ejemplo, tenemos 3 recursos:
clientes - clientes;
pedidos - pedidos de clientes;
artículos - bienes.
Los clientes envían solicitudes a los llamados puntos finales o puntos finales. En pocas palabras, un punto final es algo así como una dirección en la red. Para profundizar más, un punto final es un URI : una secuencia de caracteres que identifica un recurso físico o abstracto. Identificador uniforme de recursos: un identificador de recursos unificado. A veces, el punto final, o URI, se denomina ruta: la ruta a un recurso. A los efectos de este artículo, utilizaremos el término URI. Cada recurso específico debe tener un URI único. La responsabilidad de garantizar que cada recurso tenga siempre su propia URI recae en el desarrollador del servidor. En nuestro ejemplo, somos los desarrolladores, por lo que lo haremos como sabemos. Así como en una base de datos relacional suele ser habitual establecer la clave principal en un determinado ID numérico, en REST cada recurso tiene su propio ID. A menudo sucede que el ID de un recurso en REST coincide con el ID del registro en la base de datos en el que se almacena la información sobre este recurso. Los URI REST suelen comenzar con la forma plural de un sustantivo que describe algún recurso. Por ejemplo, de la palabra clientes. A continuación, se indica una ID mediante una barra diagonal: el identificador de un cliente específico. Ejemplos:
/clients - URI de todos los clientes existentes;
/clients/23 - URI de un cliente específico, es decir, el cliente con ID=23;
/clients/4: URI de un cliente específico, es decir, el cliente con ID=4.
Pero eso no es todo. Podemos ampliar el URI agregándole órdenes:
/clients/4/orders — URI de todos los pedidos del cliente nº 4;
/clients/1/orders/12 - URI del pedido nº 12 del cliente nº 1.
Si continuamos esta cadena y agregamos bienes, obtenemos:
/clients/1/orders/12/items: URI de la lista de todos los productos del pedido nº 12 realizado por el cliente nº 1.
Con los niveles de anidamiento, la clave es hacer que los URI sean intuitivos.
método HTTP
El método HTTP (método HTTP en inglés) es una secuencia de cualquier carácter, excepto controles y separadores, que indica la operación principal en un recurso. Existen varios métodos HTTP comunes. Enumeramos los que se utilizan con mayor frecuencia en los servicios RESTful:
GET: se utiliza para obtener información sobre un recurso específico (a través de ID) o una colección de recursos;
POST: se utiliza para crear un nuevo recurso;
PUT: se utiliza para cambiar un recurso (a través de ID);
ELIMINAR: se utiliza para eliminar un recurso (a través de ID).
Encabezamientos
Las solicitudes, así como las respuestas, contienen encabezados HTTP. Envían información adicional sobre la solicitud (o respuesta). Los encabezados son pares clave-valor. Puede leer la lista de los títulos más comunes en la página de Wikipedia . Con REST, los clientes a menudo pueden enviar un encabezado de aceptación en su solicitud al servidor. Es necesario que el servidor sepa en qué formato el cliente espera recibir una respuesta de él. En la llamada lista de tipos MIME se presentan varias opciones de formato. MIME (Extensiones multipropósito de correo de Internet) es una especificación para codificar información y formatear mensajes para que puedan enviarse a través de Internet. Cada tipo MIME consta de dos partes, separadas por una barra: un tipo y un subtipo. Ejemplos de tipos MIME para diferentes tipos de archivos:
En total, la solicitud podrá tener el siguiente encabezado:
Accept:application/json
Este encabezado le dice al servidor que el cliente espera recibir una respuesta en formato JSON.
Cuerpo de la solicitud
Un mensaje enviado por el cliente al servidor. Si una solicitud tiene cuerpo o no depende del tipo de solicitud HTTP. Por ejemplo, las solicitudes GET y DELETE normalmente no contienen ningún cuerpo de solicitud. Pero PUT y POST pueden contener: se trata del propósito funcional del tipo de solicitud. Después de todo, para recibir datos y eliminarlos por identificación (que se transmite en la URL), no es necesario enviar datos adicionales al servidor. Pero para crear un nuevo recurso (solicitud POST), debe transferir este recurso. Lo mismo ocurre con la modificación de un recurso existente. En REST, los formatos XML o JSON se utilizan con mayor frecuencia para transmitir el cuerpo de la solicitud. El formato más común es JSON. Supongamos que queremos enviar una solicitud al servidor y en ella crear un nuevo recurso. Si recuerdas, como ejemplo miramos una aplicación que gestiona los pedidos de los clientes. Digamos que queremos crear un nuevo cliente. En nuestro caso, almacenamos la siguiente información sobre los clientes: Nombre Correo electrónico Número de teléfono Entonces el cuerpo de dicha solicitud podría ser el siguiente JSON:
Edite el cliente n.º 1 de la siguiente manera:
Nombre: Ben
Correo electrónico: bigben@jr.com
Tel. — +380 (190) 346-42-13
DELETE /clients/12/orders/6
Eliminar el pedido No. 6 del cliente No. 12 del sistema
Respuestas
Digamos algunas palabras sobre las respuestas del servidor. La respuesta suele constar de las siguientes partes:
código de respuesta;
encabezados;
cuerpo de respuesta.
En general, los encabezados de respuesta no son muy diferentes de los encabezados de solicitud. Además, algunos encabezados se utilizan tanto en respuestas como en solicitudes. Creo que todo está claro también con el cuerpo de la respuesta. El organismo suele devolver información que el cliente solicitó. La información se puede devolver en el mismo formato JSON para solicitudes GET. Pero la última parte es un poco más interesante.
Códigos de respuesta HTTP
Echemos un vistazo más de cerca a los códigos de respuesta HTTP. Aquí hay una cita de Wikipedia: El código de estado HTTP es parte de la primera línea de la respuesta del servidor para solicitudes a través del protocolo HTTP. Es un número entero con tres dígitos decimales. El primer dígito indica la clase de la condición. El código de respuesta suele ir seguido de una frase explicativa en inglés separada por un espacio, que explica a la persona el motivo de esa respuesta en particular. Ejemplos:
201 Creado;
401 No autorizado;
507 Almacenamiento insuficiente.
El cliente aprende del código de respuesta sobre los resultados de su solicitud y determina qué acciones tomar a continuación. Los códigos de respuesta se dividen en varios grupos:
1ХХ - informativo;
2ХХ - informar sobre los casos de aceptación y procesamiento exitosos de la solicitud de un cliente;
3XX : informa al cliente que para completar con éxito la operación, es necesario realizar otra solicitud, generalmente utilizando un URI diferente;
4ХХ - error del cliente. Por ejemplo, una solicitud construida incorrectamente o el conocido código 404 No encontrado, que puede ocurrir cuando un cliente solicita un recurso inexistente;
5ХХ - error del servidor. Devuelto al cliente si la operación falla por culpa del servidor.
GO TO FULL VERSION