Conhecendo REST
Ser bombardeado diariamente com novidades tecnológicas foi o que sempre me atraiu no mercado de desenvolvimento de software. Justamente por isso que há algum tempo não acredito mais que exista uma tecnologia que possa resolver todos os problemas, mas que cada uma tem suas vantagens de acordo 
com o tipo do projeto.Há pouco mais de um ano eu escrevia uma monografia para o curso de pós-graduação com o que era de mais avançado em termos de arquitetura distribuída através de webservices. Seu título? “Estudo do MDA e SOA“, tratando de como é possível projetar um sistema em uma arquitetura orientada a serviços com diagramas UML e, com a mágica de uma ferramenta CASE, gerar o código e as interfaces de serviços facilmente. As descrições de serviços eram feitas em WSDL e o protocolo para comunicação, SOAP.
Algum tempo depois, estudando Ruby e Ruby On Rails deslumbrei-me com um novo conceito de arquitetura. Chamava-se ROA, ou arquitetura orientada a recursos.
E qual a diferença entre SOA e ROA?
Em SOA, o desenvolvedor descreve serviços, representados por verbos. Para obter uma lista de eventos cadastrados no sistema teríamos um método publicado com o nome GetEvents, por exemplo. A comunicação com os serviços pode ser feita através de vários protocolos, entre eles SOAP, CORBA, DCOM, etc.
Já ROA pode ser vista como uma especialidade de SOA, onde ao invés de serviços, publicam-se recursos, ou seja, entidades. Para o mesmo exemplo da lista de eventos, bastaria ter um recurso em nosso sistema acessível pelo nome Events que provesse essa funcionalidade. Cada recurso pode prover uma série de funcionalidades, cada uma comparável a um serviço. Cabe ao protocolo de comunicação informar ao recurso qual a função desejada pelo cliente.
Se em arquiteturas SOA eu uso o protocolo SOAP, então em ROA usarei REST?
Essa é uma confusão freqüente. Tratar REST como um protocolo. REST, sigla de Representational State Transfer, na verdade é um padrão para a construção de webservices que farão uso unicamente do protocolo HTTP para a comunicação.
Mas o protocolo SOAP também pode usar HTTP!
Na maioria dos casos, os dados empacotados em SOAP são transferidos usando o protocolo HTTP. Neste caso, HTTP é utilizado apenas para transporte, já que ambos os lados (cliente e servidor) precisam conhecer SOAP para desempacotar e utilizar os dados.
Em sistemas construídos da maneira REST (RESTful), nenhum outro protocolo é necessário além do HTTP, o mesmo usado pelos navegadores para obter páginas na internet. Dessa forma vemos claramente que em REST, serviços são tratados como Websites.
Muito se discute sobre as vantagens da abordagem REST em relação à SOAP, mas como escrevi no inicio do texto, cada tecnologia pode trazer um melhor resultado dependendo do projeto e da maneira como é aplicada. Agora uma coisa é certa, REST traz simplicidade ao desenvolvimento de webservices, tanto na construção do servidor quanto na implementação de clientes.
Em breve farei um texto mais detalhado sobre como definir um serviço REST. Até lá.
Aprenda mais sobre REST em:
Legal seu POST. Eu já estou usando REST há um tempinho, e já estou conhecendo bem a essência do problema. É um paradigma bem diferente de WS-*.
Não é simplesmente uma interface diferente, você precisar modelar o seu sistema com outra abordagem, senão não dá muito certo. Além disso, em serviços REST que não são CRUD, a modelagem pode ser um desafio interessante.
De uma maneira geral, serviços REST são muito poderosos, mas de fato não dá pra achar que servem pra tudo e que são tão simples. Eles têm sua complexidade também.
Agora, com certeza te digo que eu vejo muito mais casos onde REST se aplica do que WS-*. Não sei se você chegou a ler algum artigo meu sobre este assunto na Java Magazine, mas publiquei artigos em Fevereiro e Março, e em Abril vem o artigo de REST, que completa a série.
Depois dá uma olhada aqui:
http://www.devmedia.com.br/resumo/default.asp?ed=56&site=6
Abraços,
Bruno
[...] sismiko foi desenvolvido de forma REST, mas nesta primeira versão os resursos respondem apenas ao formato HTML. As páginas possuem HTML [...]
[...] camada de serviço responde a REST e no formato [...]