Para que foi inventado o SOAP?

Esta questão é inspirada por esta . Qual era o objetivo inicial de inventar o SOAP? Por que foi inventado quando tínhamos HTTP e REST do tipo antigo?

REST não é um padrão, é uma arquitetura (vagamente definida). E está ligado ao HTTP, que muitas pessoas no mundo corporativo consideram uma limitação. Então, eles pensaram que precisavam de um padrão geral adequado, que funcionasse sobre outras camadas de transferência.

E o SOAP foi definido antes do REST (pelo menos de acordo com a Wikipedia :-)

O SOAP é muito mais adequado que o HTTP simples para trocar estruturas de dados complexas. O REST tem design praticamente restrito às operações CRUD, enquanto o SOAP permite chamadas de método arbitrárias, que podem ser algo que não pode ser pressionado no esquema REST.

Da Wikipedia :

O SOAP, originalmente definido como Simple Object Access Protocol, é uma especificação de protocolo para troca de informações estruturadas na implementação de Serviços da Web em redes de computadores. ... SOAP tem três características principais: Extensibilidade (segurança e roteamento WS estão entre as extensões em desenvolvimento), Neutralidade (SOAP pode ser usado em qualquer protocolo de transporte como HTTP, SMTP ou mesmo TCP) e Independência (SOAP permite qualquer modelo de programação).

O SOAP não se limita ao HTTP e fornece segurança imediatamente.

Se você estiver usando HTTP e não precisar de segurança (seu serviço da web é aberto ao público), não precisará de SOAP.

Eu não estava na sala, mas geralmente diria que o SOAP era uma idéia muito, muito boa e uma resposta muito razoável às outras opções de RPC que existiam entre meados e o final dos anos 90. Como o CORBA , um animal com o qual não posso dizer que tive que lidar pessoalmente, mas a simples menção disso pode fazer os homens crescidos se sujarem. As opções além do CORBA eram realmente mais assustadoras em muitos casos e havia pouca padronização e muitos protocolos de mensagens personalizados em andamento. Sistemas integrados eram coisas muito, muito difíceis. Havia boas razões para não confiar no HTTP como transporte. No final dos anos 90, as velocidades típicas da LAN eram de 10 megabits ou menos, as velocidades da WAN eram muitas vezes medidas em baud. Toda a infraestrutura de cache de borda que faz tanto pelo REST não existia.

O que nos leva ao SOAP - que por si só não especifica um meio de transporte. Acredito que alguém conseguiu implementar uma chamada SOAP pelo pombo-correio. Ou talvez uma andorinha africana. De qualquer forma, é muito mais simples implementar a opção de mensagens do que a que veio antes. E se você tivesse um kit de ferramentas SOAP decente, era muito, muito mais fácil de consumir do que qualquer outra coisa que havia chegado antes. E mais fácil de fazer ferramentas. Tão fácil que eles pensaram que precisavam estender o protocolo. E é aí que entra o WS- *. É aí que as rodas caem daquele caminhão. . .

SOAP é um protocolo de mensagens criado pela mesma razão pela qual qualquer outro protocolo de mensagens foi criado; padronizar a maneira pela qual as informações do objeto são passadas. Como a página da Wikipedia afirma, ela se originou na Microsoft e agora é um padrão aberto mantido pelo W3C.

A melhor pergunta é por que escolher entre SOAP ou algum esquema XML ou JSON ou o que quer que seja, e a resposta se resume a usar o que for mais fácil / prático em sua situação específica.

Na minha opinião, o SOAP é outra visão da RPC . Veja como você expõe o WebService atualmente. Uma parte marca o método como WebService e a outra apenas busca o WSDL e usa métodos remotos como se fossem locais. Estou bastante ciente de todos os problemas do SOAP, mas em algum nível de abstração o SOAP / WS cumpre sua promessa de RPC. É claro que você pode criar uma API baseada na arquitetura REST, mas ainda será necessário que outra parte codifique alguns bits que de alguma forma desafiam a definição de RPC.