SOAP vs REST (diferenças)

Eu li artigos sobre as diferenças entre SOAP e REST como um protocolo de comunicação de serviço da web, mas acho que as maiores vantagens do REST sobre SOAP são:

1. O REST é mais dinâmico, sem necessidade de criar e atualizar UDDI (Descrição Universal, Descoberta e Integração).

2. O REST não está restrito apenas ao formato XML. Os serviços da Web RESTful podem enviar texto sem formatação / JSON / XML.

Mas o SOAP é mais padronizado (por exemplo: segurança).

Então, eu estou correto nesses pontos?

Infelizmente, existem muitas informações erradas e conceitos errados sobre o REST. Não apenas a sua pergunta e a resposta do @cmd as refletem, mas a maioria das perguntas e respostas relacionadas ao assunto no Stack Overflow.

SOAP e REST não podem ser comparados diretamente, pois o primeiro é um protocolo (ou pelo menos tenta ser) e o segundo é um estilo de arquitetura. Essa é provavelmente uma das fontes de confusão, pois as pessoas tendem a chamar REST de qualquer API HTTP que não seja SOAP.

Empurrando um pouco as coisas e tentando estabelecer uma comparação, a principal diferença entre SOAP e REST é o grau de acoplamento entre implementações de cliente e servidor. Um cliente SOAP funciona como um aplicativo de desktop personalizado, fortemente acoplado ao servidor. Há um contrato rígido entre cliente e servidor, e espera-se que tudo quebre se um dos lados mudar alguma coisa. Você precisa de atualizações constantes após qualquer alteração, mas é mais fácil verificar se o contrato está sendo seguido.

Um cliente REST é mais como um navegador. É um cliente genérico que sabe como usar um protocolo e métodos padronizados, e um aplicativo precisa se encaixar nele. Você não viola os padrões de protocolo criando métodos extras, aproveita os métodos padrão e cria as ações com eles no seu tipo de mídia. Se bem feito, há menos acoplamento e as alterações podem ser tratadas com mais graciosidade. Um cliente deve inserir um serviço REST com zero conhecimento da API, exceto o ponto de entrada e o tipo de mídia. No SOAP, o cliente precisa de conhecimento prévio sobre tudo o que estará usando ou nem começará a interação. Além disso, um cliente REST pode ser estendido por código sob demanda fornecido pelo próprio servidor,

Eu acho que esses são os pontos cruciais para entender o que é o REST e como ele difere do SOAP:

• O REST é independente de protocolo. Não está acoplado ao HTTP. Assim como você pode seguir um link ftp em um site, um aplicativo REST pode usar qualquer protocolo para o qual exista um esquema de URI padronizado.

• REST não é um mapeamento de métodos CRUD para HTTP. Leia esta resposta para obter uma explicação detalhada sobre isso.

• O REST é tão padronizado quanto as peças que você está usando. A segurança e a autenticação no HTTP são padronizadas, e é isso que você usa ao executar o REST sobre HTTP.

• REST não é REST sem hipermídia e HATEOAS . Isso significa que um cliente conhece apenas o URI do ponto de entrada e os recursos devem retornar os links que o cliente deve seguir. Os geradores de documentação sofisticados que fornecem padrões de URI para tudo o que você pode fazer em uma API REST não entendem completamente. Eles não estão apenas documentando algo que deveria estar seguindo o padrão, mas quando você faz isso, você está acoplando o cliente a um momento específico da evolução da API, e todas as alterações na API precisam ser documentadas e aplicadas, ou vai quebrar.

• REST é o estilo arquitetural da própria web. Ao inserir Estouro de pilha, você sabe o que é um Usuário, uma Pergunta e uma Resposta, conhece os tipos de mídia e o site fornece os links para eles. Uma API REST deve fazer o mesmo. Se projetássemos a Web da maneira que as pessoas pensam que o REST deveria ser feito, em vez de ter uma home page com links para perguntas e respostas, teríamos uma documentação estática explicando que, para visualizar uma pergunta, você precisa usar o URI stackoverflow.com/questions/<id>, substitua o id pelo Question.id e cole-o no seu navegador. Isso é um absurdo, mas é o que muitas pessoas pensam que é o REST.

Este último ponto não pode ser enfatizado o suficiente. Se seus clientes estão construindo URIs a partir de modelos na documentação e não obtendo links nas representações de recursos, isso não é REST. Roy Fielding, o autor do REST, deixou claro nesta postagem do blog: As APIs REST devem ser orientadas por hipertexto .

Com o exposto acima, você perceberá que, embora o REST possa não estar restrito ao XML, para fazê-lo corretamente com qualquer outro formato, você precisará projetar e padronizar algum formato para seus links. Os hiperlinks são padrão em XML, mas não em JSON. Existem rascunhos de padrões para JSON, como o HAL .

Finalmente, o REST não é para todos, e uma prova disso é como a maioria das pessoas resolve seus problemas muito bem com as APIs HTTP que eles chamaram erroneamente de REST e nunca se aventuram além disso. Às vezes, é difícil fazer o REST, especialmente no começo, mas vale a pena com o tempo, com uma evolução mais fácil no lado do servidor e com a resiliência do cliente às mudanças. Se você precisar de algo rápido e fácil, não se preocupe em acertar o REST. Provavelmente não é o que você está procurando. Se você precisar de algo que precisará permanecer online por anos ou décadas, o REST é para você.

RESTvs nãoSOAP é a pergunta certa a fazer.

REST, diferente de nãoSOAP é um protocolo.

RESTé um estilo arquitetônico e um design para arquiteturas de software baseadas em rede.

RESTconceitos são referidos como recursos. Uma representação de um recurso deve ser sem estado. É representado através de algum tipo de mídia. Alguns exemplos de tipos de mídia incluem XML, JSONe RDF. Os recursos são manipulados pelos componentes. Os componentes solicitam e manipulam recursos por meio de uma interface uniforme padrão. No caso do HTTP, esta interface é constituído por operações padrão de HTTP por exemplo GET, PUT, POST, DELETE.

@ Pergunta de Abdulaziz faz iluminar o fato de que RESTe HTTPsão muitas vezes utilizados em conjunto. Isso se deve principalmente à simplicidade do HTTP e ao seu mapeamento muito natural para os princípios RESTful.

Princípios fundamentais do REST

Comunicação Cliente-Servidor

As arquiteturas cliente-servidor têm uma separação muito distinta de preocupações. Todos os aplicativos criados no estilo RESTful também devem ser, em princípio, cliente-servidor.

Sem Estado

Cada solicitação do cliente para o servidor requer que seu estado seja totalmente representado. O servidor deve ser capaz de entender completamente a solicitação do cliente sem usar nenhum contexto ou estado da sessão do servidor. Daqui resulta que todo estado deve ser mantido no cliente.

Armazenável em cache

As restrições de cache podem ser usadas, permitindo que os dados de resposta sejam marcados como armazenáveis ​​em cache ou não em cache. Quaisquer dados marcados como armazenáveis ​​em cache podem ser reutilizados como resposta à mesma solicitação subsequente.

Interface uniforme

Todos os componentes devem interagir através de uma única interface uniforme. Como toda a interação de componentes ocorre por meio dessa interface, a interação com diferentes serviços é muito simples. A interface é a mesma! Isso também significa que as mudanças na implementação podem ser feitas isoladamente. Tais alterações não afetarão a interação fundamental dos componentes porque a interface uniforme é sempre inalterada. Uma desvantagem é que você está preso à interface. Se uma otimização puder ser fornecida a um serviço específico alterando a interface, você estará sem sorte, pois o REST proíbe isso. Pelo lado positivo, no entanto, o REST é otimizado para a Web, daí a incrível popularidade do REST sobre HTTP!

Os conceitos acima representam características definidoras do REST e diferenciam a arquitetura REST de outras arquiteturas, como serviços da web. É útil observar que um serviço REST é um serviço da Web, mas um serviço da Web não é necessariamente um serviço REST.

Consulte esta publicação no blog sobre Princípios de Design do REST para obter mais detalhes sobre o REST e os marcadores indicados acima.

EDIT: atualiza o conteúdo com base nos comentários

O SOAP ( Simple Object Access Protocol ) e o REST ( Representation State Transfer ) são belos em seu caminho. Então, eu não estou comparando eles. Em vez disso, estou tentando representar a imagem, quando preferi usar o REST e quando o SOAP.

O que é carga útil?

Quando os dados são enviados pela Internet, cada unidade transmitida inclui as informações do cabeçalho e os dados reais que estão sendo enviados. O cabeçalho identifica a origem e o destino do pacote, enquanto os dados reais são referidos como carga útil . Em geral, a carga útil são os dados transportados em nome de um aplicativo e os dados recebidos pelo sistema de destino.

Agora, por exemplo, tenho que enviar um telegrama e todos sabemos que o custo do telegrama dependerá de algumas palavras.

Diga-me entre as duas mensagens abaixo mencionadas, qual é mais barata para enviar?

<name>Arin</name>

ou

"name": "Arin"

Sei que sua resposta será a segunda, embora ambas representem a mesma mensagem, a segunda seja mais barata em relação ao custo.

Então, estou tentando dizer que enviar dados pela rede no formato JSON é mais barato do que enviá-los no formato XML com relação à carga útil .

Aqui está o primeiro benefício ou vantagens do REST sobre SOAP . O SOAP suporta apenas XML, mas o REST suporta formatos diferentes, como texto, JSON, XML, etc.

Agora, o SOAP suporta o único XML, mas também tem suas vantagens.

Realmente! Quão?

O SOAP depende do XML de três maneiras: Envelope - que define o que está na mensagem e como processá-la.

Um conjunto de regras de codificação para tipos de dados e, finalmente, o layout das chamadas e respostas do procedimento reunidas.

Esse envelope é enviado via transporte (HTTP / HTTPS), e uma RPC (Chamada de Procedimento Remoto) é executada, e o envelope é retornado com informações em um documento formatado em XML.

O ponto importante é que uma das vantagens do SOAP é o uso do transporte "genérico", mas o REST usa HTTP / HTTPS . O SOAP pode usar quase qualquer transporte para enviar a solicitação, mas o REST não pode. Então, aqui temos a vantagem de usar o SOAP.

Como eu já mencionei no parágrafo acima, “O REST usa HTTP / HTTPS” , vá um pouco mais fundo nessas palavras.

Quando falamos de REST sobre HTTP, todas as medidas de segurança aplicadas ao HTTP são herdadas, e isso é conhecido como segurança no nível de transporte e protege as mensagens apenas enquanto estiver dentro do fio, mas depois que você o entrega do outro lado, você não sabe Quantas etapas serão necessárias antes de chegar ao ponto real em que os dados serão processados. E, é claro, todos esses estágios poderiam usar algo diferente do HTTP. Então, o resto não é mais seguro, certo?

Mas o SOAP suporta SSL, assim como o REST, além disso , também suporta o WS-Security, que adiciona alguns recursos de segurança da empresa. O WS-Security oferece proteção desde a criação da mensagem até seu consumo . Portanto, para segurança no nível de transporte, qualquer lacuna encontrada que possa ser evitada usando o WS-Security.

Além disso, como o REST é limitado pelo protocolo HTTP , o suporte à transação não é compatível com ACID nem pode fornecer confirmação em duas fases entre os recursos transnacionais distribuídos.

Porém, o SOAP oferece suporte abrangente ao gerenciamento de transações baseado em ACID para transações de curta duração e gerenciamento de transações baseado em compensação para transações de longa duração. Ele também suporta confirmação de duas fases nos recursos distribuídos .

Não estou chegando a nenhuma conclusão, mas preferirei o serviço Web baseado em SOAP, enquanto segurança, transação etc. são as principais preocupações.

Aqui está o "Tutorial do Java EE 6", onde eles disseram que Um design RESTful pode ser apropriado quando as seguintes condições forem atendidas . Dar uma olhada.

Espero que tenha gostado de ler minha resposta.

RESTO ( RE apresentação S tate T ransferência)
RE apresentação S tate de um objeto é T ransferred é o descanso, ou seja, nós não enviar objeto, enviamos estado de objeto. REST é um estilo arquitetônico. Ele não define tantos padrões como o SOAP. O REST é para expor APIs públicas (por exemplo, API do Facebook, API do Google Maps) pela Internet para manipular operações CRUD nos dados. O REST está focado no acesso aos recursos nomeados por meio de uma única interface consistente.

SABÃO ( S exe O bject Um cesso P rotocolo)
SABÃO traz o seu próprio protocolo e concentra-se em pedaços de expor a lógica da aplicação (não dados) como serviços. SOAP expõe operações. O SOAP está focado no acesso a operações nomeadas, cada operação implementa alguma lógica de negócios. Embora o SOAP seja comumente chamado de serviços da Web, isso é impróprio. O SOAP tem muito pouco ou nada a ver com a Web. O REST fornece verdadeiros serviços da Web baseados em URIs e HTTP.

Por que descansar?

• Como o REST usa o HTTP padrão, é muito mais simples de qualquer maneira.
• O REST é mais fácil de implementar, requer menos largura de banda e recursos.
• O REST permite muitos formatos de dados diferentes, enquanto o SOAP permite apenas XML.
• O REST permite um melhor suporte aos clientes do navegador devido ao suporte ao JSON.
• O REST tem melhor desempenho e escalabilidade. As leituras REST podem ser armazenadas em cache, as leituras baseadas em SOAP não podem ser armazenadas em cache.
• Se a segurança não é uma grande preocupação e temos recursos limitados. Ou queremos criar uma API que será facilmente usada por outros desenvolvedores publicamente, então devemos usar o REST.
• Se precisarmos de operações CRUD sem estado, vá com REST.
• O REST é comumente usado em mídias sociais, bate-papo na web, serviços móveis e APIs públicas como o Google Maps.
• O serviço RESTful retorna vários MediaTypes para o mesmo recurso, dependendo do parâmetro do cabeçalho da solicitação "Accept" como application/xmlou application/jsonpara POST e /user/1234.jsonou GET /user/1234.xmlfor GET.
• Os serviços REST devem ser chamados pelo aplicativo do lado do cliente e não diretamente pelo usuário final.
• ST no resto vem de S tate T ransferência. Você transfere o estado ao redor, em vez de o servidor armazená-lo, isso torna os serviços REST escaláveis.

Por que SOAP?

• O SOAP não é muito fácil de implementar e requer mais largura de banda e recursos.
• A solicitação de mensagem SOAP é processada mais lentamente em comparação com o REST e não usa o mecanismo de cache da web.
• Segurança WS: Embora o SOAP suporte SSL (assim como o REST), ele também suporta WS-Security, que adiciona alguns recursos de segurança da empresa.
• WS-AtomicTransaction: precisa de transações ACID em um serviço, você precisará de SOAP.
• WS-ReliableMessaging: se o seu aplicativo precisar de processamento assíncrono e um nível garantido de confiabilidade e segurança. O Rest não possui um sistema de mensagens padrão e espera que os clientes lidem com falhas de comunicação tentando novamente.
• Se a segurança é uma grande preocupação e os recursos não são limitados, devemos usar os serviços da web SOAP. Como se estivéssemos criando um serviço da Web para gateways de pagamento, trabalho relacionado a finanças e telecomunicações, devemos usar o SOAP, pois aqui é necessária alta segurança.

source1
source2

Diferença entre Rest e Soap

SABONETE

1. SOAP é um protocolo.
2. SOAP significa Simple Object Access Protocol.
3. O SOAP não pode usar o REST porque é um protocolo.
4. O SOAP usa interfaces de serviços para expor a lógica de negócios.
5. O SOAP define padrões a serem rigorosamente seguidos.
6. O SOAP requer mais largura de banda e recursos que o REST.
7. SOAP define sua própria segurança.
8. SOAP permite apenas o formato de dados XML.
9. SOAP é menos preferido que REST.

DESCANSAR

1. REST é um estilo arquitetônico.
2. REST significa Representational State Transfer.
3. O REST pode usar serviços da web SOAP porque é um conceito e pode usar qualquer protocolo como HTTP, SOAP.
4. O REST usa o URI para expor a lógica de negócios.
5. O REST não define muitos padrões como SOAP.
6. O REST requer menos largura de banda e recursos que o SOAP.
7. Os serviços da Web RESTful herdam medidas de segurança do transporte subjacente.
8. O REST permite diferentes formatos de dados, como texto sem formatação, HTML, XML, JSON etc.
9. REST é mais preferido que SOAP.

Para mais detalhes, consulte aqui

IMHO, você não pode comparar SOAP e REST, onde essas são duas coisas diferentes.

SOAP é um protocolo e REST é um padrão de arquitetura de software. Há muitos conceitos errados na Internet para SOAP vs REST .

O SOAP define o formato de mensagem baseado em XML que os aplicativos habilitados para serviços da Web usam para se comunicar pela Internet. Para isso, os aplicativos precisam ter conhecimento prévio do contrato de mensagem, tipos de dados, etc.

O REST representa o estado (como recursos) de um servidor a partir de uma URL. Ele é sem estado e os clientes não devem ter conhecimento prévio para interagir com o servidor além do entendimento da hipermídia.

Primeiro de tudo: oficialmente, a pergunta correta seria web services + WSDL + SOAPvs REST.

Como, embora o serviço da Web seja usado no sentido lato, ao usar o protocolo HTTP para transferir dados em vez de páginas da Web, oficialmente é uma forma muito específica dessa ideia. De acordo com a definição, o REST não é "serviço da web".

Na prática, no entanto, todo mundo ignora isso, então vamos ignorá-lo também

Já existem respostas técnicas, então tentarei fornecer alguma intuição.

Digamos que você queira chamar uma função em um computador remoto, implementado em alguma outra linguagem de programação (isso geralmente é chamado de chamada de procedimento remoto / RPC ). Suponha que a função possa ser encontrada em um URL específico, fornecido pela pessoa que a escreveu. Você precisa (de alguma forma) enviar uma mensagem e obter alguma resposta. Portanto, há duas questões principais a serem consideradas.

• qual é o formato da mensagem que você deve enviar
• como a mensagem deve ser transmitida

Para a primeira pergunta, a definição oficial é WSDL . Este é um arquivo XML que descreve, em formato detalhado e estrito, quais são os parâmetros, quais são seus tipos, nomes, valores padrão, o nome da função a ser chamada etc. Um exemplo de WSDL aqui mostra que o arquivo é humano -readable (mas não facilmente).

Para a segunda pergunta, existem várias respostas. No entanto, o único usado na prática é o SOAP . Sua idéia principal é: agrupar o XML anterior (a mensagem real) em outro XML (contendo informações de codificação e outras informações úteis) e enviá-lo por HTTP. O método POST do HTTP é usado para enviar a mensagem, pois sempre há um corpo .

A idéia principal de toda essa abordagem é que você mapeie uma URL para uma função , ou seja, para uma ação . Portanto, se você possui uma lista de clientes em algum servidor e deseja visualizar / atualizar / excluir um, deve ter três URLs:

• myapp/read-customer e no corpo da mensagem, passe o ID do cliente para ser lido.
• myapp/update-customer e no corpo, passe o ID do cliente, bem como os novos dados
• myapp/delete-customer e o id no corpo

A abordagem REST vê as coisas de maneira diferente. Uma URL não deve representar uma ação, mas uma coisa (chamada recurso na linguagem REST). Como o protocolo HTTP (que já estamos usando) suporta verbos, use esses verbos para especificar quais ações executar na coisa.

Portanto, com a abordagem REST, o cliente número 12 seria encontrado no URL myapp/customers/12. Para visualizar os dados do cliente, você acessa o URL com uma solicitação GET. Para excluí-lo, o mesmo URL, com um verbo DELETE. Para atualizá-lo, novamente, a mesma URL com um verbo POST e o novo conteúdo no corpo da solicitação.

Para obter mais detalhes sobre os requisitos que um serviço precisa atender para ser considerado verdadeiramente RESTful, consulte o modelo de maturidade de Richardson . O artigo fornece exemplos e, mais importante, explica por que um serviço (chamado) SOAP é um serviço REST de nível 0 (embora nível 0 signifique baixa conformidade com esse modelo, não é ofensivo e ainda é útil em muitos casos).

Entre muitas outras já abordadas nas muitas respostas, eu destacaria que o SOAP permite definir um contrato, o WSDL, que define as operações suportadas, tipos complexos etc. O SOAP é orientado para operações, mas o REST é orientado para recursos. Pessoalmente, selecionaria SOAP para interfaces complexas entre aplicativos corporativos internos e REST para interfaces públicas, mais simples e sem estado com o mundo externo.

Adição para:

++ Um erro frequentemente cometido ao abordar o REST é pensar nele como "serviços da web com URLs" - pensar no REST como outro mecanismo de chamada de procedimento remoto (RPC), como SOAP, mas invocado por meio de URLs HTTP simples e sem o peso da SOAP Namespaces XML.

++ Pelo contrário, o REST tem pouco a ver com o RPC. Enquanto o RPC é orientado a serviços e focado em ações e verbos, o REST é orientado a recursos, enfatizando as coisas e os substantivos que compõem um aplicativo.

Muitas dessas respostas esqueceram completamente de mencionar os controles hipermídia (HATEOAS), que são completamente fundamentais para o REST. Alguns outros tocaram, mas realmente não explicaram tão bem.

Este artigo deve explicar a diferença entre os conceitos, sem entrar em detalhes sobre os recursos SOAP específicos.