Rest e soap
- 1. CENTRO UNIVERSITÁRIO DO TRIÂNGULO INSTITUTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE CIÊNCIA DA COMPUTAÇÃO REST E SOAP Aluno : Anderson da Silva Professor: Vinícius de Paula Disciplina: PSDC – Programação de Sistemas Distribuídos e Concorrência. Uberlândia, 22 de Junho de 2014.
- 2. REST E SOAP Anderson da Silva Trabalho apresentado no Curso de Ciência da Computação do Centro Universitário do Triângulo - Unitri a ser avaliado na disciplina de PSDC – Programação de Sistemas Distribuídos e Concorrência. Uberlândia, 22 de Junho de 2014.
- 3. REST e SOAP Desenvolvedores web têm uma grande quantidade de tecnologias que podem escolher, de ferramentas para acesso simples a bancos de dados, integração com serviços em middleware, a softwares do lado do cliente. A quantidade de opções em si já é um desafio, e escolher uma abordagem específica para construir partes de um aplicativo web exacerba o problema. Neste breve artigo, vamos nos concentrar em uma dessas escolhas: SOAP ou REST. Ambas possuem vantagens e desvantagens e fica na mão do desenvolvedor determinar a melhor abordagem para cada caso em particular. A maioria dos desenvolvedores tem exposto seus serviços utilizando REST, que faz uso de um padrão de URI (Uniform Resource Identifier), fazendo uma chamada para um serviço web como em: http://www.minhaempresa.com.br/programa/metodo?Parâmetros=xx O REST é simples de entender e pode ser adotado em praticamente qualquer cliente ou servidor com suporte a HTTP/HTTPS. Os desenvolvedores que o utilizam citam, como principais vantagens a facilidade no desenvolvimento, o aproveitamento da infraestrutura web existente e um esforço de aprendizado pequeno. Por outro lado, o SOAP, avô das interfaces de serviços web, não deixará de ser usado tão cedo. Com o SOAP v 1.2, muitas das deficiências percebidas nessa tecnologia foram corrigidas e aumentou a facilidade de uso. Além disso, a sigla SOAP deixou de representar "Simple Object Access Protocol". Na especificação 1.2 da W3C, SOAP é apenas o nome da especificação. Utilizar o SOAP 1.2 traz uma carga adicional não encontrada ao usar REST, mas há também vantagens. Primeiramente o SOAP é baseado em XML, de três formas: o envelope, que define o conteúdo da mensagem e informa como processá-la; um conjunto de regras de codificação para os tipos de dados; e o layout para os procedimentos de chamadas e respostas. Esse "envelope" é enviado por meio de (por exemplo) HTTP/HTTPS. E uma RPC (Remote Procedure Call) é executada, e o envelope retorna com as informações do documento XML formatado. Uma das vantagens do SOAP é o uso de um método de transporte "genérico". Enquanto que o REST faz uso de HTTP/HTTPS, o SOAP pode usar qualquer meio de transporte existente para enviar sua requisição, desde SMTP até mesmo JMS (Java Messaging Service). No entanto, uma desvantagem percebida no uso de XML é a sua natureza prolixa e o tempo necessário para analisar o resultado apresentado. A boa notícia para os desenvolvedores web é que ambas as tecnologias são muito viáveis no mercado atual. Ambos REST e o SOAP conseguem resolver um grande número de problemas e desafios na web, e em muitos casos tanto um como o outro podem ser utilizados para fazer o que querem os desenvolvedores.
- 4. Mas uma história não contada é que ambas as tecnologias podem ser misturadas e combinadas. O REST é fácil de entender e extremamente acessível porém faltam padrões, e a tecnologia é considerada apenas uma abordagem arquitetural. Em comparação, o SOAP é um padrão da indústria, com protocolos bem definidos e um conjunto de regras bem estabelecidas. Pode-se afirmar, então, que casos onde o REST funciona bem são: Situações em que há limitação de recursos e de largura de banda: A estrutura de retorno é em qualquer formato definido pelo desenvolvedor e qualquer navegador pode ser usado. Isso porque a abordagem REST usa o padrão de chamadas GET, PUT, POST e DELETE. O REST também pode usar objetos XMLHttpRequest (a base do velho AJAX) que a maioria dos navegadores modernos suporta. Operações totalmente sem-estado: se uma operação precisa ser continuada, o REST não será a melhor opção. No entanto, se forem necessárias operações de CRUD stateless (Criar, Ler, Atualizar e Excluir), o REST seria a melhor alternativa. Situações que exigem cache: se a informação pode ser armazenada em cache, devido à natureza da operação stateless do REST, esse seria um cenário adequado para a tecnologia. Essas três situações abrangem muitas soluções. Então por que ainda precisamos considerar o uso do SOAP? Mais uma vez, o SOAP é bastante maduro e bem definido e vem com uma especificação completa. Já a abordagem REST é apenas isso: uma abordagem. Está totalmente aberta. Por isso ao se encontrar uma das situações abaixo, o SOAP pode ser uma ótima solução: Processamento e chamada assíncronos: se o aplicativo precisa de um nível garantido de confiabilidade e segurança para a troca de mensagens, então o SOAP 1.2 oferece padrões adicionais para esse tipo de operação como por exemplo o WSRM (WS- Reliable Messaging). Contratos formais: se ambos os lados (fornecedor e consumidor) têm que concordar com o formato de intercâmbio de dados, então o SOAP 1.2 fornece especificações rígidas para esse tipo de interação. Operações stateful: para o caso de o aplicativo precisar de informação contextual e gerenciamento de estado com coordenação e segurança, o SOAP 1.2 possui uma especificação adicional em sua estrutura que apoia essa necessidade (segurança, transações, coordenação etc.). Comparativamente, usar o REST exigiria que os desenvolvedores construíssem uma solução personalizada. Como se vê, cada uma das abordagens tem sua utilidade. Ambas têm problemas nos quesitos de segurança, camadas de transporte etc.; mas ambas podem realizar o trabalho necessário e trazem sua contribuição para o desenvolvimento de aplicações web. Portanto, a melhor abordagem é a flexibilidade, pois não importa qual seja o problema, no mundo de hoje do desenvolvimento web, conta-se com excelentes resultados ao fazer uso de um desses padrões.