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.

Rest Shampoo

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.

Mas uma coisa é certa, REST traz simplicidade ao desenvolvimento de webservices, tanto na construção do servidor quanto na implementação de clientes.

Aprenda mais sobre REST em:

  1. Livro RESTful Web Services;
  2. Descrição da implementação REST no Del.icio.us;
  3. Dissertação que originou o conceito REST;
  4. Artigo mostrando quando usar REST e quando usar SOAP.

Published on in Blog