Conclusão
O objetivo deste artigo foi partir de um exemplo rico o suficiente de arquitetura orientada a serviços e então fazer a modelagem e desenvolvimento dos mesmos com uso de uma abordagem RESTful. Através do exemplo do leilão do Mercado Livre, fomos capazes de percorrer todas as etapas envolvidas na implementação de web services REST. Entre estas etapas podemos destacar a identificação dos recursos, mapeamento de URIs, definição do protocolo de comunicação e formas de mapeamento de Java para XML e XML para Java.
Foi possível ilustrar bem como o bom uso dos recursos do HTTP podem ajudar na definição de um protocolo de comunicação conciso e claro. Elementos já conhecidos como os status e métodos HTTP, URIs e Content-Types passam a ser utilizados para comunicações bem mais diversas do que a transferência simples de HTML.
Com o amadurecimento das implementações REST, estamos caminhando na direção de soluções poderosas e interoperáveis. Até alguns anos atrás, a adoção de web services representava uma troca de performance por interoperabilidade. Piorar a performance na comunicação com a mesma plataforma e linguagem para ser capaz de falar com qualquer outro serviço.
Isto felizmente está deixando de ser verdade. Estamos conquistando poder suficiente para ter ao mesmo tempo alta performance e interoperabilidade.
A JSR-311 e o Jersey trazem benefícios interessantes, e não nos tiram o poder do REST. A introdução destes componentes simplifica o desenvolvimento. Além disso, ganhamos funcionalidades que seriam muito trabalhosas de implementar de forma customizada. A capacidade de manipular múltiplos formatos e a geração do WADL são bons exemplos disso.
Esperamos que este artigo tenha contribuído com novas idéias para os leitores no desenvolvimento de serviços REST. Esta linha de serviços vem amadurecendo progressivamente e já se apresenta como uma opção poderosa para integração entre aplicações.
Pretendo publicar vários outros artigos na área de web services, integração e tecnologias relacionadas, então se você gostou deste artigo, acompanhe sempre as novidades por aqui 
October 21st, 2008 at 8:08 am
Mandou bem, Bruno!
Muito esclarecedor o artigo, principalmente pra quem é quase q totalmente leigo no assunto, como é o meu caso. Quer dizer, agora que já li o artigo, nem tão leigo assim…rs
Abs
October 21st, 2008 at 9:19 am
Oi A2, fico contente que você tenha gostado. Espero que o artigo seja útil para algumas pessoas, e pretendo publicar outros artigos relacionados em breve.
É muito bom quando as pessoas interagem, como você fez, porque aí facilita para que eu vá melhorando progressivamente a qualidade dos artigos.
[]s
February 15th, 2009 at 1:24 am
Falaê Bruno.
Acabei de ler o artigo e só posso dizer que ficou excelente. Estamos pensando em implentar WS no Billing e assim eliminar a necessidade do client. Seu artigo contribuiu muito para consolidar minha decissão a favor de RESTFull.
Tá demorando para escrever mais… não pare você tem talento.
[]`s
February 16th, 2009 at 8:20 am
Oi Crespo, tudo bem? Bem legal ver você por aqui.
Muito bom saber que você gostou do artigo e que isso pode te ser útil no Billing. Acredito que faça sentido usar REST no contexto de vocês sim, e certamente a experiência que tivemos no Cadun lhe trará idéias bacanas.
Eu gosto bastante de escrever e pretendo fazer isso novamente no futuro. Nesse momento meu tempo está dedicado a estudos que me trarão retorno mais rápido, e aí está difícil ter tempo para escrever. Mas eu devo voltar no futuro e torço para poder contribuir com informações e idéias interessantes.
Grande abraço!
February 24th, 2009 at 1:02 am
Muito bom o artigo! Estou iniciando um projeto de um sistema que usará uma arquitetura distribuída. Mas agora estou com a seguinte dúvida. Qual seria uma boa solução para um sistema (aplicação Swing) que tem como requisito funcionar com ou sem internet. Lendo seu artigo inicialmente pensei em alterar o host do serviço entre o host local e o remoto. Mas isso requer instalar toda parte servidora em cada estação de trabalho. Qual uma boa solução nesse caso? Fazer como mencionei anteriormente (mudar o host), ou criar uma camada local e outra camada de serviços para acessar as regras de negócio?
August 4th, 2009 at 11:32 pm
Cara, parabéns! Ficou muito bom o artigo, bem esclarecedor e prático.
Tive contato com RESTfull trabalhando com Ruby On Rails, agora é provavel que tenho que implementar algo em Java.
Falando nisso, o Rails me ‘infectou’ com idéia de Convenção Por Configuração. Dá para imaginar que essas dezenas de Annotations necessárias nos códigos não me bateram muito bem, né?! rs
Estava pensando: por que não adotar uma padrão de nomeclatura para os serviços principais (como os CRUDs, por exemplo) ?
buscarAlgumaCoisa() já seria mapeado automaticamente como GET, injetando algumaCoisaID já convertido como inteiro… Algo assim..
Consegue-se fazer isso com Java? Acho que com Reflection, não?
(O Jersey é aberto?)
Bom, parabéns mais uma vez e abraços.
Rafael Uchôa