Um serviço ReSTful ideal permite que os clientes (que podem não estar no navegador) executem qualquer tarefa necessária em uma solicitação ; porque o estado completo necessário para isso é mantido pelo cliente, não pelo servidor. Como o cliente tem controle total do estado, ele pode criar o estado sozinho (se isso for legítimo) e apenas falar com a API para "terminar".
A exigência de cookies pode dificultar isso. Para os clientes, além dos navegadores, o gerenciamento de cookies é um grande inconveniente em comparação com os parâmetros de consulta, os cabeçalhos de solicitações simples ou o corpo da solicitação. Por outro lado, no navegador, o uso de cookies pode tornar muitas coisas muito mais simples.
Portanto, uma API pode procurar primeiro no cabeçalho Authorization dos dados de autenticação necessários, pois esse é provavelmente o lugar onde os clientes não navegadores preferirão colocá-lo, mas para simplificar e agilizar os clientes baseados em navegador, também procura um cookie de sessão para login no servidor, mas apenas se o cabeçalho normal Authorization estiver faltando.
Outro exemplo pode ser um pedido complexo que normalmente requer muitos parâmetros definidos. Um cliente não interativo não teria problemas para compactar todos esses dados em uma solicitação, mas uma interface baseada em formulário HTML pode preferir dividir a solicitação em várias páginas (algo como um conjunto de páginas de 'assistente') para que os usuários não sejam apresentados com opções que não são aplicáveis com base nas seleções anteriores. Todas as páginas intermediárias poderiam armazenar os valores em cookies do lado do cliente, de modo que somente a última página, na qual o usuário realmente envia a solicitação, tenha qualquer efeito colateral do servidor. A API poderia procurar os atributos necessários no corpo da solicitação e voltar a analisar os cookies se os parâmetros necessários não estivessem lá.
Editar: no RE ao comentário do @Konrad abaixo:
Tokens in comparison are harder to implement especially because you can't easily invalidate the token without storing them somewhere.
er ... você está validando os cookies no lado do servidor, certo? Só porque você disse ao navegador para descartar um cookie depois de 24 horas não significa que será. Esse cookie pode ser salvo por um usuário altamente técnico e reutilizado por muito tempo depois de ter "expirado".
Se você não quiser armazenar dados da sessão no lado do servidor, deverá armazená-lo no token (cookie ou outro). Um token de autenticação autônomo às vezes é chamado de Macaroon . Como isso é passado entre cliente e servidor (seja por cookie, como extra cabeçalhos, ou na própria entidade solicitante) é totalmente independente do próprio mecanismo de autenticação.