Alguém pode explicar o que é REST e o que é SOAP em inglês simples? E como os serviços da Web funcionam?
Alguém pode explicar o que é REST e o que é SOAP em inglês simples? E como os serviços da Web funcionam?
Respostas:
SOAP - "Protocolo de acesso a objetos simples"
SOAP é um método de transferência de mensagens ou pequenas quantidades de informação pela Internet. As mensagens SOAP são formatadas em XML e normalmente são enviadas usando HTTP (protocolo de transferência de hipertexto).
Resto - Transferência representacional do estado
O descanso é uma maneira simples de enviar e receber dados entre cliente e servidor e não possui muitos padrões definidos. Você pode enviar e receber dados como JSON, XML ou mesmo texto sem formatação. É leve comparado com o sabão.
Ambos os métodos são usados por muitos dos grandes players. É uma questão de preferência. Minha preferência é REST, porque é mais simples de usar e entender.
Protocolo Simples de Acesso a Objetos (SOAP):
Transferência de estado representacional (REST):
Existem intermináveis debates sobre REST vs SOAP no google .
O meu favorito é este . Atualização 27 de novembro de 2013: O site de Paul Prescod parece ter ficado offline e este artigo não está mais disponível, embora possam ser encontradas cópias na Wayback Machine ou como um PDF no CiteSeerX .
DESCANSAR
Entendo que a principal idéia do REST é extremamente simples. Utilizamos navegadores da web há anos e vimos como são fáceis, flexíveis, com desempenho, etc. Sites HTML usam hiperlinks e formulários como o principal meio de interação do usuário. Seu principal objetivo é permitir que nós, clientes, conheçamos apenas os links que podemos usar no estado atual . E o REST simplesmente diz 'por que não usar os mesmos princípios para conduzir computadores em vez de clientes humanos através de nosso aplicativo?' Combine isso com o poder da infraestrutura da WWW e você obterá uma ferramenta essencial para criar ótimos aplicativos distribuídos.
Outra explicação possível é para pessoas que pensam matematicamente. Cada aplicativo é basicamente uma máquina de estado com ações de lógica de negócios sendo transições de estado. A idéia do REST é mapear cada transição em alguma solicitação para um recurso e fornecer aos clientes links representando as transições disponíveis no estado atual. Assim, ele modela a máquina de estado por meio de representações e links. É por isso que se chama REpresentational State Transfer.
É bastante surpreendente que todas as respostas pareçam se concentrar no formato da mensagem ou no uso de verbos HTTP. De fato, o formato da mensagem não importa, o REST pode usar qualquer um, desde que o desenvolvedor do serviço o documente. Os verbos HTTP apenas tornam um serviço um serviço CRUD, mas ainda não RESTful. O que realmente transforma um serviço em um serviço REST são os hiperlinks (também conhecidos como controles de hipermídia) incorporados nas respostas do servidor, juntamente com os dados, e sua quantidade deve ser suficiente para qualquer cliente escolher a próxima ação desses links.
Infelizmente, é bastante difícil encontrar informações corretas sobre o REST na Web, exceto a tese de Roy Fielding . (Foi ele quem derivou o REST). Eu recomendaria o livro 'REST in Practice' , pois fornece um tutorial passo a passo abrangente sobre como evoluir do SOAP para o REST.
SABONETE
Essa é uma das formas possíveis do estilo de arquitetura RPC (chamada de procedimento remoto). Em essência, é apenas uma tecnologia que permite aos clientes chamar métodos de servidor por meio de limites de serviço (rede, processos, etc.) como se estivessem chamando métodos locais. Obviamente, ele realmente difere de chamar métodos locais em velocidade, confiabilidade e assim por diante, mas a idéia é simples.
Comparado
Os detalhes como protocolos de transporte, formatos de mensagens, xsd, wsdl etc. não importam ao comparar qualquer forma de RPC para REST. A principal diferença é que um serviço RPC reinventa a bicicleta projetando seu próprio protocolo de aplicativo na API RPC com a semântica que apenas ele conhece. Portanto, todos os clientes precisam entender esse protocolo antes de usar o serviço, e nenhuma infraestrutura genérica como caches pode ser criada devido à semântica proprietária de todas as solicitações. Além disso, as APIs de RPC não sugerem quais ações são permitidas no estado atual; isso deve ser derivado de documentação adicional. O REST, por outro lado, implica o uso de interfaces uniformes para permitir que vários clientes entendam a semântica da API e os controles (links) da hipermídia para destacar as opções disponíveis em cada estado. Portanto,
De certa forma, o SOAP (como qualquer outro RPC) é uma tentativa de passar por um limite de serviço tratando a mídia de conexão como uma caixa preta capaz de transmitir apenas mensagens. O REST é uma decisão de reconhecer que a Web é um enorme sistema de informações distribuídas, de aceitar o mundo como está e aprender a dominá-lo em vez de lutar contra ele.
O SOAP parece ótimo para APIs de rede interna, quando você controla o servidor e os clientes e enquanto as interações não são muito complexas. É mais natural para os desenvolvedores usá-lo. No entanto, para uma API pública usada por muitas partes independentes, é complexa e grande, o REST deve se encaixar melhor. Mas essa última comparação é muito confusa.
Atualizar
Minha experiência mostrou inesperadamente que o desenvolvimento do REST é mais difícil que o SOAP. Pelo menos para o .NET. Embora existam excelentes estruturas como a API da Web do ASP.NET, não há ferramentas que gerariam automaticamente o proxy do lado do cliente. Nada como 'Adicionar referência de serviço da Web' ou 'Adicionar referência de serviço do WCF'. É preciso escrever todos os códigos de serialização e de consulta de serviço manualmente. E cara, isso é muito código clichê. Acho que o desenvolvimento REST precisa de algo semelhante ao WSDL e implementação de ferramentas para cada plataforma de desenvolvimento. De fato, parece haver uma boa base: WADL ou WSDL 2.0 , mas nenhum dos padrões parece ser bem suportado.
Atualização (janeiro de 2016)
Acontece que agora existe uma grande variedade de ferramentas para definição da API REST. Minha preferência pessoal é atualmente RAML .
Como funcionam os serviços da Web
Bem, essa é uma pergunta muito ampla, porque depende da arquitetura e tecnologia usada no serviço da web específico. Mas, em geral, um serviço da Web é simplesmente um aplicativo na Web que pode aceitar solicitações de clientes e retornar respostas. Ele é exposto à Web, portanto, é um serviço da Web e normalmente está disponível 24/7, por isso é um serviço . Obviamente, ele resolve algum problema (caso contrário, por que alguém usaria um serviço da Web) para seus clientes.
Esta é a explicação mais simples que você encontrará.
Este artigo leva a narrativa de marido para esposa, onde o marido explica à esposa sobre o REST, em termos puramente leigos. Leitura obrigatória!
como eu expliquei resto da minha esposa (link original)
como eu expliquei resto da minha esposa (19/07/2013)
SOAP - Simple Object Access Protocol é um protocolo !
REST - REpresentational State Transfer é um estilo arquitetônico !
SOAP
é um protocolo XML usado para transferir mensagens, geralmente por HTTP
REST
e sem dúvida nãoSOAP
são mutuamente exclusivos. Uma arquitetura RESTful pode usar ou ou algum outro protocolo de comunicação. é otimizado para a web e, portanto, é uma escolha perfeita. também é o único protocolo discutido no artigo de Roy Fielding. HTTP
SOAP
REST
HTTP
HTTP
Embora REST e SOAP são claramente muito diferente, a questão se acender o fato de que REST
e HTTP
são muitas vezes utilizados em conjunto. Isso se deve principalmente à simplicidade do HTTP e ao seu mapeamento muito natural para os princípios RESTful.
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 cliente-servidor em princípio.
Sem Estado
Cada solicitação de cada 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. Discutiremos a representação sem estado em mais detalhes posteriormente.
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 podem ser armazenados 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 postagem no blog REST Design Principals para obter mais detalhes sobre o REST e os marcadores indicados acima.
Eu gosto da resposta de Brian R. Bondy. Eu só queria acrescentar que a Wikipedia fornece uma descrição clara do REST . O artigo o distingue do SOAP.
O REST é uma troca de informações do estado, feita da maneira mais simples possível.
SOAP é um protocolo de mensagens que usa XML.
Um dos principais motivos pelos quais muitas pessoas passaram do SOAP para o REST é que os padrões WS- * (chamados WS splat) associados aos serviços da Web baseados em SOAP são EXTREMAMENTE complicados. Consulte a Wikipedia para obter uma lista das especificações. Cada uma dessas especificações é muito complicada.
EDIT: por algum motivo, os links não estão sendo exibidos corretamente. REST = http://en.wikipedia.org/wiki/REST
WS- * = http://en.wikipedia.org/wiki/WS- *
Os serviços da web SOAP e os serviços da web REST também podem usar o protocolo HTTP e outros protocolos (apenas para mencionar o SOAP pode ser o protocolo subjacente do REST). Vou falar apenas sobre o protocolo HTTP SOAP e REST, porque esse é o uso mais frequente deles.
SOAP (protocolo de acesso a objetos "simples") é um protocolo (e um padrão W3C ). Ele define como criar, enviar e processar mensagens SOAP.
As mensagens SOAP são documentos XML com uma estrutura específica: eles contêm um envelope que contém o cabeçalho e a seção do corpo. O corpo contém os dados reais - queremos enviar - em um formato XML. Existem dois estilos de codificação , mas geralmente escolhemos literal , o que significa que nosso aplicativo ou seu driver SOAP realiza a serialização XML e a desserialização dos dados.
As mensagens SOAP trafegam como mensagens HTTP com o subtipo SOAP + XML MIME. Essas mensagens HTTP podem ser multipartes, portanto, opcionalmente, podemos anexar arquivos a mensagens SOAP.
Obviamente, usamos uma arquitetura cliente-servidor, para que os clientes SOAP enviem solicitações aos serviços da web SOAP e os serviços enviem respostas aos clientes. A maioria dos serviços da web usa um arquivo WSDL para descrever o serviço. O arquivo WSDL contém o Esquema XML (XSD a seguir) dos dados que queremos enviar e a ligação WSDL que define como o serviço da web é vinculado ao protocolo HTTP. tem dois estilos de ligação: RPC e documento. Pela ligação do estilo RPC, o corpo SOAP contém a representação de uma chamada de operação com os parâmetros (solicitações HTTP) ou os valores de retorno (resposta HTTP). Os parâmetros e valores de retorno são validados com relação ao XSD. Pela ligação do estilo do documento, o corpo SOAP contém um documento XML que é validado no XSD. Acho que o estilo de encadernação de documentos é mais adequado para sistemas baseados em eventos, mas nunca usei esse estilo de encadernação. O estilo de ligação RPC é mais prevalente; portanto, a maioria das pessoas usa SOAP para fins XML / RPC por aplicativos distribuídos. Os serviços da web geralmente se encontram pedindo a um servidor UDDI . Servidores UDDI são registros que armazenam a localização dos serviços da web.
Portanto, o - na minha opinião - serviço web SOAP mais prevalente usa o estilo de ligação RPC e o estilo de codificação literal e possui as seguintes propriedades:
REST (transferência de estado representacional) é um estilo de arquitetura descrito na dissertação de Roy Fielding. Não se preocupa com protocolos como o SOAP. Começa com um estilo de arquitetura nulo sem restrições e define as restrições da arquitetura REST uma por uma. As pessoas usam o termo RESTful para serviços da web que atendem a todas as restrições REST, mas, de acordo com Roy Fielding, não existem níveis de REST . Quando um serviço da web não atende a todas as restrições REST, ele não é um serviço da web REST.
Interface uniforme
https://example.com/api/v1/users?offset=50&count=25
. URLs têm alguns especificações, por exemplo, URLs com os mesmos caminhos, mas consultas diferentes não são idênticas ou a parte do caminho deve conter os dados hierárquicos do URL e a parte da consulta deve conter os dados não hierárquicos. Estes são os princípios básicos de como criar URLs pelo REST. Btw. a estrutura da URL importa apenas para os desenvolvedores do serviço, um cliente REST real não se preocupa com ela. Outra pergunta freqüente é o versionamento da API, que é fácil, porque, de acordo com Fielding, a única coisa constante por recurso é a semântica. Se a semântica mudar, você poderá adicionar um novo número de versão. Você pode usar a versão clássica de três números e adicionar apenas o número principal aos URLs (https://example.com/api/v1/
) Portanto, por alterações compatíveis com versões anteriores, nada acontece; por alterações não compatíveis com versões anteriores, você terá uma semântica não compatível com versões anteriores com uma nova raiz de API https://example.com/api/v2/
. Portanto, os clientes antigos não quebram, porque podem usar a https://example.com/api/v1/
semântica antiga.PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}
solicitação em que {name: "Mrs Smith"}
é uma representação JSON do estado do recurso pretendido, em outras palavras: o novo nome. Isso acontece vica-versa, o serviço envia representações de recursos aos clientes para alterar seus estados. Por exemplo, se queremos ler o novo nome, podemos enviar uma GET https://example.com/api/v1/users/1?fields="name"
solicitação de recuperação, que resulta em um200 ok, {name: "Mrs Smith"}
resposta. Para que possamos usar essa representação para alterar o estado do cliente, por exemplo, podemos exibir "Bem-vindo à nossa página, Sra. Smith!" mensagem. Um recurso pode ter muitas representações, dependendo do identificador de recurso (URL) ou do accept
cabeçalho que enviamos com a solicitação. Por exemplo, podemos enviar uma imagem da Sra. Smith (provavelmente não nua) se image/jpeg
for solicitada.Hipermídia como o mecanismo do estado do aplicativo (HATEOAS a seguir) - Hipermídia é um tipo de mídia que pode conter hiperlinks. Pela web, seguimos os links - descritos por um formato hipermídia (geralmente HTML) - para atingir uma meta, em vez de digitar os URLs na barra de endereços. O REST segue o mesmo conceito, as representações enviadas pelo serviço podem conter hiperlinks. Usamos esses hiperlinks para enviar solicitações ao serviço. Com a resposta, obtemos dados (e provavelmente mais links) que podemos usar para criar o novo estado do cliente e assim por diante ... É por isso que a hipermídia é o mecanismo do estado do aplicativo (estado do cliente). Você provavelmente se pergunta como os clientes reconhecem e seguem os hiperlinks? Para os humanos, é bastante simples, lemos o título do link, talvez preencha os campos de entrada e, depois disso, apenas um clique.JSON-LD com Hydra ) ou com soluções específicas para hipermídia (por exemplo, relações de link da IANA e tipos MIME específicos do fornecedor por HAL + JSON ). Existem muitos formatos de hipermídia XML e JSON legíveis por máquina , apenas uma pequena lista deles:
Às vezes é difícil escolher ...
Portanto, um serviço da web REST é muito diferente de um serviço da web SOAP (com estilo de ligação RPC e estilo de codificação literal)
e assim por diante...
Um serviço da web SOAP RPC não atende a todas as restrições REST:
Bem, vou começar com a segunda pergunta: O que são serviços da Web? , por razões óbvias.
Os WebServices são essencialmente peças de lógica (às quais você pode se referir vagamente como um método) que expõem determinadas funcionalidades ou dados. O cliente implementando (tecnicamente falando, consumir é a palavra) só precisa saber quais são os parâmetros que o método aceitará e o tipo de dados que ele retornará (se houver).
O link a seguir explica tudo sobre o REST & SOAP de uma maneira extremamente lúcida.
Se você também quiser saber quando escolher o que (REST ou SOAP), mais um motivo para passar por isso!
SOAP e REST referem-se a maneiras pelas quais diferentes sistemas se comunicam.
O REST faz isso usando técnicas que se assemelham à comunicação que seu navegador possui com servidores da Web: usando GET para solicitar uma página da Web, POSTando nos campos do formulário etc.
O SOAP fornece algo semelhante, mas faz tudo enviando blocos de XML para frente e para trás. Outro componente chave do SOAP é o WSDL, que é um documento XML que descreve quais funções e elementos de dados são suportados. Os WSDLs podem ser usados para "descobrir" programaticamente quais funções são suportadas, bem como para gerar stubs de código de programação.
Eu acho que isso é tão fácil quanto eu posso explicar. Por favor, qualquer pessoa pode me corrigir ou adicionar a isso.
SOAP é um formato de mensagem usado por sistemas desconectados (como na Internet) para trocar informações / dados. Isso acontece com as mensagens XML indo e voltando.
Os serviços da Web transmitem ou recebem mensagens SOAP. Eles funcionam de maneira diferente, dependendo do idioma em que foram escritos.
O problema com o SOAP é que ele está em conflito com os ideais por trás da pilha HTTP. Qualquer middleware deve poder trabalhar com solicitações HTTP sem entender o conteúdo da solicitação ou resposta, mas, por exemplo, um servidor de cache HTTP normal não funcionará com solicitações SOAP sem saber apenas quais partes do conteúdo SOAP são importantes para o armazenamento em cache. O SOAP apenas usa HTTP como invólucro para seu próprio protocolo de comunicação, como um proxy.
SOAP - "Protocolo de acesso a objetos simples"
O SOAP é uma pequena transferência de mensagens ou pequenas quantidades de informações pela Internet. As mensagens SOAP são formatadas em XML e normalmente são enviadas controlando HTTP .
REST - "Transferência de estado representacional"
O REST é um procedimento rudimentar de eventualidade e recebimento de informações entre ventilador e servidor e não possui muitos padrões inequivocamente definidos. Você pode enviar e aceitar informações como JSON , XML ou mesmo texto sem formatação. É leve comparado com o sabão .
Serviços Web baseados em SOAP Em resumo, o modelo de Serviços baseados em SOAP vê o mundo como um ecossistema de pares iguais que não podem se controlar, mas precisam trabalhar juntos honrando contratos publicados. É um modelo válido do mundo real confuso e os contratos baseados em metadados formam a Interface de Serviço SOAP.
ainda podemos associar SOAP a chamadas de procedimento remoto baseadas em XML, mas a tecnologia de serviços Web baseada em SOAP emergiu em um modelo de mensagens flexível e poderoso.
O SOAP assume que todos os sistemas são independentes e nenhum sistema possui conhecimento dos internos de outro e da funcionalidade interna. O máximo que esses sistemas podem fazer é enviar mensagens um para o outro e torcer para que sejam respeitadas. Os sistemas publicam contratos que eles se comprometem a honrar, e outros sistemas confiam nesses contratos para trocar mensagens com eles.
Os contratos entre sistemas são chamados coletivamente de metadados e compreendem descrições de serviço, os padrões de troca de mensagens suportados e as políticas que regem as qualidades de serviço (um serviço pode precisar ser criptografado, entregue com segurança etc.) Uma descrição de serviço, por sua vez, é uma descrição detalhada especificação dos dados (documentos da mensagem) que serão enviados e recebidos pelo sistema. Os documentos são descritos usando uma linguagem de descrição XML como XML Schema Definition. Desde que todos os sistemas honrem seus contratos publicados, eles podem operar e as alterações nas partes internas dos sistemas nunca afetam nenhum outro. Todo sistema é responsável por traduzir suas próprias implementações internas de e para seus contratos
REST - Transferência Representacional do Estado. O protocolo físico é HTTP. Basicamente, REST é que todos os recursos distintos na web são identificáveis exclusivamente por uma URL. Todas as operações que podem ser executadas nesses recursos podem ser descritas por um conjunto limitado de verbos (os verbos "CRUD") que, por sua vez, são mapeados para verbos HTTP.
Os RESTs são muito menos "pesados" que o SOAP.