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!

Qual a diferença entre REST e SOAP?


Bom, vamos lá.. Quem é que nunca leu algum artigo, presenciou ou de fato iniciou uma discussão sobre REST e SOAP? Acho que muitos.. certo?!

Então… Logo após de ler o título deste post você deve estar se perguntando “Esse cara vai ser mais um desses que fica defendendo um lado e detonando o outro com argumentos esquerdistas e radicais?” De ante mão te respondo: “Não!”. Minha intenção com este post é apenas explicar um pouco sobre o assunto e tentar desfazer algumas confusões que as pessoas fazem com REST, SOAP e outros assuntos adjacentes.

Antes de mais nada, vamos a definição básica destes dois:

REST – Representational State Transfer é um estilo arquitetural usado no projeto de aplicações da Web que contam com recursos nomeados (URL,URI,URN) e engenhosamente utiliza mais profundamente o protocolo HTTP, seu cabeçalho , seus métodos (GET, POST, PUT, DELETE, HEAD) e toda a infraestrutura web já bem estabelecida, reconhecida e utilizada por todos.

SOAP – Simple Object Access Protocol é um protocolo para troca de informações estruturadas geralmente em uma plataforma descentralizada e distribuída. Ele se baseia em XML para seu formato de mensagem, ou seja, uma mensagem SOAP encapsula o conteúdo e pode ser trafegada via HTTP, JMS ou outro protocolo.

Se você, por um acaso, antes de ler este post achou que SOAP tinha alguma coisa a ver com sabão e REST com descanso.. você precisa ler mais. 😛

Brincadeiras à parte…, vamos a algumas questões que são importantes nesta discussão.

1 – Definição de interfaces

Primeiramente, pensando em serviços que utilizam mensagems no protocolo SOAP, o mais comum é descrevermos a interface do mesmo com WSDL (Web Services Description Language). Basicamente, cada serviço terá um arquivo .wsdl que terá a definição de suas operações, estrutura de dados que são usadas nas requisições e respostas, Endpoints (endereços de rede do serviço). Uma associação que ajuda o entendimento deste ponto é pensarmos nas operações como métodos de uma classe, a assinatura do método como as mensagens definidas, e o tipo de cada campo da assinatura a definição da estrutura de dados que será usadas nas mensagens.

Agora, nos serviços RESTful, se seguirmos de fato o estilo, parte da descrição da interface é desnecessária já que a forma de interagir com os serviços é sempre a mesma , por meio dos métodos http. E ainda mais com o uso do Método Option podemos saber quais outros métodos são permitidos naquele serviço. Agora com relação aos dados continua a ser interessante a definição de que dados vão trafegar e suas restrições.

Agora, tem pessoas que mesmo assim preferem de uma definição tanto dados quanto de operações, e estas podem fazer o seguinte:

a) Criar um documento para ser lido por humanos que pode conter, por exemplo, a estrutura de dados que seu serviço recebe e responde, lista de quais operações HTTP estão sendo suportadas naquele serviço, qual formato de mensagem é suportado, etc.. Na minha opinião, esta abordagem faz mais sentido quando a estrutura de dados da mensagem é simples e/ou utiliza notações simples como JSON por exemplo, devido a facilidade da implementação do código que irá acessar ao serviço.

b) A segunda forma, é utilizar o WADL(Web Application Description Language), ele é similar ao WSDL só que mais simples, com artibutos de configuração que facilitam a compreensão, por exemplo, de qual notação/formato é utilizada nas mensagens de request e response, e o mais importante, é todo orientado aos recursos e ao protocolo HTTP.

Obs:
WSDL e WADL serve para que aplicações clientes/consumidoras possam gerar o código automaticamente a partir destas definições. No entanto, nada impede que trasnformações .XSL sejam aplicadas a estes arquivos e eles fiquem mais “legíveis” para leigos, afinal os dois são XML com schema e com vocabulário bem definido.

2 – SOAP e SOA

Preciso começar este tópico com uma frase clássica, “uma coisa é uma coisa outra coisa é outra coisa”. Nem adianta falar que a diferença entre SOAP e SOA é a letra “P” essa já está velha.

Primeiro, SOAP é um protocolo para troca de informações estruturada, como vimos no início deste post. SOA, por sua vez, é uma arquitetura que se baseia no paradigma de orientação a serviço que molda o desenvolvimento de funcionalidades de negócio, buscando desacoplamento, reutilização, produtividade e alinhamento entre objetivos de negócio e as estratégias de TI. (SOA Manifesto)

Além do nome ser parecido, o que faz com que as pessoas troquem um pelo outro em conversas, e leigos que estão escutando multiplicarem esta confusão por aí…, existe também uma questão relacionada tanto aos big vendors de ferramentas, quanto aos consultores tradicionais atrelados à SOA, que focam muito em Web services, WSDL, WS-* Extensions e SOAP. Ainda tem o fato adicional de que a maioria deles estão engatinhando em REST. Ou seja…, tem muitos profissionais de TI, inclusive que se dizem entendidos de SOA, que acham que para se ter uma Arquitetura Orientada a serviço precisamos de Webservices, WSDLs e SOAP, o que está 100% errado.

3 – Algumas questões que podem desfazer algumas amarras entre estes conceitos

a) Podemos ter uma empresa com uma maturidade elevada em SOA, apenas com serviços RESTful? SIM!

b) Podemos ter serviços RESTful com a interface descrita com WSDL.? SIM! É! com WSDL.. WSDL foi criado para descrever interfaces e tem uma boa flexibilidade, podemos usar SOAP sobre HTTP, ou simplesmente HTTP com mensagens em formato JSON, ou XML. (obs: Apartir do WSDL 2.0 isto ficou mais fácil.)

c) Podemos ter serviços disponíveis em HTTP e não serem serviços REstful? SIM! Formas de utilizar o cabeçalho HTTP, como modelar as URLS, e usar operações GET, POST, PUT, DELETE entre outras coisas vão determinar se o serviço é RESTful ou não.

4 – SOAP ou REST ?

Podemos elencar alguns pontos interessantes:

Rest
– É mais elegante, pois utiliza ao máximo o protocolo HTTP, evitando a construção de protocolos adicionais
– Tem o potencial de ser bem mais simples que uma implementação com WSDL/SOAP
– Tende a ser mais performático
– ~ 80% das integrações utilizam o protocolo HTTP.
– A possibilidade de ter difersças representações de um mesmo recurso, por exemplo, uma dada entidade pode ser representada em diferentes formatos como Json, xml, html e text/plain, dependendo da requisição feita pelo cliente(Content-Negotiation)
– Possibilidade de navegar entre relacionamentos (Links web) de vários recursos de forma dinamica. seguindo a usabilidade de qualquer sistema web. HATEOAS (Hypermedia as the Engine of Application State).

SOAP
– É um padrão que combinado a as especificações WS-* podem garantir questões de QoS(Quality of Service), Segurança, transação e outras questões presentes em integrações mais complexas.
– Uma mensagem SOAP pode ser propagada por diferentes protocolos, o que flexibiliza bastante várias integrações.
– É um padrão que está muito maduro no mercado, qualquer ferramenta de integração e Framework tem várias funcionalidades para manipular as mensagens que seguem este padrão.

Com certeza existem muitos outros pontos a serem levantados, mas de qualquer forma.. Minha resposta para a pergunta tão popular “Qual o melhor?” seria “Depende”.. depende de qual problema você quer resolver.

Particularmente, acredito que cada demanda tem que ser analisada, com calma, por pessoas que conheçam as 2 abordagens e possam chegar a uma solução adequada ao problema em questão. Isto me faz lembrar de um artigo que o Marcelo Fernandes(companheiro de equipe), me encaminhou há algum tempo que falava sobre uma metodolia ágil muito extremista mas que tinha uma frase interessante.. algo como “Tudo aquilo que você considera verdade, está errado em algum contexto” ou seja, achar uma solução antes de entender o problema é algo que pode funcionar algumas vezes, mas tem um risco, e com certeza em algum, ou vários contextos aquilo não irá se aplicar.. então.. analise cada caso e tire proveito de cada um dos dois.

Abraços,

Carlos Alberto Filho

Pode existir SOA com REST?


Essa semana assisti a gravação de uma apresentação de um arquiteto da plataforma de comércio eletrônico da EBay (Sastry Malladi). A apresentação, realizada na QCon de 2010 (San Francisco, USA), fala sobre algumas formas de implementar serviços REST (RESTful services) numa arquitetura orientada a serviços (SOA) que normalmente contem serviços SOAP e os padrões WS-*.

A apresentação é mais uma demonstração prática de que serviços REST podem ser parte integrante de SOA. Na minha opinião poderíamos ir até mais longe. Isso porque eu arriscaria dizer que serviços REST devem ser sempre considerados pois nem sempre é necessário implementar os padrões WS-*.

Um ponto interessante na apresentação foi a utilização de JAXB para gerar representações em formatos JSON, coisa que por coincidência eu venho implementando juntamente com o Jersey. A flexibilidade oferecida pela dobradinha Jersey e JAXB é muito boa e me lembrou um pouco o Ruby on Rails. Pretendo em breve falar mais sobre o assunto aqui no blog.

Um ponto que a demonstração prática deixou a desejar foi mostrar com mais detalhes o uso dos XMLs de mapeamento. Fiquei com a impressão de que muito código deve ser construído e mantido para suportar as integrações, coisa que uma ferramenta de ESB ou EAI tiraria de letra.

A apresentação, sugerida pelo meu amigo e arquiteto de integração Carlos Alberto Filho, está no site da InfoQ em http://www.infoq.com/presentations/RESTful-SOA-in-the-Real-World