Web Services Uma Análise Comparativa

Transcrição

1 Revista das Faculdades Integradas Claretianas N. 5 janeiro/dezembro de 2012 Web Services Uma Análise Comparativa Ricardo Frenedoso Da Silva ricardosilva.hrc@gmail.com Faculdades Integradas Claretianas Pablo Rodrigo Gonçalves prof.pablorodrigo@gmail.com Faculdades Integradas Claretianas Resumo Os Web Services são sistemas de informação que, utilizando um conjunto de tecnologias que são padrões da Internet, permitem a integração entre outros sistemas de informação, através de troca de mensagens. Esse artigo tem o objetivo de introduzir a tecnologia de Web Services, os conceitos, as tecnologias e padrões envolvidos e suas aplicações mais comuns. Além disso, apresentar as duas principais alternativas para o desenvolvimento de Web Services disponíveis atualmente, o protocolo SOAP e o estilo arquiterural REST, fazendo uma análise comparativa entre elas, realçando as situações onde as vantagens e desvantagens de cada uma são mais relevantes. Palavras-chave: Web Services REST SOAP XML JSON - SOA. 1 Introdução No final da década de 90, com a popularização da Internet e do uso dos computadores pessoais, viu-se uma oportunidade na criação de mecanismos de comunicação entre sistemas de informação, que até então permaneciam isolados. Para essa finalidade foi criada a tecnologia de Web Services. De acordo com Kreger (2001), Um Web Service é uma interface que descreve uma coleção de operações que são acessíveis pela rede através de mensagens XML padronizadas. Seu uso permite que plataformas heterogêneas de software e hardware sejam integradas de forma transparente. O W3C (2004) define web services da seguinte maneira: Um Web Service é um sistema de software desenvolvido para permitir interações máquinamáquina através de uma rede. É uma interface descrita para ser consumida por máquinas (WSDL). Outros sistemas interagem com o Web Service através de mensagens SOAP, geralmente enviadas através de HTTP em conjunto com outros padrões relacionados à web (W3C, 2004). Os Web Services permitem que sistemas desenvolvidos em várias linguagens, sendo executados em diversas plataformas, transmitam e recebam informações padronizadas entre si, permitindo uma interação máquina-máquina mais abrangente que qualquer outra tecnologia de computação distribuída existente. Essa independência de protocolo e plataforma é conseguida através da utilização de interfaces. Toda a comunicação é realizada através da chamada de métodos do serviço, e do envio e recebimento de mensagens padronizadas. Dessa forma, os Web Services permitem que as aplicações sejam integradas mais rapidamente, facilmente e com menor custo do que nunca (KREGER, 2001). Permitir que uma aplicação consuma um serviço disponibilizado através de um Web Service sem conhecer os detalhes internos desse serviço cria um encapsulamento que traz inúmeros benefícios, como a reutilização de código e, consequentemente, a simplificação dos sistemas. É possível, por exemplo, utilizar os serviços de geolocalização do Google (Google Maps API) através de seu web service, sem conhecer os detalhes da codificação, estruturas de dados, lógica do processamento, etc. É possível também utilizar Web Services para publicar ou integrar sistemas legados com novos sistemas em desenvolvimento, de forma a reutilizar a base de código e de regras de negócio que já estão em produção, criando novas formas de visualização dos dados. Web services também são utilizados na construção de sistemas multicamadas, arquitetura que divide o 7

2 sistema em vários módulos lógicos, com responsabilidades distintas e com baixo acoplamento entre si, permitindo que uma camada seja alterada ou substituída sem afetar outras partes do sistema. 2 Arquitetura Orientada a Serviços (SOA) O termo SOA (Service Oriented Architecture) surgiu para designar um conjunto de arquiteturas e padrões de desenvolvimento de software focados na disponibilização e consumo de serviços entre aplicativos em uma rede. O W3C (2004) define SOA como um conjunto de componentes que podem ser invocados, e cuja interface pode ser publicada e descoberta.. Cada componente da arquitetura SOA representa um serviço, ou uma funcionalidade específica do sistema. Um serviço pode consumir outro serviço, utilizando uma funcionalidade que já foi implementada, permitindo a criação de serviços mais simples como uma validação de CPF, até serviços mais complexos. O aplicativos consumidores utilizam o serviço sem se preocupar com a sua implementação, apenas acessando uma interface comum que esconde os detalhes do modelo de dados e do processamento realizado. O servidor por outro lado, não se preocupa com quais aplicativos consomem seus serviços. A tecnologia de Web Services é parte importante da arquitetura SOA, e permite que serviços sejam desenvolvidos, publicados, descobertos e consumidos de uma forma simples e robusta. 3 Sistemas multicamadas A divisão em camadas é uma técnica muito utilizada pelos engenheiros de software para implementar um sistema de software complexo (FOWLER, 2002). Separando o sistema em camadas, o entendimento é facilitado, pois cada camada é responsável por prover uma funcionalidade restrita e bem definida. O acoplamento também é reduzido, uma vez que cada camada está acoplada somente à camada imediatamente superior e inferior, provendo serviços para a primeira e consumindo serviços da segunda. Inicialmente os sistemas de gestão empresarial, e vários outros sistemas cujo objetivo fosse armazenar, ler e processar informações em um banco de dados, eram construídos de forma que os códigos da interface visual, das regras de negócio e da persistência no banco de dados eram escritos na mesma unidade de código (arquitetura cliente/servidor). Sendo assim, as camadas de visualização, lógica e persistência estavam fortemente acopladas. Apesar de funcionar bem para pequenos projetos, para sistemas maiores isso se torna um grande problema, pois qualquer alteração em qualquer uma das camadas interfere diretamente nas outras, causando alterações em cascata. Com o uso de Web Services é possível implementar cada camada separadamente, facilitando a manutenção e aumentando a performance geral da aplicação 4 O Protocolo SOAP A integração de um aplicativo cliente com um Web Service deve ocorrer através da troca de mensagens. Para que possa haver uma comunicação entre duas máquinas, é necessário que haja uma conexão física entre elas pela qual os dados irão trafegar, além de um protocolo de comunicação comum, para que ambos os lados consigam interpretar as mensagens recebidas e saibam como formar as mensagens que serão enviadas como resposta. O protocolo SOAP define um padrão para essa troca de mensagens, que são documentos XML especiais. SOAP também especifica uma linguagem para a descrição dos métodos disponibilizados pelo serviço (WSDL), além da especificação de um serviço de descoberta de Web Services (UDDI). Sua especificação foi desenvolvida e publicada pelo W3C (consórcio de empresas, entre elas IBM, Amazon e Microsoft, responsável pela especificação de várias tecnologias da Web). Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

3 SOAP é uma recomendação do W3C, o que significa que é um padrão que já passou por um longo processo de avaliação e testes. SOAP é um framework composto, padronizado e extensível para o empacotamento e troca de mensagens XML (W3C, WSA pag 65). O protocolo SOAP é um protocolo stateless, ou seja, não mantém estado entre as mensagens enviadas e recebidas. Cada mensagem deve conter todas as informações necessárias para que seja processada. SOAP é flexível o suficiente para ser utilizado em aplicações que utilizem o padrão requisição/resposta, requisição/múltiplas respostas, etc. 5 O documento WSDL O documento WSDL (Web Service Description Language) é o contrato estabelecido entre o Web Service e seus clientes. É um documento XML que fornece informações detalhadas a respeito do serviço publicado, necessárias para que os aplicativos cliente consigam consumi-lo. Existem ferramentas que utilizam o WSDL para gerar código de apoio, facilitando o consumo do serviço. Na maioria dos casos, o desenvolvedor não precisa trabalhar diretamente com SOAP, a infraestrutura do SOAP fica em uma camada inferior à da aplicação, facilitando o desenvolvimento. O WSDL da versão 1.1 do SOAP está dividido em 5 seções. A seção types é opcional, e contém definições sobre os tipos de dados utilizados nas chamadas dos métodos. Geralmente essa seção aponta, ou contém, um documento do tipo XSD, que serve para validar a estrutura de um XML. Na seção message são declaradas todas as mensagens que implementam o serviço. Essas mensagens são formadas pelos tipos definidos na seção anterior, ou utilizam-se dos tipos básicos padrões, como String e Integer. A seção porttype reúne as mensagens para formar operações, repetindo várias informações da seção anterior. Cada operação é vinculada a uma mensagem de entrada (input) e saída (output). A seção binding é a seção mais complexa do WSDL. Nessa seção, a definição das operações se torna mais concreta. É definido o protocolo de transporte (HTTP, SMTP, etc), o estilo do serviço (RPC ou Document) e o formato dos dados (literal ou encoded). Por fim, a seção service possui informações como nome e localização real do serviço, os endpoints, nos quais as operações descritas estão disponíveis para acesso. 6 Mensagens SOAP Para requisitar a executação de uma operação, o aplicativo envia um documento XML que contém uma mensagem SOAP. Essa mensagem contém uma estrutura própria e é construída pela biblioteca SOAP do cliente com base na inspeção do WSDL do serviço. Uma mensagem SOAP possui três partes, uma delas sendo opcional: Envelope, Header (opcional) e Body. Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

4 Figura 1 - Estrutura de uma mensagem SOAP (KALIN, 2009) A tag Envelope envolve toda a mensagem, delimitando seu começo e fim, e contém as declarações de namespace. É a tag raiz da mensagem. A seção Header é opcional, e permite que informações adicionais sejam carregadas pela mensagem, até o servidor. Nessa seção podem ser inseridas informações de autenticação, autorização, assinatura digital, etc. O header também é utilizado nas arquiteturas distribuídas baseadas em SOAP, onde a mensagem é processada por vários nós antes de alcançar o destinatário final. Assim, os nós podem ler e alterar os dados do cabeçalho da mensagem, sem alterar seu conteúdo. A seção body contém o corpo da mensagem. Nessa seção é inserido o conteúdo que será entregue ao destinatário final da mensagem. Em uma mensagem de requisição de um serviço, é enviado no corpo da mensagem o nome da operação solicitada, conforme descrito no WSDL, e o valor dos parâmetros, caso haja algum. Na mensagem de retorno do serviço, é enviado o nome da operação, seguido do resultado processado. No final da mensagem há uma seção reservada para o envio de anexos SOAP, que pode ser uma sequência muito longa de caracteres, um arquivo, uma imagem, etc. A mensagem abaixo é um exemplo de requisição SOAP. No corpo da mensagem existe uma tag especificando qual função deve ser executada (getfuncionarios). <soapenv:envelope xmlns:soapenv=" xmlns:web=" <soapenv:header/> <soapenv:body> <web:getfuncionarios/> </soapenv:body> </soapenv:envelope> A próxima mensagem é a resposta da função getfuncionarios requisitada anteriormente. Interno a tag getfuncionariosresponse, o servidor envia uma lista de funcionários, na forma de um documento XML. <S:Envelope xmlns:s=" Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

5 <S:Body> <ns2:getfuncionariosresponse xmlns:ns2=" <return> <datanascimento>20/03/1975</datanascimento> <departamento>ti</departamento> <nome>carlos</nome> <RE>52258</RE> <sobrenome>oliveira</sobrenome> </return> <return> <datanascimento>13/05/1981</datanascimento> <departamento>contabilidade</departamento> <nome>pedro</nome> <RE>33558</RE> <sobrenome>teodoro</sobrenome> </return> <return> <datanascimento>21/10/1978</datanascimento> <departamento>ti</departamento> <nome>jorge</nome> <RE>33665</RE> <sobrenome>pereira</sobrenome> </return> <return> <datanascimento>31/11/1971</datanascimento> <departamento>vendas</departamento> <nome>eduardo</nome> <RE>32155</RE> <sobrenome>pires</sobrenome> </return> </ns2:getfuncionariosresponse> </S:Body> </S:Envelope> 7 O Estilo Arquitetural REST O protocolo SOAP é uma tecnologia viável e com um grande suporte entre as linguagens de programação atuais, porém é consenso entre os especialistas que em alguns aspectos o protocolo SOAP foi projetado em excesso. Esse é um dos motivos pelo qual os Web Services de estilo REST vem ganhando cada vez mais notoriedade entre os desenvolvedores de Web Services. Empresas como Google, Facebook, Twitter e Amazon já disponibilizam Web Services de estilo REST para acesso aos seus serviços. REST significa Representational State Transfer (Transferência de Estado Representacional) e sua especificação foi criada por Roy Fielding em sua dissertação de pós-doutorado, no ano É um estilo híbrido, derivado de vários estilos arquiteturais baseados em rede (FIELDING, 2000). REST não é uma Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

6 tecnologia, nem um protocolo. É um conjunto de princípios que, conforme são implementados no projeto de software, trazem consigo algumas vantagens e restrições. Segundo Fielding (2000), um estilo arquitetural é um conjunto de regras que restringe os papéis/funcionalidades dos elementos arquiteturais e o grau de relacionamento entre esses elementos nas arquiteturas que aplicam esse estilo. Definir estilos de arquitetura de software é um recurso útil, pois permite nomear um conjunto de padrões, técnicas e regras de forma que seja fácil identificá-los, discutir melhoramentos e aplicá-los de forma efetiva no desenvolvimento de projetos de software. O estilo REST foi projetado de forma a utilizar ao máximo a arquitetura da Web existente, tirando o maior proveito possível dos protocolos e tecnologias que já estão em uso desde que a world wide web foi criada. Roy Fielding foi um dos principais autores da especificação do protocolo HTTP (Hyper Text Transfer Protocol), o protocolo de envio e recebimento (solicitação e resposta) de mensagens predominante na web. Quando Fielding nomeou o estilo como Transferência de Estado Representacional, ele se referia ao modo como a Web funciona. A Web é um conjunto de páginas disponíveis na Internet, conectadas entre si através de hyperlinks. Ao acessar uma dessas páginas através de seu endereço (URL, ou URI), o usuário recebe uma representação dessa página. Clicando em um link dessa página, o estado é transferido para a nova página, e o usuário recebe uma nova representação. Um Web Service de estilo REST é formado por um conjunto de Recursos, onde cada recurso possue um identificador único. Esses recursos possuem uma ou mais representações, estão conectados através de hyperlinks, e possuem métodos que permitem a manipulação das suas representações. Os serviços baseados em REST são nomeados pelos desenvolvedores conforme o grau de aderência aos princípios da arquitetura. Web Services que implementam todas as diretrizes do estilo são chamados de Web Services Restful. Os que implementam somente parte das diretrizes, são chamados de Restlike. 7.1 O protocolo HTTP O protocolo HTTP (Hyper Text Transfer Protocol), traduzido como Protocolo para Transferência de Hipertexto, é o protocolo mais antigo e o mais utilizado na Internet. Através dele é possível requisitar uma página web, enviar um formulário preenchido, fazer upload de arquivos, etc. A definição do W3C, no documento de especificação do HTTP, é bem clara: O protocolo de Transferência de Hypertexto é um protocolo de nível de aplicação para sistemas de informação distribuídos, colaborativos e baseados em hipermídia. É um protocolo genérico, stateless, que pode ser usado para diversas finalidades além de seu uso com hypertexto, como servidores de nomes e sistemas de gerenciamento de objetos distribuídos, através da extensão de seus métodos, códigos de erro e cabeçalhos. Um dos recursos do HTTO é a tipagem e a negociação da representação dos dados, permitindo que sistemas o utilizem independentemente dos dados que serão transferidos (W3C, 1999a). É um protocolo baseado na arquitetura requisição-resposta. Para cada requisição que o browser envia para um servidor, há uma resposta. HTTP não é orientado a conexão e não mantém estado entre as chamadas. Isso significa que toda informação necessária para que uma requisição seja processada deve ser passada na própria requisição. Essa abordagem promove uma maior escalabilidade, pois os recursos não ficam alocados no servidor por muito tempo. Uma requisição HTTP consiste em um cabeçalho e, opcionalmente, um corpo. O cabeçalho HTTP é um conjunto de linhas, no formato chave:valor, e é enviado em texto puro. Uma típica requisição HTTP possui o seguinte formato: GET localhost/pagina.html HTTP/1.1 accept:text/html Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

7 user-agent: IE/6.0 if-modified-since: Sat, cookie: user=joao A palavra GET indica o verbo, ou comando, que será utilizado para na requisição. Existem vários verbos na especificação do HTTP, os mais utilizados são: GET: solicitação simples de um recurso ao servidor. POST: solicitação uma gravação em um recurso no servidor. PUT: criar um recurso no servidor. DELETE: requisição para deleção de um recurso. HEAD: Semelhante ao método GET, exceto que o recurso não é transferido para o cliente, apenas uma confirmação de recebimento. Serve para testar a disponibilidade de uma URL. Em seguida temos o domínio, o host para o qual a solicitação será enviada. Ainda na primeira linha do cabeçalho é incluída a versão do protocolo utilizada para a requisição. O parâmetro accept permite que o cliente especifique o formato desejado da resposta. Entre os valores possíveis estão text/xml para receber documentos XML, image/jpeg para imagens, e text/json para repostas utilizando a notação JSON, entre outros. A resposta também possui um cabeçalho e possivelmente um corpo, utilizado para transmitir os dados do processamento realizado. O exemplo a seguir é uma resposta HTTP: HTTP/ Ok date: Sat, 24 Jan :58: content-type: text/html set-cookie: user=fred <html><head><title>título da página</title <body> </body> </html> A primeira linha do cabeçalho de resposta contém, respectivamente, a versão do protocolo e um código de status. Esses códigos são utilizados para informar ao cliente se uma requisição foi processada com sucesso ou se ocorreu algum erro. No caso, o código 200 Ok significa que a requisição foi bem-sucedida. 8 Recursos A noção de recursos é o conceito central do estilo REST. Se traçarmos um paralelo com o mapeamento relacional de um banco de dados, podemos dizer que os recursos em REST equivalem às Entidades do modelo relacional. Recursos são coisas, substantivos, objetos que são disponibilizados pelo serviço. Um recurso é qualquer informação que pode ser nomeada. É um mapeamento conceitual para um conjunto de Entidades, não uma Entidade que corresponde a um mapeamento em um determinado ponto do tempo. (FIELDING, 2000). Podemos considerar como exemplos de recursos o conjunto de alunos de uma sala de aula, um determinado aluno dessa mesma sala, um serviço de previsão do tempo, o acervo histórico da cidade de São Paulo, etc. Ao dizer que um recurso é um mapeamento para uma entidade, e não uma entidade em um determinado ponto no tempo, Fielding quer dizer que os dados, as informações de um determinado recurso, podem variar em função do tempo, mas isso não significa que cada variação se torna um recurso distinto. Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

8 A World Wide Web nada mais é do que uma coleção de recursos, nesse caso documentos HTML, que são referenciados entre si através de hyperlinks. A página do New York Times por exemplo, pode ser considerada um recurso, e pode possuir uma representação diferente quando acessada em diferentes dias e horários. Ao contrário de SOAP, que é por si só um protocolo de envio e recebimento de mensagens, REST não define como as mensagens são enviadas e recebidas. Ao invés disso, ele utiliza o próprio protocolo HTTP. Cada recurso deve possuir um identificador único, que será utilizado como interface para acesso ao recurso. Utilizando-se novamente do protocolo HTTP, um web service REST utiliza URLs para identificar seus recursos. Essa abordagem garante que os identificadores dos recursos sejam únicos globalmente, uma vez que está atrelado a um domínio da web. O mapeamento de Recursos para URLs em serviços de estilo REST são estruturados da seguinte maneira: em um serviço de exemplo que tem a funcionalidade de fornecer uma lista de funcionários, e que está hospedado na máquina local, a URL para acessar tal lista seria por exemplo Nesse contexto, http é o protocolo utilizado, localhost é o domínio onde o serviço está hospedado, meuservico é o nome do Web Service, e funcionarios é o nome do recurso acessado. Uma solicitação HTTP para essa URL retornaria uma lista de funcionários cadastrados no sistema que o serviço expõe. Para acessar os dados de um determinado funcionário, supondo que exista um campo chamado RE (Registro do Empregado), que identifique na base de dados cada funcionário unicamente, esse campo passa a fazer parte da URL, ficando da seguinte forma: onde 2334 é número de RE do funcionário do qual se deseja obter os dados. Caso fosse necessário requisitar a lista de dependentes de um determinado funcionário, a URL do serviço ficaria parecida com Seguindo o mesmo padrão de mapeamento, se o objetivo fosse listar as informações de um determinado dependente, o mapeamento seria onde seria, por exemplo, o número do CPF do dependente, campo que o identificaria unicamente no conjunto. Aqui existe uma diferença substancial entre o protocolo SOAP e o estilo REST. Enquanto o primeiro publica funções (verbos), métodos que podem ser invocados e retornam um resultado, de forma muito parecida com os sistemas RPC de outrora, o segundo publica um conjunto de recursos (substantivos), entidades, que possuem representações que são transferidas entre as chamadas. Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

9 Figura 2 - Exemplo de mapeamento de um recurso em um serviço REST. (KALIN, 2009) 9 Representações De acordo com Fielding (2000), uma representação consiste de dados, metadados para descrever os dados e, quando necessário, metadados para descrever os metadados (geralmente para o propósito de verificar a integridade das mensagens). A representação de um recurso é utilizada para capturar seu estado atual ou indicar seu estado desejado, para que seja possível transferir essa representação entre os componentes envolvidos. São essas representações dos recursos que são transferidas para o cliente do serviço, e não o recurso em si. Elas podem ser exibidas, processadas, e enviadas novamente para o serviço. Cada recurso pode possuir uma ou mais representações. Ao acessar o recurso de listagem de funcionários citado anteriormente, o cliente pode solicitar as informações de um funcionário representadas em um documento XML, em um arquivo CSV (campos separados por vírgula), uma página HTML com os dados já formatados, ou uma imagem, que contenha a foto 3x4 do funcionário. Se um cliente solicitar o recurso sugerindo XML como representação, obteria o seguinte documento: <funcionarios> <funcionario href=" <RE>2334</RE> <nome>josé Carlos de Oliveira</nome> <datanascimento>29/01/1986</datanascimento> </funcionario> </funcionarios> Esse tipo de resposta se parece muito com uma resposta obtida de um Web Service baseado em SOAP. A principal diferença é que o documento SOAP conteria, além dos dados requisitados, informações de controle da mensagem SOAP, aumentando o tamanho da mensagem. 9.1 JSON Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

10 Um documento XML precisa posicionar a informação entre tags personalizadas, que possuem um nome que identifica a informação. Dessa forma, se a informação a ser transmitida for muito variada em termos de número de campos, haverá um aumento considerável no tamanho das mensagens transmitidas (CROCKFORD, 2006). Um dos formatos mais adotados nos serviços de estilo REST é o formato JSON, que é a sigla para JavaScript Object Notation (Notação de Objetos JavaScript). JSON é um formato leve, independente de máquina, baseado em texto, utilizadao para troca de dados e serialização de Objetos. É derivado da declaração literal de objetos da linguagem JavaScript (IETF, 2006). A principal vantagem de JSON sobre XML é o tamanho do arquivo. JSON é muito mais compacto, e ainda consegue ser autodescritivo, utilizando uma notação de pares chave/valor para descrever os campos. Com JSON é possível representar 4 tipos primitivos: números, strings, booleanos e null; e dois tipos estruturados: array e objeto. Abaixo está um exemplo de um objeto funcionário serializado utilizando a notação JSON: { "funcionario": { "RE": 2334, "nome": "Jose Carlos", "sobrenome": "Oliveira", "departamento": "Produção", "ativo": true, "datanascimento": " " } } 9.2 Hipermídia O conceito de hipermídia está diretamente relacionado aos conceitos de Recurso e Representação. É através dos hyperlinks que se torna possível descobrir e requisitar as representações dos diversos recursos disponíveis em um serviço de estilo REST. Um link, também citado como Web Link ou hyperlink, é uma conexão entre um recurso da Web e outro e, apesar de ser um conceito simples, é uma das principais características responsáveis pelo sucesso da Web (W3C, 1999b). Esse é um aspecto que diferencia o estilo REST da maioria das arquiteturas de sistemas distribuídos, onde os dados são encapsulados e ocultados pelos componentes de processamento. Em um sistema baseado em hipermidia, quando um link é acessado são os dados que se movem de uma localização a outra. (FIELDING, 2000). Ao acessar uma página na Web, essa página é renderizada no browser do usuário, e pode conter diversos recursos, como textos, figuras, animações, e hyperlinks, que quando clicados, direcionam o usuário para outra página, outro recurso. No estilo REST, os hyperlinks possuem exatamente a mesma função que possuem na Web: conectar um recurso ao outro. Isso permite que, uma vez que o aplicativo que está consumindo o serviço tenha acesso à representação de um recurso, essa representação contenha, além dos dados do estado atual do recurso, links para recursos relacionados, ou para outras representações do mesmo recurso. Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

11 Os links para os recursos relacionados são incluídos na representação do recurso. Utilizando o exemplo do capítulo anterior, ao requisitar uma lista de funcionários, a representação poderia conter apenas informações básicas sobre cada funcionário, e um link para a URL onde seria possível obter uma representação completa de cada registro. 9.3 Verbos HTTP aplicados aos recursos Em um Web Service de estilo REST, os recursos disponibilizados são substantivos, pois representam algum objeto, seja ele concreto ou abstrato. Sendo assim, para executar ações nesses substantivos é necessária a aplicação de verbos, como ocorre nos diversos idiomas falados no mundo. Nos idiomas, alguns verbos são específicos e só podem ser utilizados por um conjunto restrito de substantivos. Sentenças como acelerar um lápis ou navegar um carro não fazem sentido. Por outro lado, existem alguns verbos que podem ser aplicados a praticamente todos os substantivos, como pegar, criar e colocar. REST utiliza os verbos padrão existentes no protocolo HTTP para permitir que operações sejam realizadas sobre os seus recursos. Conforme afirma Kalin(2009), no núcleo da arquitetura REST está a noção de que o HTTP, apesar da palavra transporte em seu nome, é uma API, e não apenas um protocolo de transporte. Fielding nomeia essa característica de Interface Uniforme. Utilizando os verbos padrão do HTTP, cada recurso pode ser acessado e manipulado através da mesma interface. Mesmo que os métodos possuam significados diferentes quando aplicados a recursos diferentes, isso não depende de uma implementação específica, apenas a semântica da operação é alterada, a sintaxe permanece a mesma. Seguindo esse raciocínio e aproveitando a estrutura do protocolo HTTP existente, o estilo REST utiliza os verbos HTTP como operações sobre os recursos. Cada verbo padrão é mapeado para uma ação específica, conforme o seguinte padrão: O verbo GET é utilizado para requisitar uma representação do recurso. No cabeçalho da requisição, mais especificamente no parâmetro accept, o requisitante sugere o formato desejado da representação. POST é usado para criar um novo recurso, ou executar uma operação. Os dados do novo recurso são enviados no corpo da requisição. O verbo PUT é usado para atualizar um recurso existente. Novamente, os dados alterados do recurso são enviados na requisição. Por fim, o verbo DELETE é utilizado para apagar um recurso. Esse é um grande diferencial entre SOAP e REST. Por ser um protocolo totalmente independente, SOAP ignora as funcionalidades do HTTP, e precisa exportar cada funcionalidade como um novo método. Além disso, uma mensagem SOAP é enviada geralmente por HTTP, que também serve como protocolo de transporte, criando uma redundância desnecessária, ao encapsular um protocolo dentro de outro. Utilizando essa abordagem, os serviços REST se aproveitam da estrutura pronta do HTTP, e torna possível mapear qualquer ação que esteja disponível em um recurso, ou em um conjunto de recursos. 10 Conclusão Decidir quais tecnologias utilizar em novos projetos de software está entre as decisões mais difíceis da equipe de desenvolvimento, e possui influência direta no andamento do projeto, sendo determinante para seu sucesso ou fracasso. SOAP é o padrão estabelecido de mercado e tem o apoio de empresas que estão na vanguarda da tecnologia de computação, como Oracle, IBM e Microsoft. Possui mais ferramentas de apoio ao desenvolvedor e Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

12 várias extensões que permitem a adição de funcionalidades ao protocolo, como criptografia das mensagens, autenticação e autorização de usuários, mensagens assíncronas, etc. Por outro lado, é um protocolo extenso, com muitos detalhes, e praticamente impossível de se trabalhar sem apoio de ferramentas auxiliares. Ao utilizar a estrutura da web existente, o estilo REST leva vantagem em diversos aspectos, como diminuição do tráfego na rede, criação de APIs mais intuitivas e a utilização de uma interface única. De fato, nenhuma tecnologia irá substituir a outra, pelo menos não a médio prazo. Cada abordagem apresenta situações onde se encaixam melhor e problemas que solucionam de forma mais elegante. Cabe ao arquiteto de software analisar detalhadamente cada requisito da aplicação a ser desenvolvida, e comparar com as opções disponíveis, de forma a tomar a melhor decisão possível. 11 Referências Bibliográficas CROCKFORD, D. JSON: The Fat-Free Alternative to XML Disponível em Acesso em Novembro FIELDING, Roy Thomas. Architetural Styles and the Design of Netword-based Software Architetures Dissertação (Doutorado em Filosofia da Computação). Universidade da Califórnia. Irvine. FOWLER et al. Patterns of Enterprise Application Architecture Addison Wesley. 560p. IETF. The application/json Media Type for JavaScript Object Notation (JSON) Disponível em Acesso em Novembro de KALIN, Martin. Java Web Services: Up and Running. 1st Edition O Reilly Media, Inc. 336p. (tradução nossa). KREGER, Heather. Web Services Conceptual Architecture (WSCA 1.0) IBM Software Group. Disponível em Acesso em: 01/05/2011. SUDA, Brian. SOAP Web Services University of Edinburgh. TANENBAUM, A. S.; STEEN, M. V. Distributed Systems: Principles and Paradigms. Pearson Prentice Hall, UFCG. Introdução e Motivação: Arquiteturas em N Camadas Universidade Federal de Campina Grande. Disponível em: Acesso em 18/11/2011. W3C. HTML 4.01 Specification. 1999a.Disponível em Acesso em Novembro W3C. Hypertext Transfer Protocol HTTP/ b. Disponível em Acesso em 17/11/2011. W3C. Web Services Architecture Disponível em Acesso em Agosto Revista das Faculdades Integradas Claretianas Nº5 janeiro/dezembro de

13 Revista das Faculdades Integradas Claretianas Nº4 janeiro/dezembro de