Arquivologia de software: SOAP e HTTP status code

[joao]

Olá pessoal,

confesso que dei sorte e tive que lidar muito com pouco com SOAP na minha vida, foram alguns sistemas de ERP para ecommerce e agora estou passando por isso novamente com empresas adquirentes (stone, cielo, rede, …). O pessoal que trabalha comigo sempre fica assustado e sempre gera muita conversa quando recebemos um retorno de API que o HTTP status code é 200 mas no XML vem um campo informando que houve um erro na verdade. Já que hoje no universo mais REST isso não acontece com tanta frequência.
Eu já escutei isso para um cenário que é de quem trabalhar com Oracle Service Bus (OSB) que isso é um padrão deles pois para alterar o HTTP status code vc precisaria de td um malabarismo com o software que é melhor seguir esse “pattern” de colocar o status real como campo no XML.
Quem já passou por isso tbm? Quem tem experiência do lado de escrever esses tipos de API?
Gostaria de entender mais as motivações históricas disso, pois não podemos criticar os resultados sem saber os caminhos percorridos.

Abs

[kicolobo]

Nossa… desenterrou aí!

Muitos anos atrás fiz algo nesta direção: meu conhecimento é portanto bem defasado por causa da minha memória. Mas essencialmente, no WSDL você não coloca tipos de retorno HTTP, apenas no corpo da própria requisição mesmo.

Mas mais do que isto: o http é usado como camada de transporte e, em teoria, não é o único transporte que seria usado em SOAP. Você poderia ter, por exemplo, algo usando algum protocolo binário pra trafegar este conteúdo (protobuf por exemplo, ou socket). Então talvez (não tenho certeza), o código HTTP não seja levado em consideração por causa desta possibilidade de mudança de camada de transporte.

PS: nota interessante, dá uma lida neste link: https://www.w3.org/TR/wsdl.html (é a especificação do WSDL, que é como definimos os contratos em SOAP. Note que códigos HTTP não são mencionados)

[joao]

Era um sentimento que eu tinha também que o foco da comunicação ser sempre no corpo da mensagem e o resto era só bônus. Acho que pouca gente busca as especificações para entender como as coisas devem funcionar a acreditam que a forma que sua linguagem e framework favoritos implementam são as verdades absolutas sobre o assunto.

[kicolobo]

este post seu me inspirou a buscar uma resposta: pelo que pude ver a questão é basicamente esta mesmo. Como o protocolo de comunicação pode mudar, você ignora o código de retorno do HTTP, por que em teoria estaria se “prendendo” a uma implementação específica.

Mas na boa? Eu acho SOAP muito interessante: o simples fato de você ter uma especificação que te ajuda a ter coisas como um “wsdl2java” por exemplo, é algo maravilhoso. E acho interessante também dar atenção a ele até mesmo pra entender as fraquezas do modelo dominante hoje, que é o REST.

PS: acredito piamente que nos próximos anos o protocolo HTTP cai por terra e com ele o REST e, na prática, vamos acabar voltando para algo no estilo RPC/SOAP

[joao]

só ver a movimentação do mercado de todo mundo querendo usar algum barramento de eventos/broker como Kafka, SQS/SNS, RabbitMQ da vida.

[kicolobo]

é, mas no caso destes brokers, estamos pensando em um modelo assíncrono de desenvolvimento: pra um modelo síncrono estes não se aplicam.

E aí que entra a questão: o que é usado hoje em quase tudo é HTTP, e com ele você tem uma série de problemas que o pessoal não pensa:

• É um protocolo baseado em texto essencialmente (segurança complicada e cara (vide SSL)).
• Não foi feito pra ser usado como é usado hoje. HTTP (Hyper Text Transfer Protocol).
• Por ser texto, vai ser lento (você precisa parsear, e é maior que o necessário).
• Existem sessões hoje no HTTP2, mas ainda temos essencialmente os problemas que tínhamos antes e não é tão adotado assim.

E quanto mais você pensa a respeito, mais clara fica a necessidade de algo que seja mais barato do ponto de vista econômico. HTTP é bem visto por que você economiza no custo de desenvolvimento (desenvolvedores), mas do ponto de vista de infraestrutura, com certeza vai surgir algo melhor.