Conceptos Básicos de la Arquitectura REST (REpresentational State Transfer)

En esta entrada del blog les compartiré los conceptos básicos de la arquitectura REST, utilizada con APIs (Application Programming Interfaces). Durante el contenido de esta entrada explicaremos de forma muy simple los conceptos de REST, HTTP, Las peticiones HTTP más utilizadas y la diferencia entre API, API REST y Web Service. Veamos...

Un API REST (Interfaz de Programación de Aplicaciones basada en Transferencia de Estado Representacional) es un conjunto de reglas y convenciones que permite la comunicación entre sistemas a través de la web. REST es un estilo arquitectónico que utiliza los principios fundamentales de la World Wide Web y se ha convertido en un enfoque popular para diseñar servicios web debido a su simplicidad y escalabilidad. Su uso creció exponencialmente gracias a la proliferación de aplicaciones móviles pues nos permite separar el front del back, programar una sola vez la lógica de nuestra aplicación o sistema y usar las APIs REST para distintas plataformas, distintas vistas en distintos lenguajes de programación. Por ejemplo, puedo programar un API REST que haga "X" operación y que me devuelva un JSON (JavaScript Object Notation) con el resultado. Este archivo que me devuelve solo lo leeré y mostraré los datos en una interfaz, así que esa misma API REST la puedo consumir desde Java, C#, PHP, DART o prácticamente cualquier lenguaje de programación. UN API REST está basada en la arquitectura REST, usa el protocolo HTTP y tiene métodos para que las aplicaciones web se comuniquen entre sí de forma eficiente, siendo estos los más comunes GET, POST, PUT y DELETE.

Características de los Servicios Web Restful:

• Cliente y servidor separados.
• Sin estado: cada solicitud contiene toda la información.
• Interfaz con URIs y métodos como GET, POST, PUT, DELETE.
• Los recursos pueden tener diferentes formatos (XML, JSON).
• Transferencia de estado representacional: Cada recurso tiene un nombre único y puede ser modificado por su representación.

¿Cómo lo llamamos....API, API REST, Web Service, API Restful o Web Service Restful?

En primer lugar comenzaré por afirmar que n API es un concepto más amplio que puede utilizar diferentes estilos y protocolos, un por su parte API REST sigue un enfoque específico basado en los principios de REST y utiliza el protocolo HTTP como medio de comunicación principal. 

No debemos confundir un API, con un API REST y un Web Service (Servicio Web).  Una API es una interfaz, que incluso en Widows o en algún sistema operativo se usa para acceder a operaciones de bajo nivel. Un API REST es una interfaz que se utiliza como un servicio basado en HTTP y devuelve datos JSON o XML (eXtensible Markup Language) de forma predeterminada. Utiliza la arquitectura REST. Un servicio web es un servicio basado en la arquitectura SOA (Arquitectura Orientada a Servicios) y devuelve datos como XML. Un servicio web normalmente ofrece un WSDL (Web Service Description Language) desde el que puede crear stubs de cliente automáticamente. Podemos observar la diferencia entre Web Service y API REST en la siguiente imagen (tomada de: https://medium.com/beltranc/diferencia-entre-api-y-servicio-web-5f204af3aedb)

HTTP y API REST

El protocolo de transferencia de hipertexto, o también como HTTP, es un protocolo de comunicación que permite la transferencia de datos a través de la web. Fue desarrollado para mejorar la comunicación entre navegadores web y servidores. Las versiones anteriores de HTTP incluyen HTTP/1.0, HTTP/1.1 y, más recientemente, HTTP/2. Tim Berners-Lee propuso en 1989 un sistema de comunicación para documentos de hipertexto a través de Internet. Su visión era crear un sistema que permitiera a los usuarios acceder de manera sencilla a una gran cantidad de información, optando por desarrollar el protocolo HTTP en lugar de utilizar opciones más complejas y menos accesibles.

En 1996, se implementó HTTP/1.0, una versión mejorada que facilitaba transferencias más complejas, incluyendo imágenes. Al año siguiente, se lanzó HTTP/1.1, una versión revisada que se convirtió en la más ampliamente utilizada. En 2015, se introdujo HTTP/2.0, que incorporaba mejoras significativas en el rendimiento y la velocidad.

Los métodos HTTP que admite REST son: GET, POST, PUT y DELETE. Utilizados para las famosas operaciones CRUD (Create, Read, Update, Delete), el famoso ABC en México (Altas, Bajas y Cambios).

• GET permite recuperar información de un recurso en el servidor. 
• POST sirve para enviar datos al servidor para crear un nuevo recurso.
• PUT se utiliza para modificar un recurso en el servidor con la información que se le dé.
• DELETE es para eliminar un recurso en el servidor.

Códigos de estado HTTP

El código de respuesta o retorno es un número que indica que ha pasado con la petición. El resto del contenido de la respuesta dependerá del valor de este código. El sistema es flexible y de hecho la lista de códigos ha ido aumentando para así adaptarse a los cambios e identificar nuevas situaciones. Los principales son:

• Códigos con formato 1xx: Respuestas informativas. Indica que la petición ha sido recibida y se está procesando.
• Códigos con formato 2xx: Respuestas correctas. Indica que la petición ha sido procesada correctamente.
• Códigos con formato 3xx: Respuestas de redirección. Indica que el cliente necesita realizar más acciones para finalizar la petición.
• Códigos con formato 4xx: Errores causados por el cliente. Indica que ha habido un error en el procesado de la petición a causa de que el cliente ha hecho algo mal. 
• Códigos con formato 5xx: Errores causados por el servidor. Indica que ha habido un error en el procesado de la petición a causa de un fallo en el servidor.

Resumiendo un poco:

• Arquitectura Cliente-Servidor: Se basa en la separación de responsabilidades entre el cliente (quien realiza las solicitudes) y el servidor (que proporciona los recursos o servicios).
• Sin Estado (Stateless): Cada solicitud del cliente al servidor debe contener toda la información necesaria para entender y procesar la solicitud. El servidor no debe almacenar información sobre el estado del cliente entre solicitudes.
• Operaciones Bien Definidas: Las operaciones en un API REST se corresponden con los métodos HTTP estándar, como GET (para obtener datos), POST (para crear datos), PUT (para actualizar datos) y DELETE (para eliminar datos).
• Recursos Identificables: Los recursos, que pueden ser datos o servicios, son identificables mediante URLs (Uniform Resource Locators) únicas. Cada recurso tiene su propio identificador único.
• Representación de Recursos: Los recursos pueden tener múltiples representaciones, como JSON o XML. El cliente y el servidor acuerdan el formato de representación durante la comunicación.
• Interfaz Uniforme: La interfaz de un API REST sigue un conjunto de restricciones que proporcionan uniformidad en la interacción entre los componentes, lo que facilita su comprensión y uso.
• Lo ideal es esperar una respuesta con código de estado http 200, la cual indica que todo ha ido correctamente en la ejecución de nuestra API REST (End Point).
• Las API REST son una arquitectura estandarizada para crear APIs Web mediante métodos HTTP.  Son Servicios Web evolucionados que usan arquitectura REST y no SOA (service Oriented Architecture)
• No todas las APIs son Web Service, pero las API REST, resumiendo, son Web Services que utilizan la arquitectura REST y como formato de intercambio de información JSON.

La imagen siguiente muestra un pequeño resumen que utilizo bastante para diferenciar un Web Service de un API REST.

En una próxima entra haremos un ejemplo paso a paso para construir APIs REST en PHP para hacer las operaciones  CRUD. 

Felices fiestas, feliz navidad y prospero año 2024.  Les deseo mucha salud !!!

Es cuanto.

Si quieres citar este artículo en tu texto, documento, etc. puedes hacerlo de la siguiente forma:

Aguilar-Calderón, J. A. (12 de diciembre de 2023). Conceptos Básicos de la Arquitectura REST (REpresentational State Transfer). ANOVA LAB MX. https://anovalabmx.blogspot.com/2023/12/conceptos-basicos-de-la-arquitectura.html