Contratos de serviços REST com WADL

Transcrição

1 Contratos de serviços REST com WADL André Luiz Pires Silva & Rodrigo Pimenta Carvalho Abstract Web services are increasingly present in the contemporary information systems scenario, working in different contexts, from large companies that need to integrate their sectors, to everyday situations such as posts on social networking websites by mobile phone. REST (Representational State Transfer) is one of the options for implementing web services that offers attractions such as speed and simplicity. This article describes the WADL (Web Application Description Language) and its importance for REST services documentation, proposing that such language should be used as a standard to describe these services. Index Terms REST, WADL, web service contract. Resumo Os web services estão cada vez mais presentes no cenário de sistemas de informações contemporâneo, atuando em diversos contextos, desde em grandes empresas que necessitam integrar seus setores até em situações cotidianas como em postagens em redes sociais pelo celular. REST (Representational State Transfer) é uma das opções para implementação de web services que possui atrativos como velocidade e simplicidade. Este artigo descreve a WADL (Web Application Description Language) e sua importância para documentação de serviços REST, propondo que esta linguagem seja tomada como padrão para descrição dos mesmos. Palavras chave -Contrato de web service, REST, WADL. I. INTRODUÇÃO Os web services são módulos de softwares que possibilitam a comunicação entre sistemas diferentes pela WEB, independentemente de suas localizações ou tecnologias de implementação, para troca de informações e execução de rotinas programadas. Com a expansão dos sistemas distribuídos e a necessidade de as empresas otimizarem seus processos, integrando informações de diversos setores, os web services tornaram-se peças fundamentais no atual contexto de sistemas de informações. Dentre as atuais alternativas para desenvolvimento de web services existentes destacam-se as implementações baseadas no protocolo Simple Object Access Protocol (SOAP) [1] ou na arquitetura Representational State Transfer (REST) [2]. Neste artigo, os web services baseados em SOAP serão referenciados como serviços SOAP, e os web services baseados em REST, como serviços REST. Embora os serviços SOAP e os serviços REST compartilhem do mesmo propósito de possibilitar integração e comunicação entre sistemas, estas tecnologias possuem Trabalho de Conclusão de Curso apresentado ao Instituto Nacional de Telecomunicações como parte dos requisitos para a obtenção do Certificado de Pós-Graduação em Desenvolvimento em SOA com Cloud Computing e Conectividade. Orientador: Prof. Rodrigo Pimenta Carvalho. Trabalho aprovado em junho/2015. diferenças técnicas e de design que fazem com que a decisão da melhor alternativa a ser empregada num projeto dependa dos requisitos de cada caso. Por exemplo, os serviços SOAP podem ser considerados soluções adequadas para casos que demandem validações complexas de dado ou funcionalidades avançadas, como sequenciamentos de mensagens e controle de transação. Por outro lado, os serviços REST podem ser apropriados para casos que priorizem a simplicidade na comunicação e a economia de bytes na transmissão da informação, características estas geralmente encontradas em aplicações para dispositivos móveis. Os web services implementados em REST podem ser descritos computacionalmente através de interfaces construídas no formato extensible Markup Language (XML) [3], assim como em serviços SOAP usando a Web Services Description Language (WSDL) [4]. Entretanto, para o caso específico de serviços REST, existe a linguagem Web Application Description Language (WADL) [5], também escrita em XML, que segue uma gramática bem apropriada para a descrição das interfaces dos mesmos. Desta forma, a WADL pode ser aplicada como contrato de serviços REST. De fato, como se perceberá mais adiante, há inúmeras vantagens em definir tecnicamente um serviço REST com contratos WADL, sendo elas suficientes para que a WADL seja então tomada como padrão na definição de tais contratos. E é devido às vantagens e facilidades demonstradas neste artigo que se deve usar a WADL definitivamente como padrão em descrição de interface de serviço REST, perfazendo os contratos necessários. Ao final serão apresentados exemplos da utilização de contratos WADL em ferramentas de desenvolvimento de web services que podem auxiliar o trabalho de implementação e testes de serviços, reforçando a validade da proposta de padronização de contratos de serviços REST através da WADL. Para o bom entendimento da proposta deste artigo, o capítulo II mostra o que são os serviços REST, dá exemplos de mensagens nessa tecnologia e mostra uma vantagem de se usar REST em situações específicas. Em seguida, o capítulo III explica o que são contratos de serviços e cita a WADL como uma opção para tal. No capítulo IV, a linguagem WADL é explicada, sendo também mostrado um exemplo de como especificar e usar um dado serviço através de contrato com essa tecnologia. O próximo capítulo mostra como pode ser testado um serviço com WADL e termina de apresentar, complementando o capítulo anterior, um conjunto de vantagens de se usar contratos de serviços em WADL. No capítulo VI vê-se um conjunto de ferramentas que facilitam a manipulação de contratos WADL, o que constitui mais um benefício inerente dessa tecnologia. Finalmente, no capítulo VII encontra-se a conclusão sobre a vantagem da proposta contida neste artigo.

2 II. SERVIÇOS REST REST é uma definição de princípios arquiteturais para desenvolvimento de serviços focados em endereçamento de recursos. Estes serviços são disponibilizados pelo protocolo Hypertext Transfer Protocol (HTTP) [6], sendo portanto acessíveis a diversos clientes independentemente da linguagem de programação ou plataforma. Os serviços REST têm-se difundido pela Internet e são adotados por grandes empresas como Yahoo, Google e Facebook [7]. Dentre as vantagens da arquitetura REST que impulsionam a sua adoção destacam-se a economia em transmissão de dados (e o consequente aumento da velocidade) e a simplicidade de utilização em comparação com os serviços SOAP. Para ilustrar melhor as diferenças entre os serviços REST e os serviços SOAP, especificamente sobre a economia de dados relacionada à troca de mensagens, estão demonstrados a seguir dois exemplos fictícios de utilização de serviços para consulta de nome de cidade por código postal. Na figura 1 pode-se verificar como seria a mensagem de requisição do serviço SOAP. <soap:envelope> <soap:header> <wsa:to> </soap:header> <soap:body> <buscacidade> <cep> </cep> </buscacidade> </soap:body> </soap:envelope> Fig. 1. Exemplo de mensagem SOAP de requisição. Como pode ser observado, as mensagens transferidas em serviços SOAP são incluídas dentro de um documento no formato XML, cujo elemento-base é denominado Envelope. Portanto, em uma requisição de consulta de cidade a um serviço SOAP o código postal, com papel de parâmetro na operação, deverá ser incluído dentro do elemento Envelope XML para que, juntamente com outros elementos, constituam uma mensagem SOAP válida que seja interpretada e respondida pelo servidor destinatário. Já na figura 2 demonstra-se como seria a mensagem de resposta desse serviço contendo o nome da cidade referente ao código postal utilizado na requisição. <soap:envelope> <soap:body> <buscacidaderesponse> <cidade>santa Rita do Sapucaí</cidade> </buscacidaderesponse> </soap:body> </soap:envelope> Fig. 2. Exemplo de mensagem SOAP de resposta. A formatação das mensagens dos serviços SOAP, através de seu protocolo, provê facilidades para validação e consistência dos dados no servidor. Contudo, prejudica a comunicação nos aspectos clareza (facilidade de leitura e entendimento por um humano) e eficiência na transmissão da informação, pois notase que, tanto na mensagem de requisição quanto na mensagem de resposta os dados mais significativos representam a minoria dentro de todas as informações transferidas. Ou seja, grande parte da informação transferida refere-se ao protocolo SOAP e não ao dado relevante à comunicação. A seguir é demonstrada, na figura 3, a requisição de um serviço REST com a mesma finalidade do serviço SOAP apresentado anteriormente. GET HTTP/1.1 Fig. 3. Exemplo de requisição REST. Logo de início é constatada a simplicidade da requisição do serviço REST em comparação à do serviço SOAP. Ela é composta pelo verbo utilizado no protocolo HTTP, neste caso o GET, pelo endereço do serviço e pelo nome da operação que são, respectivamente, e cidade, pelo parâmetro da busca, que é o código postal, e pela versão do protocolo HTTP. Neste exemplo a simplicidade se estende às opções de teste deste serviço em tempo de desenvolvimento. Enquanto para o serviço SOAP seria necessário utilizar alguma ferramenta apropriada para simular requisições, como o SoapUI [8], ou mesmo desenvolver um software para fazer a requisição real, para testar este serviço REST disponibilizado através do verbo GET bastaria invocar o endereço do serviço juntamente com o parâmetro no campo de endereço de qualquer navegador de Internet e conferir o resultado na tela. Por fim, a mensagem de resposta do serviço REST é demonstrada na figura OK Content-Type: Application/text Santa Rita do Sapucaí Fig. 4. Exemplo de mensagem REST de resposta. No cabeçalho da mensagem HTTP consta o código 200 OK, que indica que o serviço foi executado sem erros, e o tipo do conteúdo da mensagem, que neste caso é um texto simples. No corpo da mensagem consta somente a informação desejada, que é o nome da cidade. Mais uma vez é constatada a simplicidade da mensagem do serviço REST em relação à do serviço SOAP. Outra vantagem que o serviço REST oferece é a opção de definir livremente diferentes formatações dos dados a serem transmitidos, ao passo que nos serviços SOAP são obrigatoriamente incluídos no mesmo tipo de formatação do elemento Envelope do XML. Em casos mais simples como o deste exemplo, usando o serviço REST, pode-se transferir apenas o texto puro, enquanto que em casos mais complexos é possível disponibilizar os dados em diversos formatos como XML ou JavaScript Object Notation (JSON) [9], que é uma alternativa eficiente para transmissão de informações. Conforme mencionado anteriormente, cada alternativa para desenvolvimento e uso de web services possui vantagens e desvantagens. Sendo assim, a definição da melhor estratégia deverá ser tomada mediante análise das necessidades e características de cada sistema. Por exemplo, caso seja necessário priorizar o sequenciamento das mensagens transmitidas, ou a garantia de sua entrega, ou ainda a criptografia das informações nelas contidas, pode-se

3 considerar a facilidade existente provida pelo uso de extensões específicas nos cabeçalhos do SOAP. Por outro lado, se for necessário priorizar a interoperabilidade do serviço em plataformas limitadas (em celulares, por exemplo), a redução de dados trafegados e a consequente maior velocidade na comunicação, os serviços REST podem ser considerados alternativas adequadas. As comparações feitas entre as implementações de web services neste artigo não têm o objetivo de afirmar que os serviços REST são melhores que os serviços SOAP, mas sim evidenciar alguns de seus pontos positivos e suas relevâncias. III. CONTRATOS DE SERVIÇOS Os contratos de serviços são documentos técnicos que descrevem as principais características dos serviços. Neles estão contidas todas as capacidades que o serviço disponibiliza, bem como os tipos de dados com os quais trabalha, as regras de validações, os modelos de dados e outros, constituindo a sua interface. Segundo Erl, Toda vez que dois programas ou duas unidades da lógica da programação precisarem se conectar é necessária alguma forma de contrato técnico [10]. Os contratos de serviços os descrevem com tamanha precisão e detalhamento técnico que existem ferramentas capazes de gerar automaticamente todo o código de programação necessário para invocar as operações por eles disponibilizadas. Tal recurso auxilia no trabalho de um desenvolvedor que necessite utilizar determinado serviço porque o deixa livre para focar o seu trabalho nas regras de negócio do sistema a ser implementado. Utilizando novamente a comparação entre os serviços SOAP e REST, podemos observar a vantagem dos serviços SOAP na questão de contratos, pois este conta com a WSDL que foi proposta pela W3C [11] como linguagem para descrição de web services. Entretanto, enquanto nos serviços SOAP a WSDL foi estabelecida como linguagem padrão para contrato de serviço, no caso dos serviços REST não há padronização para tal. Um documento em WSDL pode opcionalmente ser utilizado para descrever os serviços REST, mas a sua complexidade, contrapondo-se à busca de simplicidade quase sempre almejada por aqueles que optam pelo REST, faz com que a documentação dos contratos seja dada de outra forma, ou seja, sem padronização ou mesmo inexistente. Dada a ausência de padronização para contratos de serviços REST, este artigo propõe a WADL como alternativa de linguagem para tal. IV. WADL A WADL é uma especificação que foi submetida ao W3C em 2009 com o objetivo de estabelecer uma linguagem padronizada para descrição de aplicações WEB. Na especificação da WADL as aplicações WEB são definidas como aplicativos baseados no protocolo HTTP, cujas interações são passíveis de processamento por máquinas. Ou seja, enquanto WEB sites necessitam da interação humana para seu propósito, as aplicações WEB podem ser utilizadas por outros softwares sem a necessidade de intervenção direta de qualquer pessoa. Como os serviços REST são baseados em aplicações WEB, a WADL possui os requisitos necessários para descrever os serviços e constituir um contrato ou interface. Por meio da WADL é possível detalhar características de serviços REST como recursos disponibilizados e relacionamento entre eles; verbo do protocolo HTTP aplicado a cada recurso; formatação de representação de dados e outras. Comprovando-se que a utilização da WADL como linguagem para contratos de serviços REST é uma proposta relevante, diversas ferramentas relacionadas a web services disponibilizam a integração com contratos WADL para desenvolvimento e testes de serviços REST, conforme será demonstrado posteriormente neste artigo. Para descrever a estrutura da WADL e as especificações de seus principais elementos, a figura 5, apresenta um documento WADL desenvolvido e proposto como exemplo referente ao contrato de um serviço REST para gerenciamento de produtos de determinada empresa. <?xml version="1.0" encoding="utf-8"?> <application xmlns=" <grammars> <include href="produto.xsd"/> </grammars> <resources base=" <resource path="produtos"> <method id="listaprodutos" name="get"> <response> <representation xmlns=" element="produto" mediatype="application/json"/> <method id="adicionaproduto" name="post"> <request> <representation xmlns=" element="produto" mediatype="application/json"/> </request> <response> <resource path="/{codigo}"> <param name="codigo" style="template" type="xs:string" required="true"/> <method id="atualizaproduto" name="put"> <request> <representation xmlns=" element="produto" mediatype="application/json"/> </request> <response> <method id="buscaproduto" name="get"> <response status="200"> <representation xmlns=" element="produto" mediatype="application/json"/> <response status="404"> <method id="excluiproduto" name="delete"> <response> </resource> </resource> </resources> </application> Fig. 5. Contrato WADL de exemplo.

4 A fim de possibilitar uma melhor análise dos temas abordados neste artigo, foi desenvolvida também a implementação do serviço REST de exemplo obedecendo à descrição do contrato proposto. O serviço de exemplo descrito no contrato WADL apresentado contém operações para listagem, busca, adição, atualização e exclusão de produto. O exemplo proposto não utiliza todos os elementos e atributos existentes na especificação da WADL. No entanto, são usados os principais componentes necessários para a compreensão da WADL como linguagem para contrato de serviço REST, que são descritos a seguir. A. Application O elemento application constitui a raiz do documento XML. Seu atributo xmlns=" indica que o documento segue as especificações da WADL submetidas ao W3C. B. Grammars O elemento grammars é responsável por descrever a formatação dos dados a serem transferidos durante a comunicação com o serviço. As definições podem ser incluídas diretamente dentro do elemento grammars ou referenciadas por meio do elemento include, que através de seu atributo href indica o endereço onde se encontram as definições a serem incluídas no documento. A inclusão da referência das definições de estrutura de dados é uma alternativa interessante porque possibilita a implementação de um importante princípio de design de serviços defendido por Erl [10], que é o isolamento das definições de estrutura de dados do contrato de serviço. Este isolamento permite que uma mesma definição de estrutura de dados seja utilizada por mais de um serviço, tornando tais serviços compatíveis entre si em termos de formatação de informações. Esta compatibilidade facilita o trabalho quando é necessário desenvolver um sistema com composição de serviços, pois evita a necessidade de transformação de dados. No contrato WADL de exemplo proposto neste artigo foi referenciado um documento para descrição de estrutura de dados utilizando o XML Schema 1 [12] que é recomendado pelo W3C para documentação de estrutura de dados e utilizado em contratos WSDL para descrição de serviços SOAP. A definição completa pode ser observada na figura 6. <?xml version="1.0"?> <xs:schema version="1.0" xmlns:xs=" <xs:element name="produto" type="produto"/> <xs:complextype name="produto"> <xs:sequence> <xs:element name="codigo" type="xs:string"/> <xs:element name="descricao" type="xs:string"/> <xs:element name="preco" type="xs:decimal"/> </xs:sequence> </xs:complextype> </xs:schema> Fig. 6. Documento XML Schema para definição de estrutura de dados. Observa-se no XML Schema que a entidade produto 1 As especificações do XML Schema estão fora do escopo deste artigo. possuí os atributos codigo" e descricao" do tipo xs:string (campos de texto) e o atributo preco do tipo xs:decimal (campo numérico). Embora os documentos XML Schema sejam utilizados comumente para documentação de estrutura de dados na linguagem XML, as suas informações são suficientes para possibilitar que o dado seja representado em formato JSON também. C. Resources O elemento resources tem a finalidade de agrupar todos os recursos disponibilizados pelo serviço. O atributo base=" indica qual é o endereço base onde o serviço se encontra disponível. D. Resource O elemento resource agrupa as operações do serviço que são acessadas pelo mesmo padrão de URI (Uniform Resource Indentifier) representado pelo atributo path. Além das operações do serviço que serão descritas adiante, este elemento pode conter um ou mais elementos resource em seu interior, representando recursos subjacentes. O valor do atributo path pode ser estático ou pode conter referência de variáveis que serão substituídas em tempo de execução por valores relevantes à execução do serviço. Para incluir variáveis no atributo path, o nome da variável deve ser incluído entre os caracteres '{' e '}', e no interior do elemento resource deve ser incluído um elemento param que descreverá os detalhes do parâmetro, conforme apresentado na figura 7. <resources base=" <resource path="produtos">... <resource path="/{codigo}"> <param name="codigo" style="template" type="xs:string" required="true"/>... </resource> Fig. 7. Trecho do contrato para demonstração do elemento resource. O trecho apresentado na figura acima foi extraído do exemplo de contrato WADL proposto. Observa-se que a URI do recurso é composta por uma variável obrigatória do tipo xsd:string, conforme definido no elemento param. O endereço de URI completo para acesso às operações contidas no contrato é formado pela combinação do valor do atributo base do elemento resources e dos atributos path dos elementos resource da hierarquia em que a operação estiver incluída. De tal forma, as operações incluídas no elemento resource deste exemplo serão acessadas pela URI O trecho {codigo} será substituído em tempo de execução pelo código do produto a ser utilizado como parâmetro na operação. E. Method As operações disponibilizadas pelo serviço REST são descritas individualmente através dos elementos method. Este elemento possui um atributo de nome id, cujo valor será utilizado como identificador único da operação, e outro atributo de nome name que indica qual é o verbo do

5 protocolo HTTP utilizado para acesso a tal operação. As entradas esperadas como parâmetro para funcionamento da operação e as saídas originadas pelo seu processamento são descritas pelos elementos request e response respectivamente, que são descritos a seguir. F. Request O elemento request descreve as entradas que a operação espera para seu processamento. Em alguns casos um serviço REST pode conter operações que não necessitam de parâmetros ou que já possuem as variáveis necessárias dinamicamente incluídas em sua invocação através de sua URI, como demonstrado anteriormente. Nestes casos, este elemento pode ser omitido. Nos casos em que a operação necessitar de parâmetros para executar a ação esperada, estes poderão ser descritos dentro do elemento request através de outros dois elementos: param e representation. O elemento param é o mesmo utilizado dentro do elemento resource descrito anteriormente. No entanto, neste caso, os valores para o seu atributo style devem ser: query (que indicará que o valor será incluído na URI) ou header (que indicará que o valor será incluído no cabeçalho da requisição HTTP). O elemento representation é utilizado para descrever a formatação dos dados que deverão ser enviados para a operação dentro do corpo da mensagem HTTP. Através de seu atributo mediatype é possível indicar o tipo de mídia esperado pela operação conforme o exemplo da figura 8 demonstra. <method id="atualizaproduto" name="put"> <request> <representation xmlns=" element="produto" mediatype="application/json"/> </request>... Fig. 8. Trecho do contrato para demonstração do elemento "representation". O trecho acima extraído do documento WADL de exemplo, descreve que a operação "atualizaproduto" necessita de dados enviados no corpo da mensagem em formatação JSON obedecendo às definições de estrutura de dados descritas no XML Schema incluído no contrato. Outros exemplos de tipos de mídia dentre os tantos especificados pelo W3C poderiam ser application/xml para formatação em XML e text/plain para representação em texto simples. definição, por exemplo, da formatação de resposta, verificando um parâmetro no cabeçalho da mensagem HTTP de requisição. É possível também atrelar um tipo de mídia a um código de status da mensagem HTTP conforme demonstra a figura 9. <resource path="/{codigo}"> <param name="codigo" style="template" type="xs:string" required="true"/> <method id="buscaproduto" name="get"> <response status="200"> <representation xmlns=" element="produto" mediatype="application/json"/> <response status="404">... </resource> Fig. 9. Trecho do contrato para demonstração do elemento response. De acordo com o contrato, a operação buscaproduto deverá retornar os dados em formato JSON quando o status da resposta for 200 (padrão para requisições com sucesso). Entretanto, quando o status da reposta for 404 (padrão para requisições com recurso não encontrado) a operação deverá retornar um texto, que poderá conter uma mensagem descrevendo a não existência do produto procurado. V. TESTE DE SERVIÇO REST COM SOAPUI O SoapUI é uma ferramenta para testes de web services que oferece suporte aos principais protocolos e tecnologias atuais. Através do SoapUI é possível fazer requisições aos serviços de forma simples, eliminando assim a necessidade de desenvolvimento de um software exclusivo para tal. Comprovando a relevância da WADL no contexto de serviços REST, o SoapUI é uma das ferramentas que oferece suporte a esta linguagem. Ao criar um novo projeto para testes de serviços REST, é possível importar o contrato desses serviços em WADL no SoapUI, para que ele crie automaticamente a estrutura cliente completa para testar todas as operações contidas no contrato, incluindo o endereçamento dos recursos, os parâmetros esperados, a formatação dos dados e demais características que estiverem descritas, por meio de envio de requisições a esses serviços. Na figura 10 é demonstrado o teste da operação buscaproduto executado no SoapUI utilizando o mesmo contrato WADL apresentado como exemplo neste artigo. G. Response O elemento response descreve as respostas enviadas pelas operações como resultado de seus processamentos. Da mesma forma que ocorre no elemento request, os dados fornecidos como resposta são descritos nos elementos param e representation indicando as informações que serão contidas no cabeçalho e no corpo da mensagem, respectivamente. É possível definir diversos tipos de mídia através de múltiplos elementos representation indicando uma lista de formatação disponível. Neste caso, na implementação do serviço REST, deverá ser desenvolvida uma lógica para

6 resumo, podem também usufruir da WADL. VI. OUTRAS FERRAMENTAS PARA WADL Consolidando a validade da proposta de adoção da WADL como linguagem para contrato de serviços REST, existem outras ferramentas relacionadas a web services que, assim como o SoapUI, oferecem integração com esta linguagem. Neste capítulo serão demonstradas algumas dessas ferramentas capazes de facilitar e melhorar o trabalho dos desenvolvedores através desta integração. Fig. 10. Demonstração de teste de serviço REST no SoapUI. As áreas destacadas na cor azul representam as informações de entrada ao serviço, que neste caso é o verbo GET do protocolo HTTP, o endereço da operação e o código do produto. Como o SoapUI é capaz de identificar, por meio do contrato WADL, que esta operação necessita do parâmetro código do produto para fazer a busca, é automaticamente adicionada uma tabela com o item codigo, cujo valor pode ser alterado. Ao executar o teste, acionando o botão destacado na cor vermelha, o SoapUI atualiza o endereço do recurso inserindo o código do produto digitado antes de fazer a invocação do serviço. Para as operações que necessitem de informações enviadas no corpo da mensagem, como a operação para inclusão de novo produto, por exemplo, o SoapUI disponibiliza outro campo onde os dados podem ser inseridos no formato adequado. O SoapUI define bem onde inserir cada dado justamente pela análise feita sobre o contrato WADL. As áreas destacadas na cor verde representam os dados recebidos como resposta do serviço. Conforme foi definido no contrato, esta operação deve retornar os dados no corpo da mensagem HTTP no formato JSON quando o produto for localizado com sucesso. Como foi utilizado, para pesquisa, o código de um produto existente, verifica-se que a mensagem de resposta do serviço contém em seu cabeçalho o código de status 200 do protocolo HTTP, entre outras informações, indicando que o produto foi localizado com sucesso. No corpo da mensagem de resposta constam as informações do produto procurado no formato JSON conforme também apontado no seu cabeçalho. Além da opção de importação, o SoapUI disponibiliza uma ferramenta para exportação de contrato WADL. Para testar serviços REST que não possuam contrato de serviço, é possível definir manualmente cada operação e suas características, como endereço, parâmetros e formatação de dados, entre outras. Após essa definição manual, o SoapUI é capaz de gerar automaticamente um documento em WADL contendo a descrição do serviço. Esse documento WADL poderá ser utilizado para facilitar testes futuros ou mesmo para auxiliar no desenvolvimento de softwares que necessitem se comunicar com o serviço utilizando outras ferramentas existentes, que serão mencionadas a seguir, as quais, em A. Jersey O Jersey [13] é um framework Java usado para desenvolvimento de serviços REST baseado na especificação Java API for RESTful Services (JAX-RS) [14] capaz de auxiliar na criação dos serviços e dos clientes que os utilizarão. Os serviços desenvolvidos com Jersey podem ser descritos em contratos WADL gerados automaticamente. Para que o Jersey crie o contrato do serviço em WADL, basta fazer uma requisição HTTP com o verbo GET no endereço-base do serviço, acrescido da expressão application.wadl. Sendo assim, e utilizando o exemplo deste artigo, ao se fazer uma requisição GET ao endereço o Jersey gerará o contrato do serviço em WADL em tempo de execução e responderá à requisição com o contrato gerado no corpo da mensagem HTTP. O contrato WADL gerado pode auxiliar na documentação do serviço, nos processos de testes, utilizando o SoapUI conforme demonstrado anteriormente, ou mesmo no desenvolvimento de outros softwares que se comunicarão com este serviço fazendo uso de outras ferramentas, apresentadas a seguir. B. Microsoft Project Siena O Microsoft Project Siena [15] é uma tecnologia que tem o objetivo de possibilitar o desenvolvimento de aplicativos por pessoas sem conhecimentos avançados de programação. Durante a criação de aplicativos, o Microsoft Project Siena oferece algumas opções de fontes de dados, dentre elas a utilização de serviços REST. Para possibilitar que pessoas sem conhecimento ou domínio de serviços REST façam uso dessa tecnologia, o Microsoft Project Siena permite a importação de arquivos WADL como contrato de serviço. A partir desse contrato importado, a ferramenta é capaz de criar os mecanismos necessários para a comunicação com o serviço. C. Apache CXF O Apache CXF [16] é um framework utilizado no desenvolvimento de web services com suporte para os principais protocolos e tecnologias atuais. Para o desenvolvimento de serviços REST, o Apache CXF também se baseia na especificação JAX-RS e oferece opções de integração com o WADL. Além de disponibilizar a geração automática de WADL a partir de um serviço já desenvolvido, existe a possibilidade de geração de código para

7 implementação do serviço a partir de um WADL. Em alguns casos pode ser adequado iniciar o trabalho de desenvolvimento do serviço pelo seu contrato, para que o planejamento seja totalmente independente de limitações, características de tecnologias ou linguagens de programação. Esta metodologia de iniciar o desenvolvimento do serviço pelo contrato é defendida por Carvalho [17] como um importante princípio de design com o intuito de criar o serviço desacoplado das tecnologias que o irão suportar. Neste caso, a geração automática do código de implementação, através do WADL pré-definido, facilita o trabalho do programador no momento da codificação. Na figura 11 é apresentado um trecho do código gerado utilizando o contrato WADL de exemplo deste artigo. Conforme pode ser observado, o código gerado não possui a implementação completa do serviço, mas contém grande parte da estrutura necessária (métodos, parâmetros, retornos, anotações, mapeamento dos recursos, etc.), facilitando o trabalho do desenvolvedor. Além disso, este tipo de geração garante que o novo código esteja obedecendo 100% à interface definida no contrato WADL, diminuindo erros humanos de programação neste quesito, o que faz o serviço cumprir a sua parte perante o contrato WADL. Assim, o cliente de tal contrato conhecerá perfeitamente a forma de requisitar a execução das capacidades do serviço em termos de formatação de mensagens via HTTP, por exemplo. comunidade Java.net [19]. Conforme sugerido por seu nome, ela é capaz de criar códigos Java a partir de definições WADL, que constituem a estrutura (classes, métodos, parâmetros, etc.) necessária para estabelecer comunicação com o serviço. Para avaliar o resultado da geração de códigos do wadl2java, foram feitos testes utilizando o contrato de serviço proposto como exemplo neste artigo. Os códigos gerados mostraram-se eficientes, oferecendo mecanismos de acesso a todas as operações do serviço descritas de forma simples no contrato. A figura 12 demonstra um teste da operação de busca de produto utilizando o código gerado. Conforme pode ser observado na figura acima, o serviço de consulta de produto pode ser requisitado utilizando apenas duas linhas de código. O wadl2java gerou automaticamente toda a estrutura para consumir o serviço em Java, incluindo a classe de entidade Produto que contém seus respectivos atributos conforme descrito no documento XML Schema referenciado pelo contrato. O código gerado pela wadl2java utiliza internamente as bibliotecas do Jersey para estabelecer a comunicação com o serviço seguindo a especificação JAX-RS. Tal ferramenta pode auxiliar consideravelmente no trabalho do desenvolvedor de software que necessite criar um sistema cliente para consumir o serviço. Além de ter a garantia de que o serviço será acessado corretamente seguindo as descrições documentadas no contrato, ele poderá focar os seus esforços em outros pontos, já que não precisará codificar manualmente a estrutura para se comunicar com o serviço. Fig. 11. Código Java gerado pelo Apache CXF. D. wadl2java O wadl2java [18] é uma ferramenta mantida pela Fig. 12. Teste de busca de produto com código gerado pelo wadl2java. Devido à possibilidade de especificações de contratos de serviços REST satisfatoriamente utilizando WADL, devido à demanda crescente de uso desses serviços, devido ao apoio já existente através de ferramentas de software que lidam com WADL, e devido às vantagens provenientes do uso conjunto desses três tipos de tecnologias, além da falta de uma padronização atual de composição de contratos para serviços REST, a adoção de WADL em contratos desse tipo deve ser aplicada desde já, o que trará ganhos à sociedade de computação como claramente evidenciado neste documento. Com este tipo de padronização aplicado a todos os projetos

8 futuros de serviços REST, muitas dificuldades para o desenvolvimento de aplicação cliente estarão diminuídas ou eliminadas, como por exemplo a dificuldade em entender/descobrir como lidar corretamente com as capacidades de um serviço. VII. CONCLUSÃO Os serviços REST ocupam papel importante no atual contexto de tecnologias para desenvolvimento de serviços de TI disponíveis via web. Devido à simplicidade da tecnologia REST e à versatilidade e eficiência na transmissão de dados, ela tem seu espaço garantido em computação podendo ser considerada mais adequada em casos específicos, em comparação com os serviços SOAP, por exemplo. Entretanto, a ausência de um padrão consolidado para descrição das capacidades dos serviços REST, como o contrato de serviço, pode ser considerada uma desvantagem. Diante dessa característica, este artigo apresenta a WADL como uma alternativa para definição de contratos de serviços REST. Para analisar os resultados e as vantagens obtidas na prática com a utilização do WADL como contrato de serviços REST, foi desenvolvido um serviço de exemplo com operações básicas e o seu respectivo contrato com WADL. Foi constatado que o contrato em WADL é capaz de descrever detalhadamente o serviço REST com eficiência e simplicidade. Reforçando a validade da proposta de utilização do WADL como contrato de serviços, verifica-se que existem diversas ferramentas relacionadas a web services que oferecem suporte a esta linguagem para o trabalho com serviços REST. Tais ferramentas podem auxiliar no trabalho dos desenvolvedores em diversas etapas, desde o desenvolvimento e testes dos serviços até a criação de softwares capazes de interagir com os mesmos. Portanto, a WADL cumpre bem o papel de linguagem para a definição dos contratos de serviços REST, e tal papel está bem apoiado tecnicamente através das ferramentas citadas. Para aqueles que se interessarem pelo assunto e tiverem intenção de expandir a pesquisa sobre WADL como contrato de serviços REST são sugeridos os seguintes temas: 1) Repositórios de serviços baseados em WADL. 2) Descrição de estrutura de dados com XML Schema. 3) Reuso de serviços REST. [13] Jersey, [Online]. Disponível: [14] JAX-RS, [Online]. Disponível: [15] Microsoft Project Siena. [Online]. Disponível: [16] Apache CXF, [Online]. Disponível: [17] R. P. Carvalho, "Introdução em SOA + BPM" [18] WADL2JAVA. [Online]. Disponível: [19] java.net. [Online]. Disponível: [20] T. Erl, "SOA with REST Principles, Patterns & Constraints for Building Enterprise Solutions with REST", [21] M. S. R. A. Hatem Hamad, Performance Evaluation of RESTful Web Services, International Arab Journal of e-technology, André Luiz Pires Silva nasceu em Ipuiuna, MG, em junho de Recebeu o título de Bacharel em Sistemas de Informação pela Universidade do Vale do Sapucaí (UNIVAS) em Desde outubro de 2010 trabalha na PR Sistemas, em São Paulo, na área de desenvolvimento de software. Possui experiência e interesse em tecnologias como Java (JSE, JME e JEE), C#, C, C++, Android e Web Services. Possui aplicativos publicados na Google Play e Windows Phone Store. Foi um dos primeiros brasileiros a ter aplicativos selecionados para inclusão em smartphones da Nokia em 2013, para adequação à lei de incentivo ao desenvolvimento nacional ( lei do bem ). Rodrigo Pimenta Carvalho recebeu o título em Ciência da Computação pela Universidade Federal de Minas Gerais (UFMG), Belo Horizonte, MG, Brasil, em 1997, e de Mestre em Engenharia Elétrica pelo Instituto Nacional de Telecomunicações (INATEL), Santa Rita do Sapucaí, MG, Brasil, em Em Julho de 1997 foi contratado pelo INATEL como Desenvolvedor de Software. Tem experiência de 17 anos nesta área, incluindo projetos para empresas como IBM, NEC, LG, Nokia, Ericsson e Benchmark. É membro do INATEL Competence Center (ICC), trabalhando com tecnologias como Linguagens de Programação, Programação Orientada a Objetos e Protocolos de Telecomunicações. Em 2002 recebeu o prêmio de Melhor Plano de Negócios do Núcleo de Empreendedorismo do INATEL (NEMP). Em 2004 tornou-se um Programador Certificado Sun para Java 2 plataforma 1.4. Atualmente a sua principal área de trabalho é a de Design e Desenvolvimento de Software de Telecomunicações, onde possui experiência em projeto, modelagem, codificação e testes. Seus interesses atuais incluem o desenvolvimento de aplicações na nova geração de redes (NGN), adotando ferramentas-padrão da indústria, tais como Java, pilha NIST- SIP, Web Services e Parlay X. Foi também co-fundador da empresa Biosoftware Sistemas Didáticos Ltda. REFERÊNCIAS [1] W3C, SOAP. [Online]. Disponível: [2] W3C, REST. [Online]. Disponível: [3] W3C, XML. [Online]. Disponível: [4] W3C, WSDL. [Online]. Disponível: [5] W3C, WADL. [Online]. Disponível: [6] W3C, HTTP. [Online]. Disponível: [7] A. Rodriguez, RESTful Web services: The basics, IBM - DeveloperWorks, [8] SoapUI. [Online]. Disponível: [9] JSON. [Online]. Disponível: [10] T. Erl, "SOA Princípios de design de serviços", [11] W3C. [Online]. Disponível: [12] W3C, XML Schema. [Online]. Disponível: