WebService do tipo REST

Alguem aqui já fez algum webservice do tipo REST ?

Em java... por onde comecar ?

Olá

REST = Representational State Transfer e o conceito surgiu em 2000 com a tese de doutorado do Roy Fielding.

Se pode entender como REST qualquer Web Service que pode ser acessado com uma requisição simples HTTP GET.

Basicamente você pode criar um cliente com Swing enviando um request via URLConnection e receber de volta um xml resultado que deverá parsear. Diretamente do browser se pode também acessar o serviço mas como a resposta costuma vir em xml, fica meio difícil fazer algo com ela.

Googlando se pode achar muitos tutoriais sobre o que é e como usar REST. Que eu me lembre, no XML.com tem um monte de textos do Joe Gregorio (criador do ATOM) e tem um tutorial do Roger Costello no xfront.com.

Muitas empresas servem web services com REST. A Amazon diz a partir de estatísticas de tráfego, que 90% do uso dos seus web services são baseados em REST

O Google baseou seus WS em SOAP porém o Yahoo oferece uma API para busca baseada em REST. Veja http://developer.yahoo.net/.

E experimente o Yahoo:
http://api.search.yahoo.com/WebSearchService/V1/webSearch?appid=00000000&query=GUJ+chun

Na verdade o conceito inicial da tese do Roy Fielding não usava a query string do GET. Ele se baseava apenas na URL e no uso do HTTP

Assim, para acessar um serviço que retornasse todos os posts do Chun no GUJ se escreveria algo como:
http://www.guj.com.br/posts/Chun

Para ler um post_especifico seria:
http://www.guj.com.br/posts/Chun/post_especifico

Para apagar se usaria o HTTP DELETE e para incluir ou atualizar o HTTP PUT.

Na prática ninguém usa o conceito do Roy exatamente como ele criou porque significaria projetar todo o site já deste jeito. E isto foge do conceito de reaproveitar código fornecendo WS a partir de aplicações prontas que é uma das vantagens de web services.

[]s
Luca

Valeu

Ressuscitando este tópico, como ficaria uma chamada usando REST para mais de um parametro, por exemplo:

http://www.exemplo.org/rest/tickets*****(tickets com status igual a aberto e direcionados para o usuário 'abcs')*****

Virtual Machine Man Membro desde: 04/07/2007 18:28:58 Mensagens: 818 Offline

Assim:

http://www.exemplo.org/rest/usuario/abcs/ticket/aberto

Você vai encadeando os parâmetros, sendo que cada item que separa a barra limita a consulta anterior.

Ou usando query string:

http://www.u-érre-éle.com/rest?query=tickets&status=aberto&usuario=abcs

Virtual Machine Man Membro desde: 04/06/2007 17:47:24 Mensagens: 967 Offline

caraka Luca, que aula!!!!
Parabéns pela clara explicação. Vou aprender REST agora, fiquei super curioso.

Abraços

O REST seria trocar toda a parafernália de RPC, RMI e WebServices por simples chamadas HTTP a um web server?

Eu sempre dei preferencia a simplicidade de uma chamada HTTP ao invés de optar pela parafernália de uma requisição remota. Dizem que xFire resolve esse problema, mas já em 2004 eu sugeria o seguinte:

2004 wrote:
Eu estou meio por fora de webservices. Vc quer enviar objeto e receber objeto como resposta né?

Como não manjo das sugestões que foram dadas aqui, eu faria assim: (Veja se estou falando merda mais uma vez e me avise, ok? )

Pegaria meu objeto
serializaria ele para um array de bytes
codificaria ele em hexadecimal ou base64 (texto!) (ou XML para ficar independente de Java)
ziparia se fosse o caso para ecomizar banda
enviaria para o web server via HTTP mesmo

e o servidor faria a mesma coisa para me responder com um objeto.

Fonte: http://www.guj.com.br/posts/list/15760.java

Bem, vou seguir a ideia do Leonardo3001...
Estou montando um framework para um cliente onde eu pretendo disponibilizar tudo em REST... está ficando legal! Em breve estarei colocando exemplos aqui no GUJ pra galera...
Só pra dar gostinho, eu posso fazer coisas deste tipo:

http://www.exemplo.org/usuario (Lista todos os usuários)
http://www.exemplo.org/usuario.login/rodrigoallemand (detalha o usuário)
http://www.exemplo.org/usuario.login/*allemand (lista todos os usuários onde o login termine com allemand)
http://www.exemplo.org/venda.status/finalizada/venda.produto.precocusto/>10 (lista todas as vendas finalizadas onde o preço de custo do produto é maior que 10)

DETALHE: Sem nada de ficar configurando um monte de URIs pra lá e pra cá...

Rodrigo, por que você adotou essa separação por resource na URI(/usuario/, /venda.status/) e não query String do método GET?

This message was edited 1 time. Last update was at 31/01/2008 17:15:11

saoj wrote:
O REST seria trocar toda a parafernália de RPC, RMI e WebServices por simples chamadas HTTP a um web server?

Eu sempre dei preferencia a simplicidade de uma chamada HTTP ao invés de optar pela parafernália de uma requisição remota. Dizem que xFire resolve esse problema, mas já em 2004 eu sugeria o seguinte:

2004 wrote:
Eu estou meio por fora de webservices. Vc quer enviar objeto e receber objeto como resposta né?

Como não manjo das sugestões que foram dadas aqui, eu faria assim: (Veja se estou falando merda mais uma vez e me avise, ok? )

Pegaria meu objeto
serializaria ele para um array de bytes
codificaria ele em hexadecimal ou base64 (texto!) (ou XML para ficar independente de Java)
ziparia se fosse o caso para ecomizar banda
enviaria para o web server via HTTP mesmo

e o servidor faria a mesma coisa para me responder com um objeto.

Fonte: http://www.guj.com.br/posts/list/15760.java

Legal! É por isso que eu gosto do REST.
Mas tem 2 coisas legais no REST que ninguém falou:
1- A variedade de formato de representação: o cliente sempre manda os mime types que ele é capaz de processar, pode ser text/plain, application/xml ou outros. Quem tá servindo REST pode responder em vários formatos diferentes, dependendo do que o cliente está mandando. Assim, posso responder com uma imagem (image/gif), um xml (application/xml), um json (application/json) ou um objeto Java serializável (application/x-java-serializable), é só o cliente escolher.

2- O uso de links como referências: se o cliente quer buscar um pedido, só que o pedido sempre é feito por um comprador, o objeto possui uma referência para um comprador. Ok. Mas na hora de serializar, eu não preciso colocar toda a representação do comprador, basta uma referência URL como por exemplo http://www.exemplo.org/comprador/425 . Se depois disso, o cliente quiser ver o comprador, basta chamar a URL que recebeu quando viu o pedido.

1- A variedade de formato de representação: o cliente sempre manda os mime types que ele é capaz de processar, pode ser text/plain, application/xml ou outros. Quem tá servindo REST pode responder em vários formatos diferentes, dependendo do que o cliente está mandando. Assim, posso responder com uma imagem (image/gif), um xml (application/xml), um json (application/json) ou um objeto Java serializável (application/x-java-serializable), é só o cliente escolher.

Legal, mas na prática seria melhor se todo mundo optasse por um formato só. Eu gosto muito de objeto serializado em base64 zipado. Mas aí seria só para clientes Java. JSON/XML pode ser melhor para suportar qualquer tipo de cliente.

2- O uso de links como referências: se o cliente quer buscar um pedido, só que o pedido sempre é feito por um comprador, o objeto possui uma referência para um comprador. Ok. Mas na hora de serializar, eu não preciso colocar toda a representação do comprador, basta uma referência URL como por exemplo http://www.exemplo.org/comprador/425 . Se depois disso, o cliente quiser ver o comprador, basta chamar a URL que recebeu quando viu o pedido.

Não entendi. Vc diz se eu tenho um objeto que contem usuário, eu mando o link do usuário ao invés do objeto usuário inteiro? Explica melhor...

Virtual Machine Man Membro desde: 04/07/2007 18:28:58 Mensagens: 818 Offline

É um tipo de coisa que só se consegue explicar em código. Vamos lá!
Imagine que eu tenha a classe Pedido:

e eu tenha a classe Comprador:

Podemos ver que um pedido é feito por um comprador e que um comprador possui vários pedidos.

Imagine que eu faça um GET no endereço http://www.exemplo.org/pedido/5, e que me retornaria um JSON, que seria a deserialização pura do objeto:

Vai ficar muito grande se eu resolver devolver o pedido e todos os objetos que os referenciam, ia correr até risco de uma referência circular.

Por isso, eu só devolveria a referência do comprador:

Repare, a referência é uma URL! Se eu não quiser saber do comprador, tudo bem, eu não carreguei essa informação do servidor. Mas se eu quiser saber, basta pegar essa URL que está dentro de pedido e fazer uma nova requisição GET.

Seria um lazy-loading via http?

saoj wrote:
Seria um lazy-loading via http?

Pensei na mesma coisa.

Notícias, artigos e o maior fórum brasileiro sobre Java