Qual é o significado atual do SOAP?

O REST é de fato um estilo arquitetônico. SOAP é um protocolo de dados. A distinção é importante; você não pode compará-los diretamente.

O objetivo principal do REST é representar recursos na Internet, e para fornecer mecanismos para descobri-los. Em contraste, o SOAP é usado para comunicar dados estruturados entre computadores, e isso é tudo o que realmente faz .

Observe que você realmente não precisa do REST para criar um relacionamento cliente / servidor entre dois computadores na Internet. Tudo o que você precisa é de um mecanismo que transfira JSON ou XML, e você nem precisa disso se estiver disposto a ser incompatível com todos os outros.

No entanto, o SOAP caiu em desgraça para novas APIs voltadas para o público, embora ainda seja comumente usado para aplicativos B2B, pois é possível definir um "contrato de dados" com ele. Os serviços da web JSON têm a virtude de serem leves e flexíveis e, como o Javascript reconhece JSON nativamente, é uma opção natural para navegadores.

Mas nada disso tem muito a ver com o REST, na verdade.

Leitura adicional
O REST é melhor que o SOAP? (bom artigo, mesmo que indique incorretamente um protocolo REST). O modelo de maturidade de Richardson

O REST é muito mais limitado que o SOAP, que é sua força e a razão de sua popularidade.

No SOAP, o conjunto de operações permitido e o conjunto de tipos de dados permitidos são essencialmente ilimitados. SOAP é um protocolo de procedimento remoto, que você usa para expor APIs locais em toda a rede sem perder a fidelidade. Isso tornou o SOAP popular em ambientes corporativos, onde sistemas transacionais complexos precisavam interagir pela rede sem perder qualquer fidelidade ao longo do caminho. Essa riqueza em capacidade também é uma queda do SOAP, porque torna a API SOAP tão complicada de entender e usar que necessitou de ferramentas automatizadas na forma de bibliotecas de cliente WSDL e SOAP para entender as coisas. Mais ainda, expor a riqueza total do sistema subjacente não é atraente em APIs voltadas para o público, em que você deseja fornecer abstrações que permitem a evolução do sistema subjacente sem a necessidade de quebrar ou modificar sua API.

REST + JSON ganhou popularidade especificamente devido à sua simplicidade. Ele define um conjunto limitado de operações com um conjunto limitado de tipos de dados, exigindo que o designer de API cuidadosamente projete abstrações que se encaixam dentro desse vocabulário limitado e realmente pense no mapeamento do domínio de negócios para recursos REST. Uma API REST é fácil de entender e fácil de usar sem qualquer ferramenta especial. Para uma API voltada para o público, onde os usuários da API podem ter todos os níveis de conhecimento e habilidade, é exatamente isso o que você quer, e é por isso que todas as APIs que você vê na Web estão fazendo a transição para o REST. O SOAP é relegado a situações corporativas em que ainda existe o desejo e a necessidade de compartilhar APIs complexas entre sistemas. No entanto, com as tendências arquitetônicas em direção a micro-serviços de versão independente desenvolvidos por equipes separadas, até mesmo esse domínio está perdendo terreno.

Essencialmente, o que as pessoas perceberam é que o conjunto de restrições que você deve aplicar ao design da API para tornar a API simples e abstrata o suficiente para ser fácil de usar e manter é exatamente o conjunto de restrições que a REST introduz, efetivamente neutraliza os benefícios do SOAP, deixando-o com apenas suas desvantagens. Você poderia criar uma API simplificada com SOAP, mas nunca seria tão fácil de usar como REST, então, na prática, todo mundo só escolhe REST.

Você não pode comparar REST e SOAP. REST é um estilo arquitetônico, enquanto SOAP é um protocolo.

Infelizmente, o REST tornou-se um sinônimo coloquial para o serviço HTTP RESTful, o que significa uma realização da arquitetura com estilo REST com o protocolo HTTP (aplicativo).

O REST é baseado nos seguintes princípios (restrições e elementos) (entre parênteses a realização em HTTP RESTful) [1] .

• Sem estado (HTTP é um protocolo sem estado)
• Recurso (identificado por URIs)
• Interface Uniforme (Métodos HTTP)
• Representação (MIME-TYPE)
• HATEOS (hiperlinks)
• Cache (Cache HTTP)

Por outro lado, muitas pessoas querem dizer, dizendo SOAP, um serviço da Web baseado em WSDL e SOAP, que fazem parte da arquitetura de serviços da Web do W3C [2] .

• O SOAP é usado como protocolo para trocar informações (basicamente nome do método, parâmetros, valores de retorno, tipos de dados, ...).
• WSDL uma linguagem de definição de interface para descrever o serviço da Web.

What is the present-day significance of SOAP*?

SOAP é um padrão W3C e é usado como formato de troca de informações em serviços da Web do W3C. Esses serviços da Web foram - especialmente durante o hype dos SOAs (arquiteturas voltadas para serviços) por volta de 2008 (+ - 3 anos) - e (infelizmente) ainda são implementados principalmente em aplicativos corporativos.

Isso tem várias razões. Naquela época, o HTTP RESTful não era bem conhecido e era mal entendido. Infelizmente, ainda é mal entendido, dê uma olhada nas outras respostas

„[...]REST is much more limited than SOAP[...].“

„The primary purpose of REST is to represent resources on the Internet[...].“

Além disso, o SOAP (e o WSDL) fazem parte da pilha de protocolos de serviços da Web do W3C, que fornece ainda mais padrões para a implementação de um serviço da Web.

Are people still developing new SOAP-based APIs, or it's mostly a legacy now?

Então, sim, ainda existem e haverá também em futuros sistemas que estão usando o SOAP (pelo menos nos sistemas corporativos, principalmente atrás das portas). Mas a maioria está tentando fazer algum tipo de "REST" hoje em dia.

Can someone please correct me if I am wrong about this difference between SOAP and REST?

Dizer que REST é uma arquitetura sem estado mais flexível para transferência de dados não é uma boa explicação. Simplesmente falado REST é um estilo de arquitetura com restrições e elementos específicos. Considerando SOAP é um protocolo de troca de informações.

Como eu já escrevi, você não pode compará-los. Mas você pode comparar um serviço da Web HTTP RESTful com um serviço da Web SOAP / WSDL.