Una aplicación cliente (como una app para dispositivos móviles, un navegador web o un servidor diferente) inicia una solicitud a la API para realizar una acción. Esta solicitud se envía a una URL específica y contiene un método HTTP, encabezados con metadatos y, a veces, un cuerpo de solicitud con datos.

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

Después de 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 para éxito, 404 No encontrado si el recurso no existe, 401 No autorizado para problemas de seguridad), junto con los datos solicitados en el cuerpo de la respuesta.

Los datos transferidos entre el cliente y el servidor son una "representación" del estado del recurso. El formato JSON (notación de objeto de JavaScript) es el 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 cumple con estas restricciones se considera "RESTful".

Los recursos son un concepto básico en REST. Son objetos 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 un recurso.

Cada recurso se identifica de forma única con un URI. Una API bien diseñada usa 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 específico con el ID 123.

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

Cada solicitud de un cliente al servidor debe contener toda la información que el servidor necesita para comprender y procesar la solicitud. El servidor no almacena ningún contexto de cliente o estado de sesión entre solicitudes. Esta restricción hace que las APIs de REST sean altamente escalables, ya que cualquier servidor puede manejar 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 las aplicaciones del cliente y del servidor evolucionen de forma independiente.

REST requiere una interfaz coherente y uniforme entre el cliente y el servidor. Esto se logra a través del 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 intermediario puede 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 de REST no puede saber normalmente si está conectado directo al servidor final o a un intermediario en el camino. Se pueden introducir servidores intermediarios, como puertas de enlace de API o balanceadores de cargas, en la arquitectura para mejorar la escalabilidad, la seguridad y el rendimiento.

Un caso de uso común es una app de clima para dispositivos móviles que recupera el clima actual de una ubicación específica desde una API pública de clima.

La aplicación cliente realiza una solicitud HTTP GET al extremo de la 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 extremo 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 simple.