Sabão vs repouso (diferenças)

REST vs SOAP is não a pergunta certa a fazer.

REST, ao contrário de SOAP não um protocolo.

REST is an architectural style and a design for network-based software architectures.

REST os conceitos são referidos como recursos. Uma representação de um recurso deve ser apátrida. É representado através de algum tipo de mídia. Alguns exemplos de tipos de mídia incluem XML, JSON, e RDF Os recursos são manipulados por componentes. Os componentes solicitam e manipulam recursos através de uma interface uniforme padrão. No caso de HTTP, esta interface consiste de ops HTTP padrão.GET, PUT, POST, DELETE.

A pergunta de@Abdulaziz esclarece o fato de que {[[0]} e HTTP são frequentemente usados em conjunto. Isso é principalmente devido à simplicidade do HTTP e seu mapeamento natural para princípios repousantes.

Descanso Fundamental Princípios

Comunicação Cliente-Servidor

As arquitecturas cliente-servidor têm uma separação muito distinta de preocupações. Todas as aplicações construídas no estilo RESTful também devem ser cliente-servidor em princípio.

Apátrida

Cada pedido de cliente ao servidor requer que o seu estado seja totalmente representado. O servidor deve ser capaz de entender completamente o pedido do cliente sem usar qualquer contexto do servidor ou estado de sessão do servidor. Ele portanto, todo o estado deve ser mantido sobre o cliente.

Cacheável

Podem ser utilizadas restrições de Cache, permitindo assim que os dados de resposta sejam marcados como cacheáveis ou não cacheáveis. Quaisquer dados marcados como cacheáveis podem ser reutilizados como Resposta ao mesmo pedido subsequente.

Interface Uniforme

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

Os conceitos acima representam características definidoras do descanso e diferenciam a arquitectura do resto de outras arquitecturas como os serviços web. É útil notar que um serviço de repouso é um serviço web, mas um serviço web não é necessariamente um serviço de repouso.

Veja este blog post on REST Design Principles para mais detalhes sobre REST e o acima indicado marcador.

editar: actualizar o conteúdo com base nos comentários

SOAP (protocolo simples de acesso a objectos ) e descanso ({[[4]}representação transferência de Estado ) ambos são bonitos no seu caminho. Por isso, não os estou a comparar. Em vez disso, estou tentando descrever a imagem, quando eu preferi usar o descanso e quando o sabão.

O que é a carga útil?

Quando os dados são enviados pela Internet, Cada unidade transmitida inclui tanto a informação do cabeçalho como os dados reais que estão a ser enviados. O cabeçalho identifica a origem e o destino do pacote, enquanto os dados reais são referidos como a carga útil . Em geral, a carga útil são os dados que são transportados em nome de uma aplicação e os dados recebidos pelo sistema de destino.

diga-me, entre as mensagens abaixo mencionadas, qual delas é mais barata de enviar?

<name>Arin</name>

Ou

"name": "Arin"

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

Aqui está o primeiro benefício ou vantagens do descanso sobre o sabão . SOAP só suporta XML, mas REST suporta diferentes formatos como texto, JSON, XML, etc. E já sabemos, se usarmos o Json, definitivamente estaremos em melhor posição em relação à carga útil.

A sério! Como?

Um conjunto de regras de codificação para os tipos de dados, e finalmente o layout das chamadas de procedimento e Respostas recolhidas.

Este envelope é enviado através de um transporte (HTTP / HTTPS), e um RPC (chamada de procedimento remoto) é executado, e o envelope é devolvido com informações em um documento formatado XML.

O ponto importante é que uma das vantagens do SOAP é o uso do "Genérico" transporte mas o resto usa HTTP/HTTPS. Sabão pode usar quase qualquer transporte para enviar o pedido, mas o resto não pode. Aqui temos a vantagem de usar sabão.

Como já mencionei no parágrafo acima "REST usa HTTP/HTTPS" , então vá um pouco mais fundo sobre estes palavra.

Quando estamos falando de RESTO sobre HTTP, todas as medidas de segurança aplicadas HTTP são herdadas, e isso é conhecido como segurança de nível de transporte e protege as mensagens somente enquanto é no interior do fio, mas uma vez que você entregou por outro lado, você não sabe quantas etapas terá de percorrer antes de alcançar o ponto real onde os dados serão processados. E é claro, todas essas etapas poderiam usar algo diferente do HTTP.Então o descanso não é mais seguro completamente, certo?

Mas o SOAP suporta o SSL tal como o REST adicionalmente {[[4]} também suporta o WS-Security que adiciona algumas funcionalidades de segurança da empresa. WS-Security oferece proteção contra a criação da mensagem para o seu consumo . Portanto, para o nível de segurança dos transportes, seja qual for a lacuna que encontrámos que possa ser evitada através da WS-segurança.

Além disso, como O descanso é limitado pelo protocolo HTTP por isso o Suporte de transacção não é ácido compatível nem pode fornecer compromissos em duas fases através de recursos transnacionais distribuídos.

Mas a SOAP tem um apoio abrangente para a gestão de transacções baseadas no ácido para transacções de curta duração e para a gestão de transacções baseada na compensação para transacções a longo prazo. Ele também suporta compromisso em duas fases através de recursos distribuídos .

Não estou a tirar nenhuma conclusão, mas prefiro o serviço web baseado em sabonetes enquanto segurança, transacção, etc. são os principais preocupacao.

Aqui está o "Tutorial Java EE 6" onde eles disseram um design repousante pode ser apropriado quando as seguintes condições são cumpridas. Ver.

espero que tenha gostado de ler a minha resposta.

Descanso(re presentationalS tate T ransfer)
O descanso é um estilo arquitetônico. Não define tantos padrões como sabão. O resto é para expor APIs públicas (ou seja, API do Facebook, API do Google Maps) através da internet para lidar com operações CRUD em dados. O resto é focado em acessar recursos nomeados através de uma única interface consistente.

SABÃO(Simple Object Umacesso Protocol)
O sabão traz seu próprio protocolo e se concentra em expor peças da lógica de aplicação (não dados) como serviços. O sabão expõe as operações. A SOAP está focada em acessar as operações nomeadas, cada operação implementa alguma lógica de negócios. Embora o SOAP seja comumente referido como serviços web {[7] } Este é o nome errado. Sabão tem muito pouco ou nada a ver com a Web. O REST fornece os serviços web true baseados em URIs e HTTP.

Porquê descansar?

• desde que o REST usa HTTP padrão é muito mais simples em quase todos os sentidos.
• O descanso é mais fácil de implementar, requer menos largura de banda e recursos.
• O descanso permite muitos formatos de dados diferentes onde como SOAP só permite XML.
• O descanso permite um melhor suporte para os clientes do navegador devido ao seu suporte para o JSON.
O descanso tem melhor desempenho e escalabilidade. As leituras de descanso podem ser cache, as leituras baseadas em sabão não podem ser Cache.
• Se a segurança não é uma grande preocupação e nós temos limitado recurso. Ou queremos criar uma API que será facilmente usada por outros desenvolvedores publicamente, então devemos ir com o descanso.
Se precisarmos de operações sem estado, vamos descansar.
• O descanso é normalmente utilizado nas redes sociais, no chat web, nos serviços móveis e nas APIs públicas, como o Google Maps.
• RESTful service return various MediaTypes for the same resource, depending on the request header parameter "Accept" as application/xml or application/json for POST and /user/1234.json or GET /user/1234.xml for OBTER.
• os Serviços de repouso devem ser chamados pela aplicação cliente-lado e não pelo Utilizador Final directamente.
• ST em repouso vem deS tate T ransfer. Você transfere o estado ao redor em vez de ter o servidor armazená-lo, Isso torna os Serviços de repouso escaláveis.

Porquê sabão?

O SOAP não é muito fácil de implementar e requer mais largura de banda e recursos. O pedido de mensagens SOAP é processado mais lentamente como comparado ao descanso e não usa mecanismo de cache web.
• ws-segurança: enquanto o SOAP suporta SSL (tal como o resto), também suporta ws-segurança que adiciona alguns recursos de segurança da empresa.
• ws-AtomicTransaction: {[[7]} Need ACID Transactions over a service, you're gonna need SOAP.
• WS-ReliableMessaging: If your application needs Assynchronous processing and a guaranteed level of reliability and security. O resto não tem sistema de mensagens padrão e espera que os clientes para lidar com falhas de comunicação por refazer.
Se a segurança é uma grande preocupação e os recursos não são limitados, então devemos usar os serviços da SOAP web. Como se estivéssemos criando um serviço web para gateways de Pagamento, trabalho financeiro e de telecomunicações, então nós deveríamos ir com sabão como aqui alta segurança é necessária.

Origem 1
origem 2

A decisão entre os dois será a sua primeira escolha na concepção de um serviço web, por isso é importante compreender os prós e os contras dos dois. Também é importante, no debate por vezes aceso entre as duas filosofias, separar a realidade da retórica.

Fundamentos do resto

• Tudo em repouso é considerado como um recurso.
• Todos os recursos são identificados por um URI.
• usa interfaces uniformes. Os recursos são tratados usando POST, Operações GET, PUT, DELETE que são semelhantes para criar, ler, atualizar e excluir (CRUD) operações.
• sê apátrida. Cada pedido é um pedido independente. Cada pedido de cliente a servidor deve conter todas as informações necessárias para entender o pedido.
As comunicações são feitas através de representações. Por exemplo, XML, JSON RESTful Web Services. A RESTful web services are based on HTTP methods and the concept of REST. Um serviço Web repousante tipicamente define o URI base para o Serviços; os tipos MIME suportados (XML, text, JSON, user-defined, ...) e o conjunto de operações (POST, GET, PUT, DELETE) que são suportadas.

Fundamentos do sabão

A WSDL define o contrato entre o cliente e o serviço e é estática pela sua natureza.
• o SOAP constrói um protocolo baseado em XML no topo do HTTP ou, por vezes, TCP/IP.
O SOAP descreve funções e tipos de dados.
• SOAP é um sucessor do XML-RPC e é muito semelhante, mas descreve uma forma normal de comunicar.
• várias linguagens de programação têm suporte nativo para o SOAP, você normalmente dá-lhe um URL de serviço web, e você pode chamar suas funções de serviço web sem a necessidade de código específico.
• os dados binários que são enviados devem ser codificados primeiro num formato como o base64 codificado.
• tem vários protocolos e tecnologias relacionados com ele: WSDL, XSD, SOAP, WS-Addressing.

Sabão contra descanso?

Com Descanso Serviços, segurança de mensagens é fornecido pelo protocolo de transporte (HTTPS) e é apenas ponto a ponto. Ele não tem um sistema de mensagens padrão e espera que os clientes lidem com falhas de comunicação por refazer. A SOAP tem uma lógica de sucesso/retry construída e fornece confiabilidade de ponta a ponta mesmo através de intermediários de sabão.

Um dos principais benefícios da API repousante é que ela é flexível para a representação de dados, por exemplo, você poderia serializar seus dados em qualquer formato XML ou JSON. As API RESTful são mais limpas ou mais fáceis de entender porque elas adicionam um elemento de uso de URIs padronizados e dão importância ao verbo HTTP usado (i.e., GET, POST, PUT e DELETE).

Os serviços de descanso também são leves, ou seja, não têm muita marcação XML extra. Para invocar a API repousante tudo o que você precisa é de um navegador ou pilha HTTP e praticamente todos os dispositivos ou máquinas conectados a uma rede tem isso.

Vantagens do descanso

• Uma vez que o resto usa o padrão HTTP, é muito mais simples em quase todos os sentidos. Criar clientes, desenvolver APIs, a documentação é muito mais fácil de entender, e não há muitas coisas que o descanso não faz mais fácil/melhor do que sabão.
• O descanso permite muitos formatos de dados diferentes, enquanto o SOAP só permite XML. Embora isto possa parecer que adiciona complexidade para descansar, porque você precisa lidar com vários formatos, na minha experiência, tem sido bastante benéfico. JSON geralmente é um ajuste melhor para dados e analises muito rapidamente. O descanso permite um melhor suporte para os clientes do navegador devido ao seu suporte para a JSON.
O descanso tem melhor desempenho e escalabilidade. As leituras de descanso podem ser cache; as leituras baseadas em sabão não podem ser Cache.
• nenhuma ferramenta dispendiosa necessita de interagir com o serviço web
• menor curva de aprendizagem
• eficiente (o SOAP usa XML para todas as mensagens, o resto pode usar formatos de mensagens mais pequenos)
• Rápido (Sem necessidade de processamento extensivo)
Mais próximo de outras tecnologias Web em design filosofia

Vantagens do sabão

• ws-segurança: enquanto o SOAP suporta SSL (tal como o resto), também suporta ws-segurança que adiciona alguns recursos de segurança da empresa. Suporta a identidade através de intermediários, não apenas apontar para o ponto (SSL). Ele também fornece uma implementação padrão de integridade de dados e privacidade de dados. Chamar-lhe "empresa" não é dizer que é mais seguro, simplesmente suporta algumas ferramentas de segurança que os Serviços de internet típicos não necessidade de, na verdade, eles são apenas necessários em alguns cenários "enterprise".
• ws-AtomicTransaction: {[[5]} Need ACID Transactions over a service, you're gonna need SOAP. Enquanto o descanso suporta transações, não é tão abrangente e não é compatível com ácido. Felizmente, as transacções ácidas quase nunca fazem sentido na internet. O descanso é limitado pelo próprio HTTP, que não pode fornecer commit em duas fases através de recursos transacionais distribuídos, mas o SOAP pode. Aplicativos de Internet não precisam disso nível de confiabilidade transacional, aplicativos corporativos às vezes fazem.
• WS-ReliableMessaging: O descanso não tem um sistema de mensagens padrão e espera que os clientes lidem com falhas de comunicação através da repetição. A SOAP tem uma lógica de sucesso/retry construída e fornece confiabilidade de ponta a ponta mesmo através de intermediários de sabão.
• Independente da língua, plataforma e transporte (o resto requer o uso de HTTP)
• funciona bem em ambientes empresariais distribuídos (o resto assume comunicação directa ponto a ponto) ([9]}
• padronizado
• proporciona extensibilidade significativa pré-construção sob a forma de normas WS
• tratamento integrado de erros
• automatização quando utilizada com certos produtos linguísticos

Onde utilizar o descanso

As áreas para as quais o descanso funciona bem são:

• largura de banda limitada e recursos: lembre-se que a estrutura de retorno está realmente em qualquer formato (definido pelo programador). Além disso, qualquer navegador pode ser usado porque a abordagem do resto usa o padrão GET, PUT, POST e DELETE verbos. Novamente, lembre-se que o REST também pode usar o objeto XMLHttpRequest que a maioria dos navegadores modernos suportam hoje, o que adiciona um bônus do AJAX.
• operações apátridas: se uma operação precisa de ser continuada, então o descanso não é a melhor abordagem e sabão pode caber melhor. No entanto, se você precisar de operações CRUD sem estado (criar, ler, atualizar e excluir), então o resto é ele.
• Caching situações: se a informação pode ser obtida devido ao funcionamento apátrida da abordagem do resto, isto é perfeito.

Onde usar sabão

Áreas onde o sabão funciona como uma grande solução:

• processamento assíncrono e Invocação: se a sua aplicação necessitar de um nível garantido de fiabilidade e segurança, o SOAP 1.2 oferece normas adicionais para garantir este tipo de operação. Coisas como WSRM-WS-confiáveis Mensagem.
• contratos formais: Se ambas as partes (fornecedores e consumidores) tiverem de chegar a acordo sobre o formato de troca, então o SABONET 1.2 fornece as especificações rígidas para este tipo de interacção.
• operações Stateful: se a aplicação necessitar de informação contextual e de gestão do Estado de conversação, então o SOAP 1.2 tem a especificação adicional na estrutura do WS para suportar essas coisas (segurança, transacções, coordenação, etc.). Comparativamente, a abordagem do resto faria com que os desenvolvedores construíssem essa canalização personalizada.

Diferença entre o descanso e o sabão

Sabonete

O sabonete é um protocolo. SOAP significa Protocolo de acesso a objectos simples. O sabão não pode descansar porque é um protocolo. O SOAP usa interfaces de serviços para expor a lógica empresarial. O SOAP define normas a serem rigorosamente seguidas. O SOAP requer mais largura de banda e recursos do que descanso. O SOAP define a sua própria segurança.
1. o SOAP permite o formato de dados XML apenas.
2. O sabão é menos preferido do que o descanso.

Descanso

O descanso é um estilo arquitectónico.
1. descanso significa transferência de Estado representacional.
2. O descanso pode usar serviços web SOAP porque é um conceito e pode usar qualquer protocolo como HTTP, SOAP.
O descanso usa o URI para expor a lógica dos negócios. O descanso não define muitos padrões como sabão.
3. O descanso requer menos largura de banda e recursos do que o sabão.
4. RESTful web os Serviços herdam medidas de segurança do transporte subjacente.
5. O descanso permite diferentes formatos de dados, como texto simples, HTML, XML, JSON, etc.
6. descanso mais preferido do que sabão.

Para mais detalhes, por favor veja aqui

O SOAP é um protocolo e o resto é um padrão arquitectónico de software. Há um monte de equívocos na internet para sabão vs descanso.

O SOAP define o formato de mensagem baseado em XML que as aplicações ligadas ao serviço web usam para se comunicarem umas às outras através da internet. Para que as aplicações necessitem de conhecimento prévio do contrato de mensagem, tipos de dados, etc..

REST representa o estado(como recursos) de um servidor a partir de um URL.It é apátrida e os clientes não devem ter conhecimento prévio para interagir com o servidor além da compreensão da hypermedia.

Adição de:

++ um erro que é muitas vezes cometido quando se aproxima do descanso é pensar nele como "serviços web com URLs"-pensar no descanso como outro mecanismo de chamada de procedimento remoto (RPC), como o SOAP, mas invocado através de URLs HTTP simples e sem os espaços de nomes XML robustos do SOAP.

++ pelo contrário, o descanso tem pouco a ver com RPC. Enquanto a RPC é orientada para o serviço e focada em ações e verbos, o descanso é orientado para os recursos, enfatizando as coisas e substantivos que compõem um aplicacao.

Este artigo {[5] } deve explicar a diferença entre os conceitos, sem entrar nas ervas daninhas sobre características específicas do sabão.

O sabão é um protocolo, enquanto o resto é arquitectura. O sabão expõe comportamentos que representam a lógica, enquanto o resto expõe recursos que representam dados. Em termos de consumo, o serviço de repouso é muito mais simples do que o sabão. Com o descanso sobre o manuseio de envelopes XML é eliminado, o que o torna mais rápido em comparação com sabão. O SOAP forneceu boas opções de segurança em comparação com o resto.
• para interacção máquina-máquina & soluções empresariais sabão é preferível, mas para o público que enfrenta o descanso da API é a melhor opção quase 70% API pública são descanso.
• O descanso é leve, sustentável e escalável.
• O descanso é independente do dispositivo, ou seja, a API que consome clientes pode ser qualquer coisa como dispositivos móveis, Notebooks, TV, etc.
Com a nuvem a entrar em acção. A aplicação está lentamente se movendo para sistemas baseados em nuvem, como Azure, Amazon AWS. Estes sistemas são construídos e expondo API de REST. portanto, é uma boa jogada para construir a aplicação no topo da API resto.

Descanso Vs sabonete

Em primeiro lugar: no sentido lato, serviço web significa usar o protocolo HTTP para transferir Dados em vez de páginas web. No entanto, no sentido estrito, um serviço web, como definido por W3C é uma forma muito específica dessa ideia. Então, quando as pessoas falam sobre SOAP vs. REST , eles realmente significam serviços web vs. REST (onde "serviços web" se refere à definição oficial, uma vez que, na prática, os Serviços de descanso também são chamados de serviços web por todo).

• Qual é o formato da mensagem que deve enviar
• como deve a mensagem ser transmitida e forth

De Acordo com a definição oficial, a resposta para a primeira pergunta é: o WSDL, um XML, que descreve, em detalhado e rigoroso formato, quais são os parâmetros, quais são os seus tipos, nomes, valores padrão, o nome da função a ser chamada, etc. Quanto à segunda questão, há várias respostas. O mais popular (de longe) é sabão. A sua ideia principal é: envolver o XML anterior (a mensagem actual) em mais um XML, e enviá - lo por HTTP (embora, em teoria, possa ser usado com outros protocolos, mas nunca ninguém o faz). O método de POST do HTTP é usado para enviar a mensagem, uma vez que há sempre um corpo.

Então, pela abordagem (amplamente, mas erroneamente) chamada SOAP, você mapeia uma URL para uma função, que é uma ação . A abordagem repousante é: em vez do URL que representa uma acção, deve representar uma coisa (chamado recurso na linguagem repousante). Desde o protocolo HTTP (que nós já estamos usando) suporta verbos, use esses verbos para especificar quais ações para executar na coisa.

Então, com a abordagem sabão (mais uma vez, termo errado), se você tem uma lista de clientes, e você quer ver/atualizar / excluir um, você terá 3 URLS:

• E no corpo da mensagem, passe a identificação do cliente a ler.
• myapp/update-customer e no corpo, passar a identificação do cliente, bem como os novos dados
• myapp/delete-customer e a identificação no corpo

Embora, com a abordagem do resto, você só teria myapp/customers/3 (onde 3 é a identificação de um cliente específico). Para ver os dados do cliente, você carrega no URL com um pedido de GET. Para apagá-lo, o mesmo URL, com um verbo apagar. Para atualizá-lo, novamente, a mesma URL com um verbo POST, e o novo conteúdo no corpo do pedido.