Estado RESTful persistente no cliente sem cookies

Há armazenamento local em HTML5, que permite manter os dados sem contaminar as solicitações HTTP que você faz. Ele se destina exatamente a esse caso de uso: aplicativos Javascript complexos que desejam armazenar informações persistentes localmente.

link

Observe que o REST não significa proibir todo o estado do servidor; às vezes, você realmente deseja atualizar as coisas; especialmente no exemplo "ticket aéreo", você pode criar explicitamente um objeto "reserva" antes do pagamento com um POST que retorna um URL para a reserva. O cliente, em seguida, trava na URL, mas o objeto do lado do servidor existe para evitar que o mesmo assento seja reservado duas vezes.

O ponto que a Roy Fielding faz sobre cookies está relacionado ao envio desses cookies para o servidor e à manutenção do estado no servidor com base nesses cookies. Usar um cookie puramente do lado do cliente para armazenar o estado por qualquer período de tempo não viola o REST e, na verdade, não diz respeito ao servidor.

EDITAR: Você pode armazenar um cookie em um caminho que não é usado pelo seu servidor. Dessa forma, você pode acessá-lo do seu javascript, mas nunca será enviado.

Você não precisa usar cookies, mas se você tiver recursos garantidos (por exemplo, meu carrinho de compras em vez do seu carrinho), então você precisa de alguma forma de detectar qual solicitação corresponde a qual de nós. Esse ID geralmente é mantido em um cookie, pois a detecção é realizada no servidor por meio de mecanismos de autenticação caros que você deseja armazenar temporariamente e repetir cada solicitação.

logicamente, não há nada que impeça você de realizar a autenticação em todas as solicitações. (exceto no mundo real, você não fará isso, a menos que tenha, digamos, certificados de clientes comprovando sua identidade para o servidor)

Eu imagino que você poderia usar algum identificador exclusivo conhecido pelo cliente e usá-lo como um mapeamento entre o cliente e o ID do usuário protegido após o login, mas eles são difíceis de obter e manter a segurança.

Você pode usar cookies para manter o estado do cliente, porque eles são um mecanismo de armazenamento do lado do cliente. Você pode usar outros mecanismos de armazenamento do lado do cliente, por exemplo, websql ou localstorage.

O único problema com os cookies, os cookies de sessão estão violando a restrição de apatridia. Então, a menos que você use cookies de sessão, você está bem. Você deve se perguntar o que aconteceria quando o servidor fosse reinicializado. No caso de cookies de sessão, sua sessão será perdida. No caso de cookies normais, nada relevante acontece, seus pedidos serão respondidos da mesma forma como antes.

Eu acho que quando o servidor escreve os cookies que é uma coisa de zona cinza, especialmente se estamos falando de cookies somente HTTP (que não são acessíveis no javascript do navegador). Nesse caso, o serviço altera diretamente o estado do cliente. Poderíamos argumentar que os cabeçalhos dos cookies são parte da representação, mas isso é uma meia verdade, eu acho. Se sua API REST tiver um domínio diferente do seu cliente, defina os cookies somente no domínio do cliente e acesse seu conteúdo, por exemplo, com o javascript do lado do cliente, se estivermos falando sobre navegadores.

Não sei se o armazenamento em cache e os cookies estão em conflito uns com os outros. Não me lembro de tal problema.

Você deve usar o cabeçalho Authorization em vez de cookie, mas acho que não é uma tragédia se você definir o nome de usuário e a senha em um cabeçalho somente HTTP. Ou você define um cookie persistente com algum hash (se estiver registrado no servidor como um recurso por um longo tempo). Eu acho que ainda é mais seguro do que armazenar esses dados, por exemplo, no localstorage.