Quais são os fatores decisivos na escolha de expor um serviço da Web como um serviço SOAP ou REST?

Tanto quanto eu vejo que consumir SOAP requer uma pilha SOAP, por isso é mais difícil para seus clientes consumir, ou seja, eles precisam garantir que eles tenham uma pilha SOAP no lugar que formate os dados POST e os cabeçalhos corretamente e, em seguida, devolva alguns estrutura de dados, enquanto que com o REST você apenas faz uma solicitação HTTP GET com os argumentos da string de consulta e retorna algum texto que eu acho que provavelmente é XML.

Então, o que a sobrecarga / complexidade extra do SOAP fornece a você, quando você precisa e quando você pode e deve fazer sem ele?

Eu implementei uma API REST antes e gostei muito. Em geral, quando você implementa o REST sobre SOAP, seu cliente / servidor é mais ortogonal, o que significa que você pode alterar muito mais livremente o servidor sem afetar o (s) cliente (s). Essa ortogonalidade se deve ao uso de uma comunicação mais abstrata e já bem definida via verbos HTTP. Além disso, o uso de hiperlinks incorporados em suas respostas REST facilita a extensão e o crescimento da API relativamente sem problemas. Os clientes devem seguir esses links incorporados para obter novos recursos, como um humano seguiria os links em uma página da Web para 'pesquisar' mais informações.

Com isso dito, alguns colegas de trabalho disseram que precisavam usar SOAP e queixavam-se o tempo todo. Então eu fui pesquisar os dois um pouco mais detalhadamente.

Em geral, o que descobri é que o REST é adequado para aplicativos altamente distribuídos , quando você tem centenas, milhares ou milhões de clientes . Uma razão é a ortogonalidade acima mencionada, outra é o armazenamento em cache que você obtém gratuitamente desde que você está usando HTTP.

O SOAP pode ser o caminho mais rápido quando você precisa de uma API menor para um ou dois clientes rapidamente e não está muito preocupado com a escalabilidade. Também pode se adequar melhor a você se você não tiver uma arquitetura estruturada em torno de recursos , pois pode levar algum tempo para reestruturar seu aplicativo e até conseguir implementar o REST.

Pode ser um ponto secundário, mas o REST é inteiramente baseado em HTTP.

O SOAP não requer HTTP e você é livre para usar o transporte que desejar.

As mensagens SOAP podem ser roteadas de forma assíncrona e confiável, enquanto o REST é praticamente um paradigma síncrono.

O REST não informa nada sobre como devem ser os dados que você está enviando e recebendo. Existe WADL, mas principalmente você depende da documentação da API estar correta. O SOAP possui um circo de tecnologias XML para tornar a descrição dos dados menos propensa a erros. WSDL, esquema ...

No final do dia, o REST basicamente fornece um sistema de arquivos baseado em HTTP. Se o seu sistema pode se encaixar nesse paradigma - então pode ser uma boa escolha.

Então, o que a sobrecarga / complexidade extra do SOAP fornece a você, quando você precisa e quando você pode e deve fazer sem ele?

A maior diferença entre os dois é que o REST deve ser sem estado, onde SOAP não é . Na prática, muitas implementações REST realmente implementam algum estado na sessão por meio de algo como OAuth.

Outra diferença é que o REST é muito "orientado a recursos" ou substantivo . Você interage com os recursos por meio de operações CRUD. Tudo o que não se encaixa nesse paradigma se torna complicado e desajeitado.

O SOAP, por outro lado, é apenas um protocolo RPC (chamada de procedimento remoto) . Não vem com um paradigma, é apenas a camada de transporte.

O REST também usa post. De fato, ao usar o REST, os verbos http informam qual operação está acontecendo.

REST e SOAP são apenas padrões diferentes de transmissão de dados pela Internet.

Tendo usado os dois, eu geralmente recomendaria o uso do REST em vez do SOAP, a menos que você conheça as pessoas que consumirão seu serviço da Web usando o .net e o Visual Studio. Geralmente é muito mais fácil consumir um serviço da Web REST, exceto com .net VS, que faz a maior parte do trabalho para você ao usar o SOAP.

Uma coisa que eu mencionaria é a interoperabilidade - se você chamar seu serviço a partir de um aplicativo escrito em .NET e o servidor estiver escrito em Java (ou qualquer outra combinação), vá para REST. Eu já vi muitas pequenas incompatibilidades entre implementações SOAP para me preocupar em considerá-lo mais.

Se você deseja apenas um guia visual simples para ajudá-lo a medir SOAP e REST em relação aos requisitos de seus aplicativos ...

Vijay Prasad Gupta reuniu um fluxograma simples e útil.

Link direto para o fluxograma: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit

Link para o artigo: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs

Agora é 2015. Eu esperava que o SOAP já tivesse morrido, mas ainda permanece como um cheiro ruim. Para qualquer coisa, exceto o mais básico dos aplicativos "de exemplo", a integração com um serviço SOAP está repleta de desafios. É uma arquitetura complexa, com muitas opções em vários níveis, combinada com as peculiaridades de várias implementações e incompatibilidades sutis (e não tão sutis). Eu nunca tive uma boa experiência com isso. REST, por outro lado, é fácil: todo mundo entende HTTP. Na maioria dos casos, o JSON tem muito mais utilidade do que o XML InfoSet.

Para lhe dar uma idéia da complexidade do SOAP, tente integrar uma biblioteca SOAP ao seu projeto. Para Java, o cliente Apache Axis2 mais básico (usando ligação de dados ADB simples) extrai 23 novos JARs. Vinte e três! 20MB de inchaço da biblioteca. O CXF é semelhante: 21 JARs, quando contei pela última vez.

Se você realmente quisesse, pode fazer o REST com uma biblioteca HTTP simples.