Protocolos SOAP e REST – web services

Os protocolos SOAP e REST são utilizados para implementação de web services e responsáveis por realizar a comunicação entre aplicações e serviços remotos independentemente de plataformas ou linguagens, ou seja, permitem a interação direta do aplicativo cliente com estes serviços para realizar uma tarefa, sem que haja necessidade de conhecimento do modelo empregado na implementação das plataformas subjacentes. Merrill (2006) define que “[...] A funcionalidade de um serviço é percebida pela descrição das mensagens que pede e pelas quais responde”.

Configurando-se como protocolo padrão para a construção de web services, o SOAP

Simple Object Access Protocol ou Protocolo de Acesso a Objeto Simples, fundamenta-se na

troca de informações estruturadas numa plataforma descentralizada e distribuída, como a web, utilizando tecnologias baseadas em XML; e, como não se trata mais de um protocolo de acesso a objetos, o acrônimo não é mais utilizado.

Na especificação SOAP há dois componentes essenciais, o primeiro é o uso de XML para codificação de mensagens independente da plataforma, e o segundo, é a estrutura da mensagem, dividida em cabeçalho e corpo.

Numa arquitetura voltada para serviços, a aplicação cliente envia e recebe solicitações ao web service, que são codificadas pelos protocolos SOAP e transportadas geralmente via HTTP69 no formato XML, padrão pelo qual os dados são representados e estruturados. O UDDI (Universal Description, Discovery and Integration) é o protocolo responsável pelo processo de publicação, pesquisa e descoberta de web services, atuando como um índice,

tornando fácil a maneira de registrar e localizar serviços. Por fim, a descrição e representação desses serviços são realizadas a partir da linguagem WSDL (Web Services Description Language), funcionando como uma espécie de type library do web service.

Ilustração 2: Diagrama representativo do protocolo SOAP numa arquitetura voltada para serviços.

De modo geral, é realizada uma série de trocas de mensagens entre aplicação cliente e web service, consistindo em requisições e respostas consecutivamente: primeiramente é efetuada uma consulta ao UDDI para levantamento de web services disponíveis, em seguida, solicitação do documento buscado, então, pedido de um documento WSDL e por fim, o serviço propriamente dito; em que para cada solicitação efetuada pela aplicação cliente há uma resposta subseqüente do web service.

aplicação cliente (requisições) web service (respostas)

1 - consulta ao UDDI UDDI fornece a lista de web services disponíveis

2 - solicitação do documento buscado documento é fornecido

3 - requisição de documento WSDL documento WSDL é fornecido 4 - solicitação de serviço serviço é fornecido

Quadro 1: Intercâmbio de mensagens entre aplicação local e web service no protocolo SOAP. SOAP HTTP Web Service sistema remoto Regras Documento WSDL Aplicação Cliente sistema local

Solicitação do Serviço / Métodos

Resposta / Fornecimento de Informações

Publica o serviço e as regras UDDI Obtém regras UDDI XML

web

Em síntese, pode-se dizer que através do web service, o cliente obtém as regras e métodos dos serviços e pode utilizá-los e combiná-los no desenvolvimento de uma outra aplicação do modo que desejar.

Já o acrônimo REST (Representational State Transfer) ou Transferência de Estado Representacional foi criado em 200070 por Roy Fielding71 em sua tese de doutorado, na qual define uma arquitetura de software própria para sistemas hipermídia distribuídos como a World Wide Web, utilizando-se apenas de HTTP e XML, tornando-a conveniente por ser livre da complexidade apresentada pelos protocolos de trocas de mensagens, como o SOAP.

Fielding define o modelo de REST em sua dissertação como:

[...] O nome “Transferência de Estado Representacional” destina-se a evocar uma imagem de como uma aplicação Web bem concebida se comporta: uma rede de páginas web (um estado-máquina virtual), onde o usuário progride através da aplicação selecionando links (transições de estado), resultando na página seguinte (representando o próximo estado da aplicação) que está sendo transferida para o usuário e apresentada para seu uso.72 (FIELDING, 2000, p. 109, tradução nossa).

Dentre os princípios REST, destacam-se: o estado nulo ou sem estado, em que tanto o cliente como servidor não necessitam gravar nenhum estado das comunicações entre mensagens73; existência de recursos (fontes específicas de informação) com sintaxe universal para identificação global individual dos mesmos (URI); suporte a um conjunto reduzido de operações (POST, GET, PUT, DELETE) que se aplicam a todos os recursos de informação; comunicação entre cliente e servidor via interface padrão (HTTP) com troca de representações destes recursos, permitindo que documentos reais veiculem informação, como o uso de hipermídia, em que a representação deste estado é normalmente HTML ou XML.

70 _{Embora o desenvolvimento da primeira edição de REST tenha se iniciado entre 1994 e 1995 como recurso} para conceitos de comunicação web.

71 _{Cientista da computação americano, caracterizado como um dos principais autores da especificação do} protocolo HTTP, citado como autoridade mundial em arquitetura de redes de computadores.

72 _{Tradução livre de: “[…] The name “Representational State Transfer” is intended to evoke an image of how a} well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.” (FIELDING, 2000, p. 109).

Por ser uma forma mais simples para implementação de web services, Feiler afirma que o protocolo REST vem ganhando espaço na construção dos mashups em detrimento do SOAP:

Outros protocolos estão disponíveis para implementar web services. Em particular, SOAP tem sido usado para aplicações altamente estruturadas. No mundo mashup, REST parece ser o protocolo escolhido, com algum interesse significativo em JSON. Porque REST pode suportar as necessidades do mashup e é mais simples de implementar que SOAP em muitos casos74 _{[...] (FEILER, 2008, p. 114, tradução} nossa).

A base do argumento que REST seria mais adequado para a estrutura da web, fundamenta-se no conceito de interoperabilidade como essencial para o ambiente aberto da internet.