SOUP e REST

 


        A comunicação entre sistemas e a capacidade de oferecer serviços por meio da internet está se tornando cada vez mais comum. Muitas empresas de software oferecem serviços que podem ser acessados remotamente ou dentro de uma rede e que permitem a comunicação entre um ou mais dispositivos eletrônicos, tornando-os capazes de enviar e processar dados de acordo com sua funcionalidade. Para que essa comunicação ocorra é necessário que os sistemas envolvidos sigam um mesmo formato de transmissão de dados. Por causa disso os web services se tornaram populares, pois permitem que plataformas diferentes (Java, C#, C++, Python) se comuniquem sem grandes esforços.

         Entre as abordagens existentes para a implementação de web services as opções mais comuns encontradas são SOAP e REST. Começaremos por definir o que são e o que significam essas siglas. Ambas definem a maneira como as APIs são criadas. API é uma sigla que provém do inglês Application Programming Interface e trata de um conjunto de rotinas e padrões estabelecidos por um software para utilização de suas funcionalidades por outras aplicações que por sua vez não terão conhecimento algum sobre os detalhes de implementação, mas apenas utilizarão seus serviços.

        O REST (Representational State Transfer) é um conjunto de princípios de arquitetura que foi desenvolvido juntamente com o protocolo HTTP 1.1 e trazendo algumas ideias de como utilizar corretamente os verbos HTTP (GET, POST, PUT, DELETE...) enquanto o SOAP (Simple Object Access Protocol) é um protocolo oficial mantido pela W3C (World Wide Web Consortium) e que teve grande destaque no mercado no início da década de 2000, sendo o padrão mais implementado na época e deixando um legado de sistemas e integrações até hoje.

        O padrão SOUP utiliza XML para a transferência de objetos entre aplicações e HTTP para transporte. O XML segue um padrão definido pelo protocolo e serve para que a partir de um objeto seja possível serializá-lo para XML e depois deserializá-lo de volta para o formato original. Na serialização forma-se a mensagem SOAP, composta pelo objeto denominado envelope SOAP ou SOAP-ENV. Esse envelope é o elemento raiz do documento XML e pode conter declarações de namespaces e atributos adicionais como a definição do estilo de codificação. Além do envelope, o protocolo SOUP pode conter opcionalmente um cabeçalho que carregará informações adicionais, como por exemplo, se a mensagem deve ser processada por um nó intermediário. Por último temos o Body que é obrigatório e contém o payload ou informação que será transportada para o receptor da mensagem. O Body pode ainda conter o elemento opcional Fault, usado para carregar status ou erros retornados pelos receptores ao processarem a mensagem.


        Mas como um cliente de um web service sabe qual o formato dos métodos a serem chamados e quais parâmetros precisam ser passados? Para isso foi criada a WSDL ou Web Services Description Language que é uma linguagem baseada em XML que além de descrever o serviço, especifica como acessá-lo e quais as operações ou métodos disponíveis. Então quando duas empresas que podem ser concorrentes mas que desejam atender um mesmo cliente utilizando web services então a única coisa que precisa ser fornecida é a URL do WSDL. Normalmente o WSDL é encontrado quando acrescentamos “?wsdl” ao final da URL onde o web service está hospedado.

        No caso do REST cada mensagem HTTP contém toda a informação necessária para compreender a requisição. Portanto não é necessário que nem o cliente e nem o servidor gravem nenhum estado das comunicações entre as mensagens. É mais utilizado para APIs públicas e utiliza vários padrões como JSON ou XML. São necessários menos recursos e largura de banda em comparação com o SOAP.

      Com isso podemos entender um pouco mais sobre os dois padrões mais utilizados para comunicação entre softwares e ver sua importância na integração de dados entre as organizações. Embora o REST seja mais utilizado pelas grandes empresas, não podemos diminuir a importância do SOUP que está presente em muitos sistemas ainda hoje operantes.  

Referências

DANTAS, D.C.T. Simple Object Access Protocol. UFRJ - Redes de Computadores II

Disponível em: <https://www.gta.ufrj.br/grad/07_2/daniel/>

Maycon. WSDL: Simplifique a integração de dados via Web Service.

Disponível em: <https://www.devmedia.com.br/wsdl-simplifique-a-integracao-de-dados-via-web-service/30066>

REST - MDN Web Docs 

Disponível em: <https://developer.mozilla.org/pt-BR/docs/Glossary/REST>


Comentários

Postar um comentário

Postagens mais visitadas deste blog

Como utilizar Tag Prefix WinCC Professional

Imagem
Versão do software utilizada: Siemens WinCC TIA Portal V14 SP1 - WinCC Professional - Version V14 SP1 Update 4 Objetivo: Utilizar o tag prefix para mostrar em uma mesma tela parâmetros de informações de diferentes produtos instanciadas em "Picture Window".                 Para este exemplo, vamos considerar uma fábrica de chocolates com 6 diferentes tipos de produtos. Cada produto tem suas respectivas características de: nome, teor de cacau, recheio, quantidade de lotes produzidos. Os valores serão armazenados em tags internas com persistência para que o valor não se perca quando o Runtime for desativado. Criaremos apenas uma tela de exibição que poderá ser instanciada com as informações do chocolate selecionado. Vamos aos passos. Passo 1: Abrir o TIA Portal e criar um novo projeto na opção “Create new project”. O nome escolhido foi WinCC Tutorials. Figura 1 - Tela inicial TIA Portal ...
Leia mais

TUTORIAL: Criando WinCC Tags a partir de documentos de texto utilizando script em Python

Imagem
Imagine que em um projeto no WinCC Professional você precise criar muitas tags para cada um dos componentes do seu sistema SCADA. Agora imagine que essas tags sejam, por exemplo, referentes a diferentes motores e que seguem uma estrutura padrão tal como cada motor possui uma tag de referência, uma tag de input, uma de output, uma referente ao painel onde o motor está ligado, uma tag de descrição e uma tag somando o tempo que o motor esteve ligado.   Dependendo da quantidade de motores, criar essas tags pode ser uma atividade repetitiva que demanda algumas horas. Imagine agora que possui as descrições de cada um dos motores em um documento Word em forma de pequenas tabelas. E se fosse possível apenas selecionar toda a tebela Word, apertar as teclas Ctrl + C aplicar um comando e todas as tags simplesmente aparecessem em uma tabela Excel pronta para ser importada no WinCC? Parece mágica, mas é perfeitamente possível, vai economizar tempo de desenvolvimento e vou mostrar uma forma ...
Leia mais

Utilizando interfaces, inversão de controle e injeção de dependências em programação - Um exemplo em C#

Imagem
          A melhor forma que encontrei para entender e explicar os conceitos de interfaces, inversão de controle e injeção de dependências é através de exemplo. Este exemplo tirei de um curso que pode ser verificado nas referências desta postagem.           O exemplo trata do cálculo de impostos e do valor total cobrado do cliente em uma empresa fictícia de aluguel de veículos. O valor da taxa de imposto varia caso o aluguel seja por dia ou por hora. O valor calculado sempre é arredondado para mais. As entradas que damos ao sistemas são: - data e horário da retirada do veículo - data e horário da devolução do veículo - preço do aluguel por hora - preço do aluguel por dia           Executando a aplicação:             No github , dividi a solução em dois commits diferentes. Um para a solução sem uso de interfaces e outro com o uso da interface. Dado o código e o fun...
Leia mais