Qual seria a melhor maneira de gerenciar sessão em REST? Login/Logout…
Autenticação do HTTP é a maneira mais simples.
Mas você também pode fazer o seu próprio protocolo de autenticação, como S3 da Amazon -> http://www.onjava.com/pub/a/onjava/2007/11/07/introduction-to-amazon-s3-with-java-and-rest.html
Mas se puder ficar com autenticação HTTP pura é sempre melhor 
Acho que ele estava se referindo a gerenciamento de sessao, e nao autenticacao.
Voce ainda pode continuar utilizando as velhas tecnicas de reescrita de URL, Cookies e/ou session trackings.
Ps: Ou eu que entendi errado a pergunta mesmo…
Ele falou login/logout…
De qualquer forma, não se usa sessões http em aplicações REST.
[quote=Rafael Nunes]Acho que ele estava se referindo a gerenciamento de sessao, e nao autenticacao.
Voce ainda pode continuar utilizando as velhas tecnicas de reescrita de URL, Cookies e/ou session trackings.
Ps: Ou eu que entendi errado a pergunta mesmo…[/quote]
Acho que vc entendeu errado, ele ta falando de REST.
Essa parte eu entendi.
Guardar informacoes de sessao em uma aplicacao REST seria ir contra a definicao do Fielding. Mas ainda assim voce conseguiria identificar uma sequencia de comunicacoes REST com as tecnicas de reescrita, cookie, etc.
De qualquer forma, eu que falei besteira mesmo.
Cara,
pulando fora detalhes de autenticação, pensaria assim:
- O que representa essa sessão? Se fosse um carrinho de compras, eu chamaria um serviço assim:
minhaURL/carrinho
que me retornaria um número aleatório apenas para identificar o carrinho na sessão no servidor.
- Pra adicionar produtos no carrinho, eu chamava uma url que começa com “carrinho” seguido do número aleatório retornado anteriormente, seguido dos demais recursos. Exemplo:
minhaURL/carrinho/7543468549211908/produto/3674
essa ação coloca um produto no carrinho alocado no servidor no id associado.
- Haverá uma ação que “limpa” o conteúdo do carrinho. Por exemplo, a compra dos produtos:
minhaURL/usuario/988767/compra/carrinho/7543468549211908
e aí o conteúdo do carrinho deixa de existir.
Enfim, se você quiser uma sessão, é só fazer isso, faça um POST que obtenha o id da sessão e use esse id para fazer as próximas requisições.
[quote=Leonardo3001]
Enfim, se você quiser uma sessão, é só fazer isso, faça um POST que obtenha o id da sessão e use esse id para fazer as próximas requisições.[/quote]
Como seria implementado o servico? Esse POST criaria o carrinho no banco de dados e retornaria um id do registro na tabela? Ou vc ta falando de sessao de verdade no servidor?
[quote=Leonardo3001]Cara,
pulando fora detalhes de autenticação, pensaria assim:
- O que representa essa sessão? Se fosse um carrinho de compras, eu chamaria um serviço assim:
minhaURL/carrinho
que me retornaria um número aleatório apenas para identificar o carrinho na sessão no servidor.
- Pra adicionar produtos no carrinho, eu chamava uma url que começa com “carrinho” seguido do número aleatório retornado anteriormente, seguido dos demais recursos. Exemplo:
minhaURL/carrinho/7543468549211908/produto/3674
essa ação coloca um produto no carrinho alocado no servidor no id associado.
- Haverá uma ação que “limpa” o conteúdo do carrinho. Por exemplo, a compra dos produtos:
minhaURL/usuario/988767/compra/carrinho/7543468549211908
e aí o conteúdo do carrinho deixa de existir.
Enfim, se você quiser uma sessão, é só fazer isso, faça um POST que obtenha o id da sessão e use esse id para fazer as próximas requisições.[/quote]
Isso não seria +/- o que um cookie faz? guarda a id da sessão pra usar nas próximas requisições?
O REST não obriga que o id de determinado recurso seja pareado com uma tabela em banco de dados. O id pode ser uma chave para qualquer coisa, inclusive um map armazenado em memória.
No exemplo, imagino um Map com escopo application que armazena os carrinhos. Daí basta usar o id que o usuário informou como chave e buscar o valor associado.
O Java usa um jsessionid como requestParam para controlar a sessão, não sei se o desenvolvedor tem poder de mudar essa lógica, se tiver será ótimo, pois será possível usar o id do carrinho como o id da sessão do container web. Mas se não puder, o map citado no parágrafo anterior seria a solução.
Poderia usar um cookie, mas não enxergo isso como um serviço puro REST.
Usar um map em memória dentro de um único servidor também não é interessante, especialmente se essa memória não for gerenciada com alguma coisa como memcached, você vai terminar mantendo estado de sessão no servidor web, o que não é uma boa idéia.
[quote=Leonardo3001]O REST não obriga que o id de determinado recurso seja pareado com uma tabela em banco de dados. O id pode ser uma chave para qualquer coisa, inclusive um map armazenado em memória.
No exemplo, imagino um Map com escopo application que armazena os carrinhos. Daí basta usar o id que o usuário informou como chave e buscar o valor associado.
O Java usa um jsessionid como requestParam para controlar a sessão, não sei se o desenvolvedor tem poder de mudar essa lógica, se tiver será ótimo, pois será possível usar o id do carrinho como o id da sessão do container web. Mas se não puder, o map citado no parágrafo anterior seria a solução.
Poderia usar um cookie, mas não enxergo isso como um serviço puro REST.[/quote]
Entao isso ta mais pra caching remoto do que exemplo de sessao, até pq como ja foi dito nao ha sessao de usuario em REST e nem precisa, nao ha pq tb fazer uma aplicacao de e-commerce em REST.
E por que?
A solução do Leonardo disse é completamente possível e restful (eu só removeria a necessidade de se criar um carrinho, acho que um “carrinho eterno” faria o trabalho melhor).
E por que?
A solução do Leonardo disse é completamente possível e restful (eu só removeria a necessidade de se criar um carrinho, acho que um “carrinho eterno” faria o trabalho melhor).[/quote]
Mas veja um sistema desses requer em algumas situacoes um estilo de interacao com o usuario que nao é o ponto do REST.
Só pra ficar claro, é perfeitamente possível criar um sistema de ecommerce seguindo os principios REST mas as vezes (nos casos citado acima) melhor criar aplicacoes especificas em cima dessa camada REST do que tentar forçar uma interacao stateful.
editado: deixar mais claro ainda
Continuo sem entender. Que estilo de interação com o usuário é esse que não é o ponto do REST?
Interação stateful.
Achei o exemplo bom tb pra mostrar como nao deve ser feito!
Servidores em load-balance nao seria possivel com essa solucao. Ja nao é tao restful assim.