Profissionais TI - Pra quem respira informação

Olá galera!

Hoje vamos falar um pouco sobre Serviços Web? Vamos evitar aquela “sopa de letrinhas” habitual para falar de HTTP, XML e o elemento mais importante dentro de serviços web: a informação.

O pecado de muitos desenvolvedores web é esquecer que Web e Internet não são sinônimos: Web é a camada HTTP em ação, Internet é um conjunto de serviços que enriquece (e mantém ativa) a rede mundial de computadores. Não há web sem conectividade, mas há conectividade sem web (pense nisso). O principal objetivo da internet é prover conectividade, e da web é prover informação…

HTML é vital!

Com o HTTP (HyperText Transfer Protocol) podemos transferir hipertextos/hipermídias que serão interpretadas (ou não) pelos nossos navegadores. Você só consegue “visualizar” a estrutura de um XML em seu navegador porque ele foi programado para isso… se você não tem o player do Flash em sua máquina e acessa diretamente um recurso .swf, provavelmente isto iniciará uma transferência de arquivos. A mesma coisa acontece com imagens, o Firefox é capaz de renderizar um SVG pois suporta este tipo MIME, já o IE6 não. Nossas páginas web são documentos (hipertextos) que agrupam uma série de recursos (hipermídias), os navegadores baixam essas mídias em seus temporários, abrem o documento, interpretam o documento e daí associam as hipermídias a ele.

XML é vital!

Você está lendo esta informação através de um software cliente, o seu navegador. Você acessou um hipertexto… navegadores entendem hipertextos. Mas e seu leitor RSS? Ele é um cliente RSS certo?! Não é um navegador web, ele tem que conectar-se em um servidor RSS (feeds). Este servidor tem que disponibilizar uma informação genérica dentro de um padrão para que o cliente entenda. Para isso monta-se um documento XML (eXtensible Markup Language) que siga o padrão de construção de RSS’s e então transporta-se este documento por HTTP.

Você acabou de ter um exemplo fundamental do funcionamento do REST e de um Webservice. O que é importante saber é que através de XML podemos fazer dois softwares se comunicarem (no exemplo, um cliente RSS desktop e uma aplicação CMS que disponibilize feeds RSS) adotando um padrão de criação e interpretação.

INFORMAÇÃO é vital!

O que pode-se entender disso tudo? – Os recursos (CSS, JS, SWF) são detalhes, o que interessa é a informação (HTML, XML), como você vai acessá-la (HTTP) e usufruir dela (navegador, RSS). Podemos ter informação sem formatação (CSS): sim; podemos ter informação sem comportamento (JS): sim; podemos ter informação de uma forma genérica (XML): sim; podemos ter a informação de uma forma semântica em nossos navegadores (xHTML): sim; podemos ter informação de uma forma semântica em nossos leitores RSS: sim. Mas isso MUITO depende da mentalidade do programador.

Bem-vindo ao REST

Gosto de fazer a analogia do REST (Representational State Transfer) com os padrões web. Webstandards foram uma “ducha de água fria” no pessoal que estava implementando recursos proprietários onde não havia necessidade. Estavam complicando nossas vidas e o W3C veio para descomplicar formulando especificações que regem as três camadas fundamentais do desenvolvimento web (informação, formatação e comportamento), mas que não impedem a criação de aplicações ricas e/ou complexas.

O REST[5] é uma técnica para sistemas hipermídia originado numa tese de doutorado de Roy Fielding. Não estamos falando de uma biblioteca, plataforma, aplicação, tecnologia, etc. Estamos falando de uma técnica…assim como o MVC ou o Tableless, você usa se quiser.

Ok! E o que o REST tem de diferente do SOAP (Simple Object Access Protocol)[3]? Respondo: O REST defende o fato de que o protocolo HTTP é rico o bastante para proporcionar Webservices, e não há necessidade de criar-se nenhuma abstração para este fim. Para termos um Webservice efetivo precisamos apenas de: um cliente, um serviço, informação, um meio de “encapsular” esta informação (XML, JSON, YAML, etc) e do meio para acessar esta informação (HTTP).

SOA x ROA

Você com certeza já deve ter ouvido falar do SOAP em algum momento. Através dele, cria-se uma abstração da comunicação onde ferramentas “envelopam” a informação para que o seu receptor a entenda e a processe. Um exemplo muito comum do SOAP é integrar um e-Commerce ao sistema de cálculo de frete dos Correios: enviamos por SOAP para o servidor um CEP remetente, um CEP destino, o peso do pacote, e as dimensões do pacote. Ele nos responde por SOAP o valor do frete; O processamento fica por conta dos servidores dos Correios, o SOAP só é um meio (muito eficiente por sinal) de enviar os dados que queremos e receber as informações que precisamos.

Este conceito é conhecido por SOA (Service-oriented Architecture)[2]. Onde desenhamos uma aplicação para que ela opere através de serviços em uma rede de computadores (Intranet, Extranet, Internet), indepedentemente de linguagem, e seguindo padrões abertos.

Ok! Então o que o SOAP tem de diferente do REST? Respondo: SOAP é um padrão aberto que define uma framework de comunicação independente de linguagem e protocolo mas que é baseada em XML. Isso quer dizer que, seja web ou não, em Java ou PHP, a sua informação sempre será transferida de uma forma padronizada, empacotada em SOAP. Obviamente isto requer que tanto seu cliente, quanto seu servidor (serviço) entendam o que é SOAP.

Flávio Granero, em seu post sobre REST[1], fala de um conceito que até então eu não tinha ouvido falar: o ROA (Resource-oriented Architecture)[4]. Segundo ele, em SOA o desenvolvedor descreve serviços representados por verbos que podem ser acessíveis por qualquer padrão (SOAP, DCOM, etc). Já em ROA, o desenvolvedor publica uma entidade que pode ser acessível e manipulada por qualquer que seja o cliente.

Seguindo o exemplo dos Correios, ao invés de enviar um SOAP, acessaríamos o recurso através de seu URI (Uniform Resource Identifier)[8]:

http://www.correios.com.br/webservices/calculo-de-frete/valor_frete.php?cep_inicial=00000-000&cep_final=00000-000&largura=0000&altura=0000&profundidade=0000&peso=0000

O exemplo é meramente ilustrativo, mas percebe-se que o meio de transferir informações por REST é “puramente web”. O retorno desta URL poderia ser um XML, JSON, YAML, etc.

Mas o fundamental é que ele nos retorne o valor do frete de acordo com os parâmetros passados (por GET). Para usuários de frameworks modernas (como Django, Ruby on Rails, Pylons, etc) deve-se criar um caminho mais “semântico” para o recurso, sem necessitar apelar tanto para o GET. Segue exemplo de um recurso RSS sem url’s amigáveis:

http://www.meu-super-portal-de-noticias.com/rss.asp?secao=noticias&categoria=esportes

Agora com url’s amigáveis:

http://www.meu-super-portal-de-noticias.com/rss/noticias/esportes

Muito melhor não?! Esta informação poderá ser acessada por qualquer cliente que trabalhe sobre o protocolo HTTP… agora se ele vai entender ou não, aí é outra história. Então o que é necessário fazermos? Um cliente web que leia esta informação e a processe dentro de um contexto.

No portal do desenvolvedor do Yahoo temos alguns exemplos bem práticos sobre o funcionamento do REST com Python[9], já no ONLamp.com você pode conferir um artigo[10] que aborda o REST mais a fundo (inclusive sobre o uso de GET, POST, PUT e DELETE).

REST é para Webservices mesmo!

Não quero evangelizar e muito menos contrariar nenhum utilizador do SOAP. Mas concordo com os argumentos da utilização do REST e faço questão de contribuir para uma web mais simples e semântica.

Caso você precise de um modelo independente de linguagem, plataforma e protocolo, não pense duas vezes e estude SOAP. Agora, se o seu serviço resume-se especificamente a um serviço web, onde a informação tende a ser transportada somente através do protocolo HTTP… com certeza utilizando o REST você terá um serviço implementado de uma forma muito mais simples.

Considerações Finais

Como esse post ficou muito grande, decidí não “esmiuçar” mais ainda o assunto. Em posts futuros podemos analisar o REST de uma forma mais prática, e quem sabe até constuir um comparativo do uso de REST e SOAP em determinados cenários.

Referências

1. Flávio Granero – REST: http://flaviogranero.com/category/rest/
2. Wikipedia – SOA: http://pt.wikipedia.org/wiki/SOA
3. Wikipedia – SOAP: http://pt.wikipedia.org/wiki/SOAP
4. Wikipedia – ROA: http://en.wikipedia.org/wiki/Resource_oriented_architecture
5. Wikipedia – REST: http://pt.wikipedia.org/wiki/REST
6. Inospito – O debate SOAP vs. REST: http://inospito.com/2007/10/10/o-debate-soap-vs-rest/
7. Sun Developer Network – RESTful Webservices: http://java.sun.com/developer/technicalArticles/WebServices/restful/
8. Wikipedia – URI: http://pt.wikipedia.org/wiki/URI
9. YDN – Make Yahoo! Web Service REST calls with Python: http://developer.yahoo.com/python/python-rest.html
10. OnLamp. Python DevCenter – Using REST with AJAX: http://www.onlamp.com/pub/a/python/2006/02/23/using-rest-with-ajax.html

Até a próxima…