Estado RESTful persistente no cliente sem cookies

5

Estou lendo a dissertação de Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures, que apresenta o estilo arquitetural REST.

Roy explica que os cookies são uma violação do REST à medida que introduzem o comportamento stateful - as respostas armazenadas em cache podem não se aplicar mais (por exemplo, pressionar o botão voltar) e a apatridia do lado do servidor é uma restrição de REST.

Não há razão para que o cliente não mantenha o estado, mas isso é perfeitamente aceitável.

Portanto, se eu tiver uma API RESTful - para uma loja on-line por exemplo - e eu quiser persistir no lado do cliente do estado do usuário por muito tempo - entre várias sessões, existem alternativas ao uso de cookies para persistir o estado local em navegadores modernos?

Se for importante, suponho que estou executando um aplicativo de JavaScript no navegador.

Existe alguma maneira de criar cookies somente do lado do cliente?

Esta questão está relacionada a uma pergunta semelhante sobre cookies para autenticação em REST ...

ATUALIZAÇÃO:

... mas no meu caso eu não estou preocupado com as estratégias de autenticação - apenas em como persistir o estado entre as sessões sem enviar o estado para o servidor.

Para dar um contexto melhor à discussão, quando se fala em autenticação baseada em cookies, Roy diz:

cookie-based applications on the Web will never be reliable. The same functionality should have been accomplished via anonymous authentication and true client-side state.

    
por perfectionist 19.02.2015 / 14:41
fonte

4 respostas

2

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.

    
por 19.02.2015 / 16:52
fonte
0

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.

    
por 19.02.2015 / 15:26
fonte
0

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.

    
por 19.02.2015 / 16:09
fonte
0

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.

    
por 19.02.2015 / 17:43
fonte

Tags