A última vez que encontrei um serviço baseado em SOAP foi durante meu estágio em uma empresa financeira em 2013. Foi nessa época que iniciei minha carreira em TI. Lembro-me de ter algum material de estudo sobre SOAP em um dos meus cursos de engenharia. Fora isso, não usei muito o SOAP durante minha carreira.
Estou perguntando isso desde que a pergunta "Diferença entre SOAP e REST" surgiu em uma de minhas entrevistas recentes. Pelo que sei (e o que encontrei no Google) SOAP é um protocolo com forte acoplamento entre cliente e servidor para intercâmbio de informações que está intimamente relacionado à lógica comercial. Enquanto o REST é uma arquitetura sem estado mais flexível para transferência de dados.
Alguém pode me corrigir se estiver errado sobre essa diferença entre SOAP e REST? Além disso, qual é o significado atual do SOAP? As pessoas ainda estão desenvolvendo novas APIs baseadas em SOAP ou agora são um legado?
fonte
Respostas:
REST é realmente 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 fornecer mecanismos para descobri-los. Por outro lado, 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 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 desuso para novas APIs voltadas ao público, embora ainda seja comumente usado para aplicativos B2B, porque você pode definir um "contrato de dados" com ele. Os serviços da Web JSON têm a virtude de serem bastante leves e flexíveis e, como o Javascript reconhece o JSON nativamente, é uma escolha 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, apesar de chamar incorretamente o protocolo REST).
O Modelo de Maturidade de Richardson
fonte
O REST é muito mais limitado que o SOAP, que é sua força e o motivo 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, usado para expor APIs locais na rede sem perder nenhuma fidelidade. Isso tornou o SOAP popular em ambientes corporativos onde sistemas transacionais complexos precisavam interagir através da rede sem perder nenhuma fidelidade ao longo do caminho. Essa riqueza de habilidades também é a queda do SOAP, porque torna as APIs do SOAP tão difíceis de entender e usar que eram necessárias ferramentas automatizadas na forma de bibliotecas de clientes WSDL e SOAP para entender as coisas. Além disso, expor toda a riqueza do sistema subjacente não é atraente nas APIs voltadas para o público, nas quais você deseja fornecer abstrações que permitem evoluir o sistema subjacente sem precisar interromper ou versão sua API.
REST + JSON ganhou popularidade especificamente por causa de sua simplicidade. Ele define um conjunto limitado de operações com um conjunto limitado de tipos de dados, exigindo que o designer da API projete cuidadosamente abstrações que se encaixam nesse vocabulário limitado e realmente pense no mapeamento do domínio de negócios para os recursos REST. Uma API REST é fácil de entender e fácil de usar, sem nenhuma ferramenta especial. Para uma API voltada ao público, na qual seus usuários da API podem ter todos os níveis de habilidade e conhecimento, é exatamente isso que você deseja, e é por isso que todas as APIs que você vê na Web estão migrando para o REST. O SOAP é relegado a situações corporativas em que ainda existe um desejo e a necessidade de compartilhar APIs complexas entre sistemas. Contudo,
Essencialmente, o que as pessoas perceberam é que o conjunto de restrições que você deve aplicar ao seu design de API para tornar a API simples e abstrata o suficiente para que seja sustentável e fácil de usar é exatamente o conjunto de restrições que o REST introduz, que neutraliza efetivamente os SOAP benefícios deixando você com apenas suas desvantagens. Você poderia criar uma API simplificada com SOAP, mas nunca seria tão fácil de usar quanto o REST; portanto, na prática, todo mundo escolhe o REST.
fonte
Você não pode comparar REST e SOAP. REST é um estilo de arquitetura, enquanto SOAP é um protocolo.
Infelizmente, o REST tornou-se falado coloquialmente como sinônimo de serviço HTTP RESTful, o que significa uma realização da arquitetura denominada REST com HTTP como protocolo (aplicativo).
O REST é baseado nos seguintes princípios (restrições e elementos) (entre parênteses, a realização no HTTP RESTful) [1] .
Por outro lado, muitas pessoas querem dizer SOAP como um serviço da Web baseado em WSDL e SOAP, que fazem parte da arquitetura de serviços da Web W3C [2] .
SOAP é um padrão W3C e é usado como formato de troca de informações nos serviços web W3C. Esses serviços da web foram - especialmente durante o hype das SOAs (arquiteturas orientadas a serviços) por volta de 2008 (+ - 3 anos) - e (infelizmente) ainda são implementados principalmente em aplicativos corporativos.
Isso tem vários motivos. Naquela época, o HTTP RESTful não era bem conhecido e era mal compreendido. Infelizmente, ainda é incompreendido, dê uma olhada nas outras respostas
Além disso, o SOAP (e o WSDL) fazem parte da pilha de protocolos de serviço da Web W3C, que fornece ainda mais padrões para a implementação de um serviço da Web.
Então, sim, ainda existem e também haverá sistemas futuros por aí que usam SOAP (pelo menos em sistemas corporativos, principalmente atrás das portas). Mas a maioria está tentando fazer algum tipo de "REST" hoje em dia.
Dizer que o REST é uma arquitetura sem estado mais flexível para transferência de dados não é uma boa explicação. O REST de fala simples é um estilo de arquitetura com restrições e elementos específicos. Considerando que o 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.
fonte