Una aplicación cliente (como una aplicación móvil, un navegador web u otro servidor) inicia una solicitud a la API para realizar una acción. Esta solicitud se envía a una URL específica e incluye un método HTTP, encabezados con metadatos y, a veces, un cuerpo de solicitud con datos.

El servidor recibe y valida la solicitud, y confirma que el cliente está autenticado y autorizado para realizar la acción solicitada. A continuación, procesa la solicitud, lo que podría implicar recuperar datos de una base de datos, crear un nuevo recurso o actualizar uno que ya exista.

Tras procesar la solicitud, el servidor envía una respuesta al cliente. Esta respuesta incluye un código de estado HTTP que indica el resultado (por ejemplo, 200 OK si la solicitud se ha realizado correctamente, 404 No encontrado si el recurso no existe o 401 No autorizado si hay problemas de seguridad), junto con los datos solicitados en el cuerpo de la respuesta.

Los datos que se transfieren entre el cliente y el servidor son una "representación" del estado del recurso. JSON (JavaScript Object Notation) es el formato más común para estos datos porque es ligero, legible por humanos y fácil de analizar para los lenguajes de programación.

La potencia y la escalabilidad de REST provienen de un conjunto de restricciones arquitectónicas que guían su diseño. Un sistema que se ajusta a estas restricciones se considera "RESTful".

Un recurso es un concepto fundamental en REST. Es un objeto con un tipo, datos asociados, relaciones con otros recursos y un conjunto de métodos que operan en él. Por ejemplo, en una API de comercio electrónico, un "producto" o un "cliente" serían recursos.

Cada recurso se identifica de forma única mediante un URI. Una API bien diseñada utiliza URIs limpios, descriptivos y coherentes para identificar sus recursos. Por ejemplo, /users podría identificar una colección de usuarios y /users/123 identificaría a un usuario concreto con el ID 123.

Un cliente no interactúa directamente con el recurso, sino con una representación de ese recurso. El formato de representación más común es JSON, pero también se pueden usar otros como XML o HTML. Esto proporciona una forma flexible de representar el estado de un recurso.

Cada solicitud que un cliente envía al servidor debe contener toda la información que el servidor necesita para entender y procesar la solicitud. El servidor no almacena ningún contexto de cliente ni estado de sesión entre solicitudes. Esta restricción hace que las APIs REST sean muy escalables, ya que cualquier servidor puede gestionar cualquier solicitud.

El cliente y el servidor están separados, y la API actúa como interfaz entre ellos. Esta separación de responsabilidades permite que la aplicación del lado del cliente y la aplicación del lado del servidor evolucionen de forma independiente.

REST requiere una interfaz uniforme y coherente entre el cliente y el servidor. Esto se consigue mediante el uso de métodos HTTP estándar, URIs para la identificación de recursos e hipermedia como motor del estado de la aplicación (HATEOAS).

Las respuestas del servidor deben definirse como almacenables en caché o no almacenables en caché. Cuando una respuesta se puede almacenar en caché, un cliente o un intermediario pueden reutilizarla para solicitudes idénticas posteriores, lo que puede mejorar significativamente el rendimiento y reducir la carga del servidor.

Un cliente conectado a una API REST no suele poder saber si está conectado directamente al servidor final o a un intermediario. Se pueden introducir servidores intermediarios, como pasarelas de APIs o balanceadores de carga, en la arquitectura para mejorar la escalabilidad, la seguridad y el rendimiento.

Un caso práctico habitual es una aplicación meteorológica para móviles que obtiene el tiempo actual de una ubicación específica a partir de una API meteorológica pública.

La aplicación cliente hace una solicitud HTTP GET al endpoint de API, que incluye la ubicación y una clave de API para la autenticación.

El servidor procesa la solicitud, recupera los datos meteorológicos de la ubicación especificada y devuelve una respuesta JSON.

En una arquitectura de microservicios, un servicio de "producto" podría necesitar obtener un precio actualizado de un servicio de "inventario" antes de mostrarlo en un sitio de comercio electrónico. 

El servicio de productos hace una solicitud HTTP GET interna al endpoint de la API del servicio de inventario para un ID de producto específico.

El servicio de inventario busca el precio actual y devuelve una respuesta JSON sencilla.