Posted on: January 29, 2020 12:18 PM
Posted by: Renato
Views: 1490
A velha pergunta: qual é a diferença entre as APIs SOAP e REST e qual é a certa para o meu projeto?
Só porque nosso nome é SoapUI, não significa que também não sabemos do que estamos falando quando se trata de explicar APIs e serviços da Web RESTful.
Portanto, se você estiver procurando por um recurso que forneça uma resposta para essa pergunta antiga, você veio ao lugar certo. Também abordaremos exemplos de código, bem como desafios e críticas de cada escolha.
Sugerimos começar com o vídeo como uma introdução a este tópico ou para aqueles que são apenas aprendizes visuais.
SOAP vs REST
O termo API da Web geralmente se refere aos dois lados dos sistemas de computadores que se comunicam por uma rede: os serviços da API oferecidos por um servidor, bem como a API oferecida pelo cliente, como um navegador da Web.
A parte do servidor da API da web é uma interface programática para um sistema de mensagens de solicitação-resposta definido e geralmente é chamada de serviço da web. Existem vários modelos de design para serviços da web, mas os dois mais dominantes são SOAP e REST.
O SOAP fornece as seguintes vantagens quando comparado ao REST:
- Independente de idioma, plataforma e transporte (o REST requer o uso de HTTP)
- Funciona bem em ambientes corporativos distribuídos (o REST assume comunicação direta ponto a ponto)
- Padronizado
- Fornece extensibilidade significativa de pré-construção na forma dos padrões WS *
- Tratamento interno de erros
- Automação quando usada com determinados produtos de idiomas
O REST é mais fácil de usar e é mais flexível. Possui as seguintes vantagens quando comparado ao SOAP:
- Usa padrões fáceis de entender, como o swagger e o OpenAPI Specification 3.0
- Menor curva de aprendizado
- Eficiente (SOAP usa XML para todas as mensagens, o REST usa principalmente formatos de mensagens menores, como JSON)
- Rápido (não é necessário processamento extensivo)
- Mais próximo de outras tecnologias da Web na filosofia de design
Como um tutorial da API REST colocou: SOAP é como um envelope enquanto REST é apenas um cartão postal.
Certamente, um cartão postal é mais rápido e mais barato para enviar do que um envelope, mas ainda pode ser embrulhado em outra coisa, até mesmo um envelope.
Você também pode ler um cartão postal, enquanto um envelope executa algumas etapas extras, como abrir ou desembrulhar para acessar o que está dentro.
Esta é apenas a versão do TLDR, continue lendo abaixo para obter mais detalhes sobre os dois formatos. Ou consulte o infográfico SOAP vs REST, se esse for o seu estilo.
SOAP
SOAP - Simple Object Access Protocol - é provavelmente o mais conhecido dos dois modelos.
O SOAP depende muito do XML e, juntamente com os esquemas, define uma estrutura de mensagens com um tipo muito forte.
Toda operação que o serviço fornece é definida explicitamente, juntamente com a estrutura XML da solicitação e resposta para essa operação.
Cada parâmetro de entrada é similarmente definido e vinculado a um tipo: por exemplo, um número inteiro, uma sequência ou outro objeto complexo.
Tudo isso é codificado no idioma WSDL - Web Service Description (ou Definition, em versões posteriores). O WSDL é frequentemente explicado como um contrato entre o provedor e o consumidor do serviço. Em termos de programação, o WSDL pode ser considerado uma assinatura de método para o serviço da web.
Exemplo:
Um exemplo de troca de mensagens é semelhante ao seguinte.
Uma solicitação do cliente:
<br>POST http://www.stgregorioschurchdc.org/cgi/websvccal.cgi HTTP/1.1 Accept-Encoding: gzip,deflate Content-Type: text/xml;charset=UTF-8 SOAPAction: "http://www.stgregorioschurchdc.org/Calendar#easter_date" Content-Length: 479 Host: www.stgregorioschurchdc.org Connection: Keep-Alive User-Agent: Apache-HttpClient/4.1.1 (java 1.5) <?xml version="1.0"?> <soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cal="http://www.stgregorioschurchdc.org/Calendar"> <soapenv:Header/> <soapenv:Body> <cal:easter_date soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <year xsi:type="xsd:short">2014</year> </cal:easter_date> </soapenv:Body> </soapenv:Envelope>
The response from the service:
HTTP/1.1 200 OK Date: Fri, 22 Nov 2013 21:09:44 GMT Server: Apache/2.0.52 (Red Hat) SOAPServer: SOAP::Lite/Perl/0.52 Content-Length: 566 Connection: close Content-Type: text/xml; charset=utf-8 <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <namesp1:easter_dateResponse xmlns:namesp1="http://www.stgregorioschurchdc.org/Calendar"> <s-gensym3 xsi:type="xsd:string">2014/04/20</s-gensym3> </namesp1:easter_dateResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
A partir deste exemplo, podemos ver que a mensagem foi enviada por HTTP. O SOAP é realmente independente do protocolo de transporte subjacente e pode ser enviado por quase qualquer protocolo, como HTTP, SMTP, TCP ou JMS.
Como já foi mencionado, a própria mensagem SOAP deve ser formatada em XML. Como é normal para qualquer documento XML, deve haver um elemento raiz: o Envelope neste caso.
Ele contém dois elementos necessários: o cabeçalho e o corpo. O restante dos elementos nesta mensagem é descrito pelo WSDL.
O WSDL acompanhante que define o serviço acima é semelhante a este (os detalhes não são importantes, mas o documento inteiro é mostrado aqui para garantir a integridade):
<br><?xml version="1.0"?> <definitions xmlns:tns="http://www.stgregorioschurchdc.org/Calendar" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" name="Calendar" targetNamespace="http://www.stgregorioschurchdc.org/Calendar"> <message name="EasterDate"> <part name="year" type="xsd:short"/> </message> <message name="EasterDateResponse"> <part name="date" type="xsd:string"/> </message> <portType name="EasterDateSoapPort"> <operation name="easter_date" parameterOrder="year"> <input message="tns:EasterDate"/> <output message="tns:EasterDateResponse"/> </operation> </portType> <binding name="EasterDateSoapBinding" type="tns:EasterDateSoapPort"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="easter_date"> <soap:operation soapAction="http://www.stgregorioschurchdc.org/Calendar#easter_date"/> <input> <soap:body use="encoded" namespace="http://www.stgregorioschurchdc.org/Calendar" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="encoded" namespace="http://www.stgregorioschurchdc.org/Calendar" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding> <service name="Calendar"> <port name="EasterDateSoapPort" binding="tns:EasterDateSoapBinding"> <soap:address location="http://www.stgregorioschurchdc.org/cgi/websvccal.cgi"/> </port> </service> </definitions>
Observe que todas as partes do corpo da mensagem estão descritas neste documento. Observe também que, mesmo que este documento pretenda ser lido principalmente por um computador, ainda é relativamente fácil para uma pessoa com algum conhecimento em programação seguir.
Experimente um projeto SOAP de exemplo no SoapUI
WSDL
O WSDL define todos os aspectos da mensagem SOAP. Ele é capaz de definir se algum elemento ou atributo pode aparecer várias vezes, se necessário ou opcional, e pode até ditar uma ordem específica na qual os elementos devem aparecer.
É um equívoco comum que o WSDL seja um requisito para um serviço SOAP.
O SOAP foi projetado antes do WSDL e, portanto, o WSDL é opcional. Embora seja significativamente mais difícil fazer interface com um serviço da web que não possui um WSDL.
Por outro lado, se for solicitado a um desenvolvedor que faça interface com um serviço da Web SOAP existente, ele só precisa receber o WSDL, e existem ferramentas que fazem a descoberta de serviço - geram stubs de método com parâmetros apropriados em quase qualquer idioma desse WSDL .
Muitas ferramentas de teste no mercado funcionam da mesma maneira - um testador fornece uma URL para um WSDL e as ferramentas geram todas as chamadas com parâmetros de amostra para todos os métodos disponíveis.
Crítica do SOAP
Embora o WSDL possa parecer uma grande coisa a princípio - ele é auto-documentado e contém quase a imagem completa de tudo o que é necessário para integrar-se a um serviço -, também pode se tornar um fardo.
Lembre-se de que o WSDL é um contrato entre você (o provedor do serviço) e cada um de seus clientes (consumidores do serviço).Mudanças no WSDL também significam mudanças no cliente.
Se você deseja fazer uma alteração em sua API, mesmo algo tão pequeno quanto adicionar um parâmetro opcional, o WSDL deve mudar. E as alterações no WSDL também significam alterações no cliente - todos os seus consumidores devem recompilar o aplicativo cliente contra esse novo WSDL.
Essa pequena mudança aumenta muito o fardo para as equipes de desenvolvimento (nos dois lados da comunicação), bem como para as equipes de teste. Por esse motivo, o WSDL é visto como um bloqueio de versão e a maioria dos provedores é muito resistente a atualizar sua API.
Além disso, enquanto o SOAP oferece alguma flexibilidade interessante, como a capacidade de ser transmitida por qualquer protocolo de transporte, ninguém realmente aproveitou a maioria deles.
Graças à evolução da Internet, tudo o que importa passa por HTTP.
Existem novos avanços, mas a maioria deles está sendo prejudicada pelos roteadores de infraestrutura que se recusam a rotear o tráfego HTTP não padrão. Basta considerar: há quanto tempo o mundo tenta migrar para o IPv6?Definitivamente, é necessário um modelo mais leve e flexível [que SOAP].
Qualquer situação em que o tamanho da mensagem transmitida não importe ou onde você controla tudo de ponta a ponta, o SOAP é quase sempre a melhor resposta.
Isso se aplica principalmente à comunicação direta de servidor para servidor, geralmente usada para comunicação interna apenas dentro dos limites de uma empresa.
No entanto, existe a necessidade de um mundo em que quase todas as pessoas no planeta tenham vários dispositivos de baixa memória e baixo poder de processamento conectados a vários serviços o tempo todo, definitivamente é necessário um modelo mais leve e flexível.
Listagem 1. Exemplo de um envelope SOAP que transporta um objeto com o nome "RevistaNome".
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
</soap:Header>
<soap:Body>
<m:GetRevista xmlns:m="http://www.example.org/revista">
<m:RevistaNome>Java Magazine</m:ResvistaNome>
</m:GetRevista>
</soap:Body>
</soap:Envelope>
REST
O REST - REpresentational State Transfer - está rapidamente se tornando o modelo de design preferido para APIs públicas (você pode aprender muito mais sobre o REST e como testá-las neste REST 101: Guia para iniciantes no uso e teste de APIs RESTful Ebook ).
REST significa Representational State Transfer. É um estilo de arquitetura de software que se baseia em um protocolo de comunicações sem estado, mais comumente em HTTP. O REST estrutura dados em XML, YAML ou qualquer outro formato legível por máquina, mas geralmente o JSON é mais amplamente usado. O REST segue o paradigma de programação orientado a objetos do substantivo-verbo. O REST é muito orientado a dados, comparado ao SOAP, que é fortemente orientado a funções. Você pode ver as pessoas se referindo a elas como APIs RESTful ou serviços Web RESTful. Eles significam a mesma coisa e podem ser intercambiáveis.
Não há padrão para o formato de descrição dos serviços REST (você pode importar seu serviço REST no SoapUI usando arquivos WADL). O SoapUI Pro suporta os formatos OpenAPI, Swagger e RAML.
Suas solicitações HTTP REST básicas são: POST, GET, PUT e DELETE. O SoapUI também suporta solicitações HEAD, OPTIONS, TRACE e PATCH. Vejamos um exemplo da API da Swagger Pet Store :
- O envio de uma solicitação GET para / pet / {petId} recuperaria animais de estimação com um ID especificado do banco de dados.
- Enviar uma solicitação POST para / pet / {petId} / uploadImage adicionaria uma nova imagem do animal de estimação.
- O envio de uma solicitação PUT para / pet / {petId} atualizaria os atributos de um animal de estimação existente, identificado por um ID especificado.
- O envio de uma solicitação DELETE para / pet / {petId} excluiria um animal de estimação especificado.
Então, em poucas palavras, aqui está o que cada um desses tipos de solicitação mapeia:
| OBTER | Ler ou recuperar dados |
| POSTAR | Adicionar novos dados |
| COLOCAR | Atualizar dados que já existem |
| EXCLUIR | Remover dados |
Para saber mais sobre solicitações REST e como fazê-las no SoapUI, visite nossa página Trabalhando com Solicitações REST .
Exemplo:
Uma troca de mensagens de amostra pode conter tão pouco quanto isso -
Pedido:
GET http://www.catechizeme.com/catechisms/catechism_for_young_children/daily_question.js HTTP / 1.1 Accept-Encoding: gzip, deflate Host: www.catechizeme.com Conexão: Keep-Alive User-Agent: Apache-HttpClient / 4.1. 1 (java 1.5)
Resposta:
HTTP / 1.1 200 OK
Data: Sex, 22 de novembro de 2013 22:32:22
Servidor GMT : Apache
X-Powered-By: Phusion Passenger (mod_rails / mod_rack) 3.0.17
ETag: "b8a7ef8b4b282a70d1b64ea5e79072df"
X-Runtime: 13
Cache-Control : privado, idade máxima = 0, deve-revalidar
Comprimento do conteúdo: 209
Status: 200
Keep-Alive: timeout = 2, max = 100
Conexão: Keep-Alive
Tipo de conteúdo: js; charset = utf-8
{
"link": "catecismos \ / catecismo_para_jovens \ / perguntas \ / 36",
"catecismo": "Catecismo para crianças pequenas",
"a": "Pecado original.",
"posição": 36,
"q": "
Como já era esperado, esta mensagem foi enviada por HTTP e usou o verbo GET.
Observe também que o URI, que também precisava ser incluído na solicitação SOAP, mas não tinha significado, aqui realmente assume um significado. O corpo da mensagem é significativamente menor; neste exemplo, na verdade não há um.
Um serviço REST também possui um esquema chamado WADL - Web Application Description Language. A WADL da chamada acima ficaria assim:
<? xml version = "1.0"?>
<application xmlns = "http://wadl.dev.java.net/2009/02">
<doc xml: lang = "en" title = "http: // www. catechizeme.com "/>
<resources base =" http://www.catechizeme.com ">
<caminho do recurso =" catecismos / {CATECHISM_NAME} /daily_question.js "id =" Daily_question.js ">
<doc xml: lang = "en" title = "Daily_question.js" />
<param xmlns: xs = "http://www.w3.org/2001/XMLSchema" name = "CATECHISM_NAME" style = "modelo" type = "string" / >
<nome do método = "GET" id = "Daily_question.js">
<doc xml: lang = "en" title = "Daily_question.js" />
<request />
<response status = "200">
<representação mediaType = "json" elemento = "data" />
<representação mediaType = "js; charset = utf-8" elemento = "data" />
</response>
</method>
</resource>
</resources>
</application>
A WADL usa a sintaxe XML para descrever os metadados e as ações disponíveis. Também pode ser escrito para ser tão rigoroso quanto o WSDL: definição de tipos, parâmetros opcionais, etc.
Experimente um exemplo de projeto REST no SoapUI
WADL
A WADL não possui nenhum mecanismo para representar os próprios dados, que é o que deve ser enviado no URI. Isso significa que a WADL é capaz de documentar apenas metade das informações necessárias para interagir com o serviço.
Tomemos, por exemplo, o parâmetro CATECHISM_NAME na amostra acima. A WADL apenas informa onde o parâmetro pertence ao URI e que deve ser uma sequência.
No entanto, se você tivesse que coletar os valores válidos, provavelmente levaria muito tempo. Observe que é possível adicionar um esquema à WADL, para que você possa definir até tipos de variáveis complexas, como enumerações; no entanto, isso é ainda mais raro do que fornecer uma WADL.O WADL é completamente opcional.
Além disso, a WADL é completamente opcional; de fato, é bastante raro que a WADL seja fornecida! Devido à natureza do serviço, para fazer qualquer uso significativo, você quase certamente precisará de documentação adicional.
Crítica do REST
Ter uma área muito pequena e utilizar o padrão HTTP amplamente adotado torna o REST uma opção muito atraente para APIs públicas.
Juntamente com o JSON, o que simplifica bastante a adição de um parâmetro opcional, o torna muito flexível e permite lançamentos frequentes sem afetar seus consumidores.
Indiscutivelmente, a maior desvantagem é a WADL - opcional e sem algumas informações necessárias. Para solucionar essa deficiência, existem várias estruturas disponíveis no mercado que ajudam a documentar e produzir APIs RESTful, como Swagger , RAML ou JSON-home . O Swagger foi doado à Open API Iniative e agora é chamado de OpenAPI (OEA). Vá para o Swagger.io, onde você pode ler mais sobre esse padrão, as especificações e como as ferramentas do Swagger desempenham um papel.
Renato de Oliveira Lucena - 12/2019
Donate to Site
Renato
Developer