Contrato de Serviços REST


Ao longo das últimas semanas venho pesquisado e análisado várias abordagens diferentes sobre como implementar serviços seguindo o estilo REST, e fiquei muito intrigado em como descrever ou não a sua interface e os dados associados a eles.

Pois então, logo que me deparei com REST, tive a impressão de que as pessoas preferiam implementar serviços onde suas mensagens eram Json, pura e simplesmente por não entenderem de fato XML e quererem fugir de qualquer coisa que remeta ao wsdl e XML Schema dos Webservices. Infelizmente para muitos o wsdl é apenas um arquivo que você utiliza passar ao framework de webservices  para poder se comunicar com o serviço, mas de fato não sabem o que ele contém e que de fato ele é um contrato, ou seja, que funcionalidades este serviço te oferece, como interagir com elas, quais as restrições e onde está este serviço.

Mas depois lendo mais relatos e conversando com outros profissionais da área, pude perceber que minha primeira percepção não estava errada mas também que estas pessoas citadas acima são apenas parte das pessoas que apoiam REST e Json.  De fato a combinação dos 2 pode trazer muitos benefícios, como por exemplo simplicidade e performance. O que de fato ainda não me deixa ficar tranquilo são as implementações de serviços que recebem e respondem mensagens em Json mas não tem um contrato de dados. Por exemplo, uma solução para isso seria o uso de JSON Schema, que pode ser usado para garantir que as mensagens estejam formatadas de acordo com o que o serviço se propoe a fazer e ainda pode e deve ajudar o cliente na hora de consumi-lo.  Acredito que quando os validadores de Json ficarem mais maduros esta será uma boa prática. Por em quanto o XML Schema ainda ganha quando nos preocupamos com contrato de dados.

Outra questão que vale a pena comentar é a do uso de WSDL para descrever serviços REST. Então.. depois ler uma parte específica sobre WSDL 2.0 Bindings do livro “Web Service Contract Design & Versioning – Thomas Erl”l, fiquei cada vez mais interessado nesta abordagem e pouco tempo depois um caso específico me chamou muita atenção (Ebay). Eles resolveram que para cada serviço que estava no repositório corporativo, deveria ter um WSDL com a usual definição de dados em XML Schema, mas sempre ter 2 bidings definidos, um para SOAP e outro para HTTP. Ou seja, aquela mesma funcionalidade poderia ser consumida usando mensagens SOAP quanto requests HTTP “puros”, utilizando os métodos/verbos HTTP.

De positivo que me salta aos olhos são a flexibilidade na forma de consumir o serviço, e a oportunidade desta decisão ser tomada caso a caso e não em tempo de definição do serviço. Agora se você ler um pouco sobre o que é REST e refletir sobre este assunto, você se depara com uma questão que incomoda a quem defende REST que inclusive eu mencionei no post anterior. Já que o serviços REST tem uma interface padrão, URI + HTTP Verbs, faz apenas sentido definir os dados que serão recebidos e enviados do serviço.

Bom estes foram alguns pensamentos sobre REST, Json, e Contrato de dados.
Opine! Comente! Compartilhe!

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s