5 Motivos para você usar REST ao invez de WS-*
No dia 25/01/2002 Alguém se lembra o que aconteceu? Foi o dia em que as Atividades com Web Services iniciaram no W3C. De lá pra cá, muitas coisas aconteceram. Quem já não teve que escrever um Web Service? Foi divertido? Se as suas respostas foram SIM e NÃO continue lendo senão sai do post :)
O que ocorre é que existe uma quantidade imensa de especificações WS-* que nem foram implementadas ainda. Existem vários problemas relacionados a questões relativamente simples em um sistema *local*, como por exemplo transação.
Outro problema é a complexidade. É muito complexo e pouco produtivo trabalhar com Web Services. Ahh beleza vai vir um engraçadinho dizendo: "Ahh mas tudo pode usar Xfire ou até mesmo o AXIS", eu digo: "ok". Mas o que acontece na outra ponta? E a sua outra aplicação em C++ ou Smalltalk como fica?
Mesmo com Xfire ainda assim existe muita complexidade por traís das especificações WS-*, sem falar em um outro problema o XML, e o custo de se fazer o parser prá lá e prá cá.
NOTA: Isso ainda é um problema. Por que ferramentas novas por exemplo como o BPEL da ORACLE até a versão 10.1.0.3 tinha seu parser em XML com DOM. Isso ai dom4j.jar!
Soluções com WS são uteis para integração de sistemas, principalmente com tecnologias diferentes como Java e .NET ou C++. Des de 18/10/2006 o pessoal do Open Group iniciou seus trabalhos com SOA. Então nesses últimos anos a filosofia SOA vem ganhando destaque, de fato SOA é algo muito bom.
Uma das formas de se implementar os princípios da filosofia SOA é através de Web Services. Ai novamente o uso de Web Services ganhou mais destaque.
Muito esforço e complexidade com WS
Bom pra começar como vocês já sabem mensagens enviadas e recebidas são em formato XML. Dentro dessas mensagens existem métodos que serão executados, esses métodos podem possuir parâmetros( tanto de entrada, como de saída) e serão empacotados no protocolo SOAP. Adivinhem sobre SOAP? Isso ele é baseado em XML! Tudo isso é descrito com uma especificação WS para descrição que é a WSDL. Quem conhece sabe que a WSDL é asquerosa e nojenta.
Legal, depois disso ainda falta publicar o serviço para isso é utilizado o protocolo UDDI. Esse protocolo não é utilizando apenas para publicação, é utilizado também para pesquisa de serviços. Lembrando que tudo isso roda sobre o protocolo de transporte que nesse caso é o HTTP.
Se você tem dúvidas quanto a complexidade, implemente alguns e depois pense novamente de maneira mais pragmática.
REST é o futuro
Ele foi criado em 2000 através de uma tese de doutorado do Roy Fielding. Que por sinal é um dos criadores do protocolo http. Não bastasse o cara criou o REST. Mas a final o que é REST?
REST é um modelo de design Arquitetural que baseada em transição de estados e hoje em dia é conhecido por utilizar: HTML + XML( ou Json) + utilizam mais os metodos da especificação http. Quando eu digo usar mais os metodos eu digo em usar: DELETE, PUT, etc... Não apénas POST e GET como o dé abitual.
Essas aplicações que utilizam REST são chamads de RESTFull. Em 2007 eu tinha sugerido um framework java para rest. Hoje possuimos outros como o Jersey que é a implementação padrão da JSR311. Também existem outros projetos que estão quase em produção como o Apache ABdera.
Ná prática você pode usufluir dos principios REST em uma aplicação JEE com apénas um Servlet e uma infra em java, conforme apáreceu ante-penultiuma edição da revista Mundo Java.
A tecnologia já vem sendo utilizado com muito sucesso em empresas como: eBay e a Amazon.
NOTA: Diferentemente dos Web Services REST é um estilo arquitetural não um padrão. É bem possivel que ele vire um padrão, em Java já a JSR311, mas em ternos de W3C ainda não. Por equanto só se viu workshops.
Quais são as caracteristicas de um WS-REST ?
A Figura a cima é auto explicativa. Mas basicamente ganhamos com Agilidade, Robustes e conectividade. Outro item que ganhamos e não está ai e a questão da Aderesabilidade que é o fato de endereçarmos recursos e operações a métodos + URLS.
5 Motivos para você usar REST
O que ocorre é que existe uma quantidade imensa de especificações WS-* que nem foram implementadas ainda. Existem vários problemas relacionados a questões relativamente simples em um sistema *local*, como por exemplo transação.
Outro problema é a complexidade. É muito complexo e pouco produtivo trabalhar com Web Services. Ahh beleza vai vir um engraçadinho dizendo: "Ahh mas tudo pode usar Xfire ou até mesmo o AXIS", eu digo: "ok". Mas o que acontece na outra ponta? E a sua outra aplicação em C++ ou Smalltalk como fica?
Mesmo com Xfire ainda assim existe muita complexidade por traís das especificações WS-*, sem falar em um outro problema o XML, e o custo de se fazer o parser prá lá e prá cá.
NOTA: Isso ainda é um problema. Por que ferramentas novas por exemplo como o BPEL da ORACLE até a versão 10.1.0.3 tinha seu parser em XML com DOM. Isso ai dom4j.jar!
Soluções com WS são uteis para integração de sistemas, principalmente com tecnologias diferentes como Java e .NET ou C++. Des de 18/10/2006 o pessoal do Open Group iniciou seus trabalhos com SOA. Então nesses últimos anos a filosofia SOA vem ganhando destaque, de fato SOA é algo muito bom.
Uma das formas de se implementar os princípios da filosofia SOA é através de Web Services. Ai novamente o uso de Web Services ganhou mais destaque.
Muito esforço e complexidade com WS
Bom pra começar como vocês já sabem mensagens enviadas e recebidas são em formato XML. Dentro dessas mensagens existem métodos que serão executados, esses métodos podem possuir parâmetros( tanto de entrada, como de saída) e serão empacotados no protocolo SOAP. Adivinhem sobre SOAP? Isso ele é baseado em XML! Tudo isso é descrito com uma especificação WS para descrição que é a WSDL. Quem conhece sabe que a WSDL é asquerosa e nojenta.
Legal, depois disso ainda falta publicar o serviço para isso é utilizado o protocolo UDDI. Esse protocolo não é utilizando apenas para publicação, é utilizado também para pesquisa de serviços. Lembrando que tudo isso roda sobre o protocolo de transporte que nesse caso é o HTTP.
Se você tem dúvidas quanto a complexidade, implemente alguns e depois pense novamente de maneira mais pragmática.
REST é o futuro
Ele foi criado em 2000 através de uma tese de doutorado do Roy Fielding. Que por sinal é um dos criadores do protocolo http. Não bastasse o cara criou o REST. Mas a final o que é REST?
REST é um modelo de design Arquitetural que baseada em transição de estados e hoje em dia é conhecido por utilizar: HTML + XML( ou Json) + utilizam mais os metodos da especificação http. Quando eu digo usar mais os metodos eu digo em usar: DELETE, PUT, etc... Não apénas POST e GET como o dé abitual.
Essas aplicações que utilizam REST são chamads de RESTFull. Em 2007 eu tinha sugerido um framework java para rest. Hoje possuimos outros como o Jersey que é a implementação padrão da JSR311. Também existem outros projetos que estão quase em produção como o Apache ABdera.
Ná prática você pode usufluir dos principios REST em uma aplicação JEE com apénas um Servlet e uma infra em java, conforme apáreceu ante-penultiuma edição da revista Mundo Java.
A tecnologia já vem sendo utilizado com muito sucesso em empresas como: eBay e a Amazon.
NOTA: Diferentemente dos Web Services REST é um estilo arquitetural não um padrão. É bem possivel que ele vire um padrão, em Java já a JSR311, mas em ternos de W3C ainda não. Por equanto só se viu workshops.
Quais são as caracteristicas de um WS-REST ?
- Modelo Cliente-Servidor
- Ciclo de vida Stateless
- Uso de Cache
- Interface unificada( http, PUT, GET, TRACE, etc...)
- Recursos nomeados com URL
- Camadas de Componentes (Firewalls, Gateways)
A Figura a cima é auto explicativa. Mas basicamente ganhamos com Agilidade, Robustes e conectividade. Outro item que ganhamos e não está ai e a questão da Aderesabilidade que é o fato de endereçarmos recursos e operações a métodos + URLS.
5 Motivos para você usar REST
- Agilidade e Simplicidade
- Uso correto do protocolo HTTP (EX: uso de GET)
- Produtividade e Clareza
- Já existe uma JSR (JSR311)
- Manutenção (muito mais simples de modificar o sistema)
