Precisamos de um descritor de serviços REST?

maio 14, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Me perguntaram sobre isso na minha apresentação de REST na Globo.com e isso foi assunto de uma discussão interessante hoje no CEJUG. Como é um assunto que pode interessar a bastante gente e eu me interesso muito por web services, resolvi falar mais sobre isso aqui no blog.

Os web services WS-* possuem o WSDL (Web Services Description Language), um artefato amplamente aceito que descreve de forma padrão os serviços da aplicação. Ao especificar no WSDL quais são os schemas XML dos documentos que serão trocados e a cardinalidade precisa de cada elemento, conseguimos garantir que qualquer cliente que entenda o padrão estabelecido será capaz de interpretar os documentos e comunicar-se corretamente com os serviços. Além disto, a maturidade deste padrão traz a vantagem de que já existem geradores de clientes em várias linguagens a partir de um documento WSDL.

Entretanto, WSDL (bem como muita coisa em WS-*) é complexo. Um ser humano que tenha que analisar um WSDL grande perderá um bom tempo para entender o que está descrito no documento. Já REST não tem uma forma padrão de especificar os contratos dos serviços.

Embora a versão 2.0 da especificação WSDL permita descrever web services REST, os principais projetos open source da área como o Apache Abdera, Google Data API, Jersey e o Mule não utilizam esta forma de publicação. Não tenho conhecimento de nenhum projeto publicamente divulgado que faça uso do WSDL 2.0 para descrever serviços REST, e a adoção desta capacidade é baixíssima (se é que existe).

O projeto Jersey oferece opcionalmente o WADL, que é uma forma de descrever serviços REST. Confesso que ainda não olhei o WADL para ver se seria interessante usá-lo. Pelo que sei, entretanto, a adoção dele também é muito baixa.

Existe também o documento de serviços do AtomPub, que é bem interessante. Ele é um documento simples que lista quais são as coleções disponíveis e a localização das mesmas. O documento informa também quais são os MIME types aceitos em cada coleção.

Eu considero interessante que a aplicação ofereça uma interface simples de consulta dos serviços disponíveis. Não é obrigatório, mas quando a aplicação tem uma certa quantidade de clientes é bem legal ter isso para facilitar.

Em dois projetos que eu trabalhei, eu implementei um Servlet simples que listava todas as URIs disponíveis na aplicação, quais métodos HTTP são aceitos em cada uma das URIs e além disso um exemplo de XML manipulado em cada uma das URIs. Isso foi algo que eu achei bom o suficiente, e não tão custoso. Normalmente a documentação de verdade dos serviços fica em algum lugar como uma Wiki, ou uma página qualquer com a descrição detalhada de como interagir com os serviços.

A questão principal é que quando você segue as boas práticas de desenvolvimento REST, os seus serviços ficam muito mais claros para quem precisa se integrar. Por exemplo, eu trabalhei em um projeto crítico de integração com o Google esse ano. Tive que usar várias funcionalidades da Google Data API. A API deles é REST, e encapsula os dados com o formato Atom. Eles não oferecem nenhuma interface semelhante ao WSDL, eles simplesmente têm uma página com a documentação dos serviços.

Como eles seguiram as boas práticas de implementação REST, eu rapidamente aprendi a utilizar a API deles. Os protocolos de comunicação REST são bem semelhantes, e mais simples de entender do que qualquer coisa com WS-*. Pouco mais de 1 hora depois de olhar a documentação deles, eu já estava conseguindo me integrar com eles, com os primeiros exemplos.

O Guilherme fez uma observação interessante durante a discussão disso na minha apresentação no Tech Talk. Quando você segue as boas práticas e implementa um protocolo conciso e claro, de certa forma podemos dizer que a implementação se “auto-documenta”. É algo que podemos traçar um paralelo ao que acontece ao utilizarmos Domain Driven Design. Aproximando a linguagem do código do domínio de negócio, facilitamos a compreensão da aplicação por pessoas que nunca a tinham visto antes. Uma boa arquitetura de web services declarativos (REST) fica muito mais clara do que uma arquitetura de web services imperativos (WS-*). Isto acontece porque com REST o que fica em destaque são os Recursos (que representam conceitos claros do domínio), em vez de Operações.

É claro que as pessoas ainda terão que ler um pouco da documentação, mas como os conceitos em sua maioria já estarão “no sangue”, as dificuldades iniciais são menores do que com WS-*.

O Felipe Gaúcho comentou no CEJUG sobre a capacidade de gerar clientes automatizados com WSDL. Embora isso seja verdade, no meu ponto de vista isso é meio que um mito. Não conheço ninguém que faça integrações automatizadas sem depender de seres humanos. A motivação disso é clara. Integrações envolvem regras de negócio, e ninguém que eu conheço faz negócios automáticos, sem definir as regras 🙂

Existia o mito de que as aplicações “descobririam” serviços automaticamente com UDDI e se virariam para fazer as integrações, gerando os clientes automaticamente. Embora isso seja tecnicamente possível, na prática isso pra mim é uma viagem que serviria mais para desenvolvimento de inteligência artificial do que para web services propriamente 🙂

Embora esta precisão do WSDL seja um ponto positivo, eu tenho a convicção de que a clareza que temos ao usar REST supera e muito as vantagens de termos geradores de clientes automatizados. Quanto a WS-* x REST de uma maneira mais geral, tem uma frase que eu gosto de utilizar. WS-* é apenas overhead a não ser que você tenha informações relevantes nos seus cabeçalhos SOAP. Se você nunca se preocupou MUITO (veja bem, MUITO) com o que está indo nos seu cabeçalhos SOAP, provavelmente um protocolo REST seria mais interessante.

Tem uma opinião a respeito disso? Estou ansioso para conhecê-la! 🙂

Anúncios

Java Magazine 55

março 8, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Java Magazine 55 - Março de 2008

Caros amigos, nos próximos dias chega às bancas a edição 55 da Java Magazine. Nesta edição sai um artigo meu entitulado “Web services WS-*“.

Este artigo é uma continuação do artigo da edição 54, na qual fiz uma análise dos web services REST e web services WS-*. Na edição 54, o foco era mais teórico, discutindo várias questões relevantes da implementação de web services nas 2 linhas de desenvolvimento.

Neste artigo, o objetivo é partir de um problema real de arquitetura orientada a serviços, e então realizar a modelagem e implementação utilizando a pilha WS-*. O exemplo adotado para contextualizar o problema é o processo de leilão do Mercado Livre, mas num contexto de leilão com apenas 1 usuário adquirindo um determinado item. O desenvolvimento foi feito utilizando o Apache Axis 2, uma das opções mais populares para o desenvolvimento deste nicho em Java.

Na edição 56, esta série será complementada com outro artigo prático, que utiliza a abordagem REST para resolver o mesmo problema proposto para esta edição. O objetivo com estes 2 artigos práticos é utilizar um mesmo exemplo que seja de fácil visualização por parte dos leitores e então descrever os detalhes principais do desenvolvimento de web services utilizando a abordagem WS-* e a abordagem REST.

Espero que os leitores gostem destes artigos e torço para que eles possam contribuir com o entendimento do desenvolvimento de web services, e mais especificamente, a implementação em Java. Ao longo do ano escreverei mais artigos nesta área, então se você tiver interesse no assunto, certamente recomendo acompanhar as edições futuras da revista 🙂


Java Magazine 54 – Meu primeiro artigo

fevereiro 14, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Java Magazine - Edição 54 - Fevereiro de 2008

Caros amigos, é com enorme satisfação que anuncio que esta semana chega às bancas a edição 54 da Java Magazine, na qual estou publicando o meu primeiro artigo.

No artigo desta edição, faço uma análise imparcial dos web services REST e web services WS-*, dando uma visão pragmática do nosso momento atual de implementação de web services.

Este é o primeiro do que eu espero que sejam muitos artigos meus publicados na revista, e pelo menos inicialmente a maioria deles será na área de web services. Espero que bastante gente leia o artigo e possivelmente dê opiniões sobre o mesmo. Torço para que vocês gostem das minhas publicações, vamos ver se eu levo jeito para a coisa 😉