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?
[quote=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?[/quote]
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?
[quote=FernandoFranzini]Voltando ao assunto principal…como ficaria a URL do requisição para uma coleção?
Ou tb fura os principios de rest?[/quote]
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?
- retorna só um 400 ?
- retorna um 400 ou tem como colocar uma texto customizado de erro? “campo tal não foi preenchido”?
To confuso com essas praticas HTTP…
[quote=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?
- retorna só um 400 ?
- retorna um 400 ou tem como colocar uma texto customizado de erro? “campo tal não foi preenchido”?
To confuso com essas praticas HTTP…[/quote]
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? :?: :?:
[quote=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? :?: :?:
[/quote]
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
[quote=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? :?: :?:
[/quote]
Da sim…vc precisa dominar algumas tecnologias e conceitos ai.
asaudate e Fernando,Obrigado pelo esclarecimento.
Pra mim ainda está um pouco confuso,vou me aprofundar mais no assunto!
Vlw!!!
