A especificação do HTTP indica o retorno do header LOCATION para a URL de criação de um recurso criado…
Mas se meu POST criar uma coleção de recursos?
Como proceder :?:
[quote=FernandoFranzini]A especificação do HTTP indica o retorno do header LOCATION para a URL de criação de um recurso criado…
Mas se meu POST criar uma coleção de recursos?
Como proceder :?: [/quote]
Como assim, seu post cria uma coleção de recursos? Você passa várias entidades como parâmetro?
Simmm!!!
Mas então… a idéia de um “recurso” é que ele seja auto-contido… ou seja, você não passa vários para criação, mas sim um de cada vez. Se você quer ter um serviço que processa em batch, acredito que o certo seria você devolver o local onde o usuário pode consultar todos os recursos, e não apenas aqueles q vc passou em lote. Sei lá, minha opinião. Não acho que exista uma resposta pro seu caso em específico…
[]'s
É verdade…bem complicado…
Outra coisa que vejo o pessoal furar é deixar o estado statefull tb…
Que vc acha?
[quote=FernandoFranzini]É verdade…bem complicado…
Outra coisa que vejo o pessoal furar é deixar o estado statefull tb…
Que vc acha?
[/quote]
Acho que, assim como aconteceu com praticamente todas as inovações na área de programação, muita gente simplesmente não entende o que é a idéia e sai fazendo. Com REST não foi diferente, e sempre tem gente “exercitando a criatividade” por aí. Isso acontece principalmente quando a idéia não é simples - no caso do REST, usar hipermídia como motor da máquina de estados não é algo trivial, e até as próprias implementações de JAX-RS 1 praticamente ignoraram o problema, levando os desenvolvedores a ignorarem também.
Eu mesmo estou sendo forçado a usar com statefull…é impraticável fazer autenticação e autorização a toda invocação HTTP com REST. Muito complicado isso…tem alguma dica ai?
Bom, você poderia fazer algo baseado em tokens, mais ou menos que nem o twitter (OAuth) faz. Não iria ser menos stateful, mas iria diminuir o acoplamento entre o cliente/servidor e te daria mais chances de criar alguma coisa nos moldes de um Single Sign-On. Como é feito hoje?
[]'s
Então…estou projetando algo para um piloto ainda…nada oficial…estou estudando e fazendo uma validação arquitetural…
Eu poderia usar rest mas teria que ferir o conceito de stateless…
Quais são as opções?
Pensou eu q seria usar SOAP mesmo ou usar MVC action like retornando JSON.
Que vc acha?
[quote=FernandoFranzini]Então…estou projetando algo para um piloto ainda…nada oficial…estou estudando e fazendo uma validação arquitetural…
Eu poderia usar rest mas teria que ferir o conceito de stateless…
Quais são as opções?
Pensou eu q seria usar SOAP mesmo ou usar MVC action like retornando JSON.
Que vc acha?[/quote]
Bom, acredito que REST e SOAP são muito diferentes para ter uma relação assim, um pra um. SOAP é RPC… seria mto melhor praquele caso q vc citou do processamento em lote. A não ser q vc esteja mto seguro de que pode projetar a aplicação inteira pra ser orientada a recursos, acho que seria melhor usar SOAP.
SOAP que, aliás, também tem suas desvantagens. Você iria ter que fazer algum contorno pra ele passar autenticação… contorno que, aliás, serviria igualmente caso os serviços sejam REST.
Quanto ao MVC action-like… já me parece que estupra os conceitos de REST duma vez =P
kkkkkk
Concordo com tudo que vc falou…
Mas deixa eu explicar…por que estamos sem contexto…
Preciso de canal de comunicação de objetos JSON. Nesse canal tem autenticação, autorização e SSL. Sendo assim, tenho 3 opções:
- SOAP
- REST
- MVC Action Like.
- REST não se encaixa, por ser totalmente stateless.
- SOAP fica muito bom.
- MVC Action Like eu consigo retornar JSON da mesma forma do REST, mas não tenho q seguir os principios do REST.
Por isso, para este caso a melhor opção esta sendo MVC A.L…Apensar que, se eu colocar o REST como statefull, tb funcionaria…
[quote=FernandoFranzini]kkkkkk
Concordo com tudo que vc falou…
Mas deixa eu explicar…por que estamos sem contexto…
Preciso de canal de comunicação de objetos JSON. Nesse canal tem autenticação, autorização e SSL. Sendo assim, tenho 3 opções:
- SOAP
- REST
- MVC Action Like.
- REST não se encaixa, por ser totalmente stateless.
- SOAP fica muito bom.
- MVC Action Like eu consigo retornar JSON da mesma forma do REST, mas não tenho q seguir os principios do REST.
Por isso, para este caso a melhor opção esta sendo MVC A.L…Apensar que, se eu colocar o REST como statefull, tb funcionaria…
[/quote]
Mas como vc faria com a questão da autenticação/autorização?
Até agora, na minha cabeça, eu usaria um “intercepting filter”
Antes da requisição chegar na camada especifica de integração (REST, SOAP, MVC) eu faria a aut. e autor.
Outra questão é que na mesma solução, eu tenho uma camada web sendo usando e assim eu reutilizaria a mesma aut. e autor. para ambas as camadas.
No caso de REST vc falou para usar token ou oAuth. Token eu conheço mas oAuth não sei como funciona.
[quote=FernandoFranzini]Até agora, na minha cabeça, eu usaria um “intercepting filter”
Antes da requisição chegar na camada especifica de integração (REST, SOAP, MVC) eu faria a aut. e autor.
Outra questão é que na mesma solução, eu tenho uma camada web sendo usando e assim eu reutilizaria a mesma aut. e autor. para ambas as camadas.
No caso de REST vc falou para usar token ou oAuth. Token eu conheço mas oAuth não sei como funciona.[/quote]
Sendo bastante simplista no caso do OAuth, seria como se você colocasse um terceiro na conversação, e esse terceiro seria o responsável por dizer para o servidor se aquela aplicação pode se logar ou não. Se puder, ela recebe um token seguro para ser usado. Na prática, isso não faria sua aplicação ser menos stateful, mas acredito que o certo seria seu cliente (ou seja, a camada web) gerenciar esse estado, e não seus serviços. Nesse caso, seria independente você usar tokens ou usuário/senha toda vez. Em outras palavras: sua aplicação web seria stateful (com armazenamento de dados em sessão), mas seus serviços, não.
Se você quiser dar uma olhada nessa questão da autenticação/autorização com OAuth, o Spring Security tem um plugin bastante interessante pra isso… aí, de quebra, você já integraria a autenticação/autorização de ambos (cliente e servidor) com OAuth.
[]'s
Então alexandre…deixa ver se eu entendi…
Se eu separar o “controle do gerenciamento do estado” da camada REST e deixar a camada de integração REST sem dependência nenhuma…ou seja, ela sera invocada sem saber que existe uma auten. e autor. statefull eu poderia usar REST sem furar o principio de stateless :?:
[quote=FernandoFranzini]Então alexandre…deixa ver se eu entendi…
Se eu separar o “controle do gerenciamento do estado” da camada REST e deixar a camada de integração REST sem dependência nenhuma…ou seja, ela sera invocada sem saber que existe uma auten. e autor. statefull eu poderia usar REST sem furar o principio de stateless :?: [/quote]
Mais ou menos, você continuaria passando alguma espécie de mecanismo de autenticação e autorização por request, mas quem manteria esses dados, de maneira stateful, seria o cliente (ou seja, a camada web). O lance de ser stateless é válido para o servidor, mas o cliente pode manter o estado da maneira que lhe convier. Afinal de contas, os browsers mantém os estados de navegação que nós fazemos à vontade 
[]'s
Não senti firmeza nessa “mais ou menos” ai kkkkk
O serviço rest não vai acessar e nem colocar nada na “sessão statefull” autenticada…simplesmente vai prover os serviços invocados.
O filtro que seria uma suposto “AOP” cuida disso…
Fica ou não dentro do REST?
[quote=FernandoFranzini]Não senti firmeza nessa “mais ou menos” ai kkkkk
O serviço rest não vai acessar e nem colocar nada na “sessão statefull” autenticada…simplesmente vai prover os serviços invocados.
O filtro que seria uma suposto “AOP” cuida disso…
Fica ou não dentro do REST?[/quote]
Então, a idéia seria a de que os serviços REST continuassem pedindo os dados de autenticação. Mas isso ficaria transparente para o usuário da aplicação, cujos dados, ficariam na sessão da camada web (que é o cliente dos serviços).
Eu não sei se estou entendendo muito bem o problema, poderia fazer um desenho? =)
Desenho fica complicado mas vai outra explicação…
- Eu uso auten. e autori. via JAAS…
- a camada web se autentica no jaas para usar o sistema.
- o serviço rest ficaria na mesma coisa, mas dentro do rest ficaria transparente isso.
- eu colocaria um AOP antes de entrar no rest para autenticar e autorizar a requisição e controlar o ID da sessão autenticada. Usaria o padrão de cookies com o ID da sessão…
Mas como eu falei…isso ficaria transparente para serviços rest.
[quote=FernandoFranzini]Desenho fica complicado mas vai outra explicação…
- Eu uso auten. e autori. via JAAS…
- a camada web se autentica no jaas para usar o sistema.
- o serviço rest ficaria na mesma coisa, mas dentro do rest ficaria transparente isso.
- eu colocaria um AOP antes de entrar no rest para autenticar e autorizar a requisição e controlar o ID da sessão autenticada. Usaria o padrão de cookies com o ID da sessão…
Mas como eu falei…isso ficaria transparente para serviços rest.[/quote]
Maravilha. Ia ficar bem legal assim, sem ferir REST.