Os cookies devem ser usados ​​em uma API RESTful?

Estou especificamente interessado em como os usuários executam operações autorizadas / autenticadas em uma API da web.

Os cookies de autenticação são compatíveis com a filosofia REST e por quê?

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 por conta própria (se for legítimo), e apenas conversar com a API para "concluir".

Exigir cookies pode tornar isso difícil. Para clientes além dos navegadores, gerenciar cookies é um inconveniente bastante grande comparado aos parâmetros de consulta, cabeçalhos simples de solicitação ou 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 Authorizationcabeçalho os dados de autenticação de que precisa, já que provavelmente é o lugar onde os clientes que não são navegadores preferem colocá-los, mas para simplificar e otimizar os clientes baseados em navegador, também pode procurar um cookie de sessão para logon no servidor, mas apenas se o Authorizationcabeçalho regular estiver ausente.

Outro exemplo pode ser uma solicitação complexa que normalmente requer muitos parâmetros configurados. Um cliente não interativo não teria problemas para agrupar 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 podem armazenar os valores nos cookies do lado do cliente, para que apenas a última página, na qual o usuário realmente envia a solicitação, tenha algum efeito colateral no servidor. A API poderia procurar os atributos necessários no corpo da solicitação e voltar a examinar os cookies se os parâmetros necessários não estivessem lá.

Edit: no RE para o comentário do @ Konrad abaixo:

Os tokens em comparação são mais difíceis de implementar, especialmente porque você não pode invalidar facilmente o token sem armazená-los em algum lugar.

er ... você está validando os cookies no servidor, certo? Só porque você disse ao navegador para descartar um cookie após 24 horas não significa que sim. Esse cookie pode ser salvo por um usuário altamente técnico e reutilizado muito tempo depois de "expirar".

Se você não deseja armazenar dados da sessão no lado do servidor, deve armazená-los no token (cookie ou não). Às vezes, um token de autenticação independente é chamado de Macaroon. Como isso é passado entre cliente e servidor (seja por cookie, como cabeçalhos extras ou na própria entidade de solicitação) é totalmente independente do mecanismo de autenticação.

Sim e não - depende de como você o usa.

Os cookies, se utilizados para manter o estado do cliente no cliente, para o cliente, do cliente e pelo cliente, são repousantes.

Se você está armazenando o estado do servidor no cookie, basicamente está apenas transferindo a carga para o cliente - o que não é tranquilo.

Então, quais são alguns exemplos?

Repousante:

• Detalhes de autenticação ou 'está logado'
• última página visualizada ou local no aplicativo etc.

Não repousante:

• Armazenando informações da sessão

A tranquilidade vem da apatridia - do servidor. Os clientes podem manter o estado do aplicativo e enviá-lo ao servidor para dizer onde estão, para que o servidor possa decidir para onde ir a partir daí. Basicamente, as sessões / estados precisam de dados históricos e dependem de solicitações anteriores, por exemplo, aplicativos repousantes não são ideais (não é viável ter um aplicativo repousante 100% puro, se você tiver uma tela de login :)

Pode-se usar cookies. O REST permite.

O REST exige que todas as informações da sessão sejam armazenadas no lado do cliente, mas quando se trata de autenticação, algumas informações precisam permanecer no lado do servidor por motivos de segurança.

Em uma das postagens do meu blog , existe um acordo geral de que os dados de autenticação são considerados fora do escopo em relação ao REST. Portanto, não há problema em os servidores manterem alguns dados desta sessão do lado deles.