Desenvolvedores web têm uma grande quantidade de tecnologias que podem escolher, de ferramentas para acesso simples a bancos de dados, integração com serviços em middleware, a softwares do lado do cliente. A quantidade de opções em si já é um desafio, e escolher uma abordagem específica para construir partes de um aplicativo web exacerba o problema.
Neste breve artigo, vamos nos concentrar em uma dessas escolhas: SOAP ou REST. Ambas possuem vantagens e desvantagens e fica na mão do desenvolvedor determinar a melhor abordagem para cada caso em particular.
A maioria dos desenvolvedores tem exposto seus serviços utilizando REST, que faz uso de um padrão de URI (Uniform Resource Identifier), fazendo uma chamada para um serviço web como em:
http://www.minhaempresa.com.br/programa/metodo?Parâmetros=xx
O REST é simples de entender e pode ser adotado em praticamente qualquer cliente ou servidor com suporte a HTTP/HTTPS. Os desenvolvedores que o utilizam citam, como principais vantagens a facilidade no desenvolvimento, o aproveitamento da infraestrutura web existente e um esforço de aprendizado pequeno.
Por outro lado, o SOAP, avô das interfaces de serviços web, não deixará de ser usado tão cedo. Com o SOAP v 1.2, muitas das deficiências percebidas nessa tecnologia foram corrigidas e aumentou a facilidade de uso. Além disso, a sigla SOAP deixou de representar "Simple Object Access Protocol". Na especificação 1.2 da W3C, SOAP é apenas o nome da especificação.
Utilizar o SOAP 1.2 traz uma carga adicional não encontrada ao usar REST, mas há também vantagens. Primeiramente o SOAP é baseado em XML, de três formas: o envelope, que define o conteúdo da mensagem e informa como processá-la; um conjunto de regras de codificação para os tipos de dados; e o layout para os procedimentos de chamadas e respostas. Esse "envelope" é enviado por meio de (por exemplo) HTTP/HTTPS. E uma RPC (Remote Procedure Call) é executada, e o envelope retorna com as informações do documento XML formatado.
Uma das vantagens do SOAP é o uso de um método de transporte "genérico". Enquanto que o REST faz uso de HTTP/HTTPS, o SOAP pode usar qualquer meio de transporte existente para enviar sua requisição, desde SMTP até mesmo JMS (Java Messaging Service). No entanto, uma desvantagem percebida no uso de XML é a sua natureza prolixa e o tempo necessário para analisar o resultado apresentado.
A boa notícia para os desenvolvedores web é que ambas as tecnologias são muito viáveis no mercado atual. Ambos REST e o SOAP conseguem resolver um grande número de problemas e desafios na web, e em muitos casos tanto um como o outro podem ser utilizados para fazer o que querem os desenvolvedores.
Mas uma história não contada é que ambas as tecnologias podem ser misturadas e combinadas. O REST é fácil de entender e extremamente acessível porém faltam padrões, e a tecnologia é considerada apenas uma abordagem arquitetural. Em comparação, o SOAP é um padrão da indústria, com protocolos bem definidos e um conjunto de regras bem estabelecidas.
Pode-se afirmar, então, que casos onde o REST funciona bem são:
- Situações em que há limitação de recursos e de largura de banda: A estrutura de retorno é em qualquer formato definido pelo desenvolvedor e qualquer navegador pode ser usado. Isso porque a abordagem REST usa o padrão de chamadas GET, PUT, POST e DELETE. O REST também pode usar objetos XMLHttpRequest (a base do velho AJAX) que a maioria dos navegadores modernos suporta.
- Operações totalmente sem-estado: se uma operação precisa ser continuada, o REST não será a melhor opção. No entanto, se forem necessárias operações de CRUD stateless (Criar, Ler, Atualizar e Excluir), o REST seria a melhor alternativa.
- Situações que exigem cache: se a informação pode ser armazenada em cache, devido à natureza da operação stateless do REST, esse seria um cenário adequado para a tecnologia.
Essas três situações abrangem muitas soluções. Então por que ainda precisamos considerar o uso do SOAP? Mais uma vez, o SOAP é bastante maduro e bem definido e vem com uma especificação completa. Já a abordagem REST é apenas isso: uma abordagem. Está totalmente aberta. Por isso ao se encontrar uma das situações abaixo, o SOAP pode ser uma ótima solução:
- Processamento e chamada assíncronos: se o aplicativo precisa de um nível garantido de confiabilidade e segurança para a troca de mensagens, então o SOAP 1.2 oferece padrões adicionais para esse tipo de operação como por exemplo o WSRM (WS-Reliable Messaging).
- Contratos formais: se ambos os lados (fornecedor e consumidor) têm que concordar com o formato de intercâmbio de dados, então o SOAP 1.2 fornece especificações rígidas para esse tipo de interação.
- Operações stateful: para o caso de o aplicativo precisar de informação contextual e gerenciamento de estado com coordenação e segurança, o SOAP 1.2 possui uma especificação adicional em sua estrutura que apoia essa necessidade (segurança, transações, coordenação etc.). Comparativamente, usar o REST exigiria que os desenvolvedores construíssem uma solução personalizada.
Como se vê, cada uma das abordagens tem sua utilidade. Ambas têm problemas nos quesitos de segurança, camadas de transporte etc.; mas ambas podem realizar o trabalho necessário e trazem sua contribuição para o desenvolvimento de aplicações web.
Portanto, a melhor abordagem é a flexibilidade, pois não importa qual seja o problema, no mundo de hoje do desenvolvimento web, conta-se com excelentes resultados ao fazer uso de um desses padrões.
Sobre o autor
Mike Rozlog é o diretor sênior de produtos para a Embarcadero Technologies, dedicando-se a discutir e explicar os aspectos técnicos e de negócios de produtos e serviços da empresa. Mike fez parte da antiga CodeGear e passou mais de oito anos trabalhando para a Borland, inclusive como Chief Technical Architect.