SOAP vs REST?

Este post surgiu como uma resposta em uma discussão bastante interessante no grupo de telegram PyBR e a versão mais rudimentar dele foi escrita em um gist. Um membro pediu indicação de uma biblioteca Python para lidar com Web Services que utilizavam SOAP como protocolo, outros membros questionaram a razão dos serviços não estarem implementados em RESTful, e por fim alguém falou que SOAP era um jeito ultrapassado de implementar Web Services. Como faz algum tempo que eu não lido com SOAP, logo imaginei que algo havia surgido neste meio-tempo para substituí-lo.

Mas não, ele se referia à RESTful Web Services como um substituto do SOAP. A verdade é que sequer faz muito sentido fazer uma comparação entre REST e SOAP, visto que o primeiro é um padrão arquitetural, o segundo um protocolo. Acho que faz mais sentido fazermos uma comparação entre HTTP (seguindo REST ao pé da letra ou não) e SOAP.

Para a maioria dos casos que encontro hoje em dia, implementar uma API pública utilizando HTTP faz muito mais sentido, tanto pela flexibilidade de poder usar XML ou JSON, quanto pela simplicidade da operação. Mas quando eu acho que SOAP vale a pena ou é a escolha “certa”?

Modelagem de negócio

A maioria das APIs têm foco em entidades e operações básicas nessas entidades (ex.: entidade Cliente e operações de inserir (PUT), alterar (POST), buscar (GET), etc…). Você começa a ter problemas em manter sua modelagem (endpoints, coerência interna, etc) de forma consistente quando suas operações não tem uma entidade clara, ou fogem muito do padrão CRUD que os métodos HTTP “impõem”. Tenho certeza que todos podemos imaginar exemplos disso, aplicados à nossa realidade. Eu já tive, por exemplo, que fazer um serviço/endpoint para migração opcional de dados de um sistema antigo para um novo, sob demanda de certos usuários. Como eu represento isso bem apontando para uma entidade e uma única operação/método HTTP?

Protocolo de transporte

Você sempre pode usar HTTP/HTTPS? Quando não, SOAP é independente de protocolo de transporte e resolve essa para você.

Tratamento de erro

SOAP possui tratamento de erro embutido. É possível que algumas libs ou frameworks para RESTful web services hoje em dia também possuam, se não for o caso e você não quiser/tiver tempo de implementar sua própria camada de confiabilidade, SOAP é uma boa escolha. Há também garantia de transporte/entrega, independente do protocolo de transporte.

Operações com estado

O título da seção já é bem descritivo. SOAP preconiza e suporta interações stateful, simular/garantir algo parecido com APIs RESTful utilizando HTTP/S não é simples, e filosoficamente, nem deve ser feito, para ser direto.

Autenticação

Embora não seja difícil implementar autenticação em serviços RESTful, não há o conceito de sessão, portanto, é muito complicado implementar autenticações consistentes que fujam do padrão token/passcode ou que usem aquele OAuth by google/facebook. É muito comum, por exemplo, precisarmos aproveitar o Enterprise Single Sign-On (SSO) que uma empresa já use internamente, para autenticar o uso de web services.

Conclusão

Amo RESTful APIs + HTTP/S e vou protegê-los. Odeio SOAP e ter que lidar com XML. Adoraria que todos esses problemas sumissem, mas é pouco realista. A verdade é que um não surgiu para substituir o outro, mas sim para simplificar a implementação e consumo de Web Services em determinados casos. O prêmio de consolação? Implementar estes serviços com SOAP, hoje, é muito mais simples que nas épocas das primeiras versões do JAX-WS e frameworks similares. Não dói tanto quanto parece.