Um aplicativo cliente (como um app para dispositivos móveis, navegador da Web ou outro servidor) inicia uma solicitação para a API realizar uma ação. Essa solicitação é enviada a um URL específico e inclui um método HTTP, cabeçalhos com metadados e, às vezes, um corpo de solicitação com dados.

O servidor recebe e valida a solicitação, confirmando que o cliente está autenticado e autorizado a realizar a ação solicitada. Em seguida, ele processa a solicitação, o que pode envolver a recuperação de dados de um banco de dados, a criação de um novo recurso ou a atualização de um recurso atual.

Depois de processar a solicitação, o servidor envia uma resposta de volta ao cliente. Essa resposta inclui um código de status HTTP que indica o resultado (por exemplo, 200 "OK" quando for bem-sucedido, "404 Not Found" se o recurso não existir, "401 Unauthorized" para problemas de segurança), além dos dados solicitados no corpo da resposta.

Os dados transferidos entre o cliente e o servidor são uma "representação" do estado do recurso. JSON (JavaScript Object Notation) é o formato mais comum para esses dados porque é leve, legível por humanos e fácil de analisar para linguagens de programação.

O poder e a escalonabilidade do REST vêm de um conjunto de restrições arquitetônicas que orientam seu design. Um sistema que segue essas restrições é considerado "RESTful".

Um recurso é um conceito fundamental no REST. É um objeto com um tipo, dados associados, relações com outros recursos e um conjunto de métodos que operam nele. Por exemplo, em uma API de e-commerce, um "produto" ou um "cliente" seriam recursos.

Cada recurso é identificado exclusivamente por um URI. Uma API bem projetada usa URIs limpas, descritivas e consistentes para identificar seus recursos. Por exemplo, /users pode identificar uma coleção de usuários, e /users/123 identificaria um usuário específico com o ID 123.

Um cliente não interage diretamente com o recurso, mas com uma representação dele. O formato de representação mais comum é o JSON, mas outros como XML ou HTML também podem ser usados. Isso oferece uma maneira flexível de representar o estado de um recurso.

Cada solicitação de um cliente para o servidor precisa conter todas as informações necessárias para que o servidor entenda e processe a solicitação. O servidor não armazena nenhum contexto do cliente ou estado da sessão entre as solicitações. Essa restrição torna as APIs REST altamente escalonáveis, porque qualquer servidor pode lidar com qualquer solicitação.

O cliente e o servidor são separados, e a API atua como a interface entre eles. Essa separação de preocupações permite que o aplicativo do lado do cliente e o aplicativo do lado do servidor evoluam de forma independente.

O REST exige uma interface consistente e uniforme entre o cliente e o servidor. Isso é feito com o uso de métodos HTTP padrão, URIs para identificação de recursos e hipermídia como o mecanismo de estado do aplicativo (HATEOAS).

As respostas do servidor devem ser definidas como armazenáveis em cache ou não armazenáveis em cache. Quando uma resposta pode ser armazenada em cache, um cliente ou intermediário pode reutilizar essa resposta para solicitações idênticas subsequentes, melhorando significativamente o desempenho e reduzindo a carga do servidor.

Um cliente conectado a uma API REST normalmente não consegue saber se está conectado diretamente ao servidor final ou a um intermediário no caminho. É possível introduzir servidores intermediários, como gateways de API ou balanceadores de carga, na arquitetura para melhorar a escalonabilidade, a segurança e o desempenho.

Um caso de uso comum é um app de previsão do tempo para dispositivos móveis que busca a previsão atual para um local específico em uma API pública de previsão do tempo.

O aplicativo cliente faz uma solicitação HTTP GET ao endpoint da API, incluindo o local e uma chave de API para autenticação.

O servidor processa a solicitação, recupera os dados meteorológicos do local especificado e retorna uma resposta JSON.

Em uma arquitetura de microsserviços, um serviço de "produto" talvez precise receber um preço atualizado de um serviço de "inventário" antes de exibi-lo em um site de e-commerce. 

O serviço de produtos faz uma solicitação HTTP GET interna ao endpoint da API do serviço de inventário para um ID de produto específico.

O serviço de inventário pesquisa o preço atual e retorna uma resposta JSON simples.