Status 201 [location=uri] para criação de uma coleção de recursos - REST

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 :?:

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?

FernandoFranzini:

É verdade…bem complicado…
Outra coisa que vejo o pessoal furar é deixar o estado statefull tb…
Que vc acha?

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?

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?

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:

1. SOAP
2. REST
3. 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…

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:

1. SOAP
2. REST
3. 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…

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.

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.

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 :?:

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 :?:

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?

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?

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.

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.

Maravilha. Ia ficar bem legal assim, sem ferir REST.

Que legal…obrigado pelas dicas…ainda não tive tempo de me aprofundar mesmo em REST. Ja estou separando livros e um tempo para ler mesmo.
Só para esclarecer as ideias…

REST deve ser stateless …
isso quer dizer que dentro da implementação rest…não se por escrever nada que amarre o serviço com coisas statefull…exemplos…pegar coisas da sessão, armazenar coisas na sessão, cookies etc…ou seja…a implementação rest tem que apenas obter dados do request e responder um recurso…
Dessa forma, o cliente do REST precisa gerenciar seu próprio estado e enviar os dados dentro do HTTP request para ser processado…

certo?

FernandoFranzini:

Que legal…obrigado pelas dicas…ainda não tive tempo de me aprofundar mesmo em REST. Ja estou separando livros e um tempo para ler mesmo.
Só para esclarecer as ideias…

REST deve ser stateless …
isso quer dizer que dentro da implementação rest…não se por escrever nada que amarre o serviço com coisas statefull…exemplos…pegar coisas da sessão, armazenar coisas na sessão, cookies etc…ou seja…a implementação rest tem que apenas obter dados do request e responder um recurso…
Dessa forma, o cliente do REST precisa gerenciar seu próprio estado e enviar os dados dentro do HTTP request para ser processado…

certo?

Na verdade, o ideal é que a máquina de estados seja gerenciada por hipermídia - ou seja, os próximos passos de um determinado workflow, por exemplo, venham contidos na própria resposta do servidor. Esse mecanismo é abreviado como HATEOAS. Eu dei uma exemplificada em como ele funciona nessa mini aplicação que está na minha assinatura - sinta-se livre para baixar e testar à vontade. Assim, os estados não vão estar nem armazenados na aplicação nem no servidor, mas nas próprias respostas que ele enviar.

É claro, na questão da segurança isso já não é tão simples assim, daí a idéia do cliente armazenar esse tipo de dado…

Agora vc complicou…hahahahaha…

Hahahahahah! Imagino!

Olha, eu bloguei sobre isso (no blog da Concrete Solutions): http://blog.concretesolutions.com.br/2012/03/sobre-rest-e-java/

Vê se ajuda

Voltando ao assunto principal…como ficaria a URL do requisição para uma coleção?
Ou tb fura os principios de rest?

FernandoFranzini:

Voltando ao assunto principal…como ficaria a URL do requisição para uma coleção?
Ou tb fura os principios de rest?

Para fazer GET, tranquilo… até porque é o retorno é encarado como uma coisa só (XML, pelo menos, só tem um elemento raiz). Para fazer POST que a coisa complica, porque desse mesmo ponto de vista, a coisa toda seria encarada como um recurso só, mas a sua aplicação saberia que vários recursos estão sendo criados. Mas não sei te dizer como isso é encarado de um ponto de vista mais purista de REST. Eu dei uma pesquisada sobre isso e alguém colocou um ponto importante: o que você faz se a sua operação em batch levar tanto tempo que dê timeout? Como desfazer a operação? Minha conclusão é que você deveria evitar batch com REST…

[]'s

Brother me ajuda nessa.

Como ficaria um POST para criação de 1 recurso com valores obrigatório no qual não foram enviados corretamente. Como proceder?

1. retorna só um 400 ?
2. retorna um 400 ou tem como colocar uma texto customizado de erro? “campo tal não foi preenchido”?
   To confuso com essas praticas HTTP…

FernandoFranzini:

Brother me ajuda nessa.

Como ficaria um POST para criação de 1 recurso com valores obrigatório no qual não foram enviados corretamente. Como proceder?

1. retorna só um 400 ?
2. retorna um 400 ou tem como colocar uma texto customizado de erro? “campo tal não foi preenchido”?
   To confuso com essas praticas HTTP…

Dá pra retornar um texto sim, no corpo da resposta, no mesmo esquema de uma resposta 200. Aliás, acredito que quase todos esses códigos que são retornados pela aplicação permitem isso, dependendo do verbo utilizado, claro.

[]'s

Dai o cliente pega o retorno 400 e extrai o texto de erro certo?

Isso mesmo. Perceba que, de acordo com o código de erro, o cliente consegue fazer um redirecionamento do fluxo de dados sem precisar conhecer o corpo da requisição

Rapaziada sou iniciante em Java Web e pesquisando sobre algumas tecnologias do facebook e twitter , cheguei a algumas conclusões sobre elas ,gostaria de saber se estou certo nas conclusões que tirei de cada uma delas e também saber como eu posso integrar essas tecnologias em um projeto .Abaixo descrevo minhas conclusões sobre elas, Por favor me corrijam se eu estiver errado:

Rest
= é uma especificação de web service que não segue o padrão w3s.

json
= é arquivo de troca de informçaões/dados em aplicações diferentes.

oauth
= protocolo de segurança que fornece acesso de aplicações terceiras aos dados pessoais dos usuários
em outras aplicações.

maven
= padronizador de caminhos para o desenvolvimento e disponibilizaçõa de aplicações.

:?: :?: :?: :?: :?: :?: :?: :?:

Rest
= é uma arquitetura para sistemas distribuídos.

json
= é um formato de arquivo, usado na para a troca de informações.

maven
= ferramenta de gerenciamento de dependências…

Fernando,Como eu posso integrar essas tecnologias em um projeto!
Tipo eu usaria o Rest para me comunicar com outro sistema de plataforma diferente e o Oauth para importar os dados para o Json? é que eu estou meio confuso sobre a forma que eles podem trabalhar em conjunto no sistema? :?: :?:

JavaThai:

Fernando,Como eu posso integrar essas tecnologias em um projeto!
Tipo eu usaria o Rest para me comunicar com outro sistema de plataforma diferente e o Oauth para importar os dados para o Json? é que eu estou meio confuso sobre a forma que eles podem trabalhar em conjunto no sistema? :?: :?:

JavaThai, pelas suas dúvidas dá pra perceber que você está bem confuso, então vou dar algumas explicações básicas:

REST é um conjunto de práticas de comunicação entre sistemas que é fortemente baseado nas boas práticas HTTP. Essas práticas incluem (dentre muitas outras) o bom uso de headers HTTP. Um desses headers é o Accept, que diz ao servidor que formato de resposta o cliente espera. Desta maneira, você pode enviar para o servidor text/json ou application/json, por exemplo, para dizer a ele que o resultado deve ser formatado como Json.

Já o OAuth envolve um conceito mais abstrato que é de um “mediador” na conversação. Quando você usa o OAuth, você basicamente faz uma conversa entre A e B (sendo B o servidor - por exemplo, o Twitter) e C é um mediador da conversa. Em outras palavras, C diz a A e B que eles podem confiar um no outro, sob a garantia de C. Note que nem sempre esses papéis são fáceis de reconhecer - em várias situações, o Twitter deixa de ser B para ser C, e fica alternando nestes papéis. Note, também, que o formato da conversação é “acordado” entre A e B; C não influencia, neste aspecto, em nada.

Um adendo importante: OAuth nada mais é que um protocolo; como tal, existem implementações dele. Não existe um “servidor OAuth”, existe um “servidor que implementa OAuth”.

[]'s

JavaThai:

Fernando,Como eu posso integrar essas tecnologias em um projeto!
Tipo eu usaria o Rest para me comunicar com outro sistema de plataforma diferente e o Oauth para importar os dados para o Json? é que eu estou meio confuso sobre a forma que eles podem trabalhar em conjunto no sistema? :?: :?:

asaudate e Fernando,Obrigado pelo esclarecimento.
Pra mim ainda está um pouco confuso,vou me aprofundar mais no assunto!

Vlw!!!