Entendendo e Desenvolvendo Restful WebServices no Framework X-Gov. Autor: Mauricio Cirelli

Transcrição

1 Entendendo e Desenvolvendo Restful WebServices no Framework X-Gov 1. Introdução Autor: Mauricio Cirelli Neste documento abordaremos a estrutura da arquitetura REST (Representational State Transfer) no desenvolvimento de serviços web. Estudaremos seus funcionamentos e postulados para, então, desenvolvermos uma aplicação de WebService utilizando C# Mais adiante, iremos comparar a estrutura com a arquitetura SOAP (Simple Object Access Protocol). Criaremos um exemplo de serviço web baseado em REST e discutiremos métodos de consumo desta aplicação e sua publicação. Por fim veremos como aplicar os conceitos abordados dentro do cross-media e, mais especificamente, para o projeto X-GOV. 1.1 Histórico do REST O termo originou-se em 2000, a partir da tese de doutorado de Roy Fielding, um dos principais autores da especificação do protocolo HTTP (Hypertext Transfer Protocol), utilizado na comunicação Web. Os sistemas baseados em REST são denominados RESTful e devem seguir os princípios descritos por Fielding em sua tese: "Architectural Styles and the Design of Network-based Software Architectures". 1.2 Princípios do REST Fielding postula que o protocolo HTTP possui recursos suficientes para executar todas as transações Web comuns: inserção, atualização, exclusão e recuperação de informações, utilizando apenas seus métodos (verbs) nativos e o endereço da requisição (URI: Uniform Resource Identifier): O protocolo HTTP Nota: URL (Uniform Resource Locator) é um tipo de URI O protocolo HTTP foi criado para garantir a comunicação no ambiente Web. É graças a ele que conseguimos acessar um site. Porém, até 2000, quando Fielding definiu a arquitetura REST, esta era praticamente a única função do HTTP: receber informação de um servidor localizado através de uma URL ou enviar uma informação ao mesmo. Estas atividades fazem uso de apenas 2 verbos do HTTP: GET e POST. O HTTP foi definido contendo 8 verbos: Nota: Atualmente o HTTP possui muitos outros verbos, porém são menos utilizados e muitos não são aceitos na maioria dos navegadores. OPTIONS: Uma requisição do tipo OPTIONS retornará os métodos HTTP disponíveis no servidor em questão. Na arquitetura REST, em termos de WebServices, OPTIONS nos possibilita saber quais WebMethods (serviços, funções) estão disponíveis em determinada URI. HEAD: Requisições HEAD retornam o cabeçalho da resposta HTTP. Este cabeçalho contém informações como: Content-Type: tipo de dados que o servidor aceita, como XML, JSON, texto puro. Status: indica se a requisição foi bem sucedida ou não, indicando com 200 OK em caso afirmativo ou com outro número e descrição de erro. Date: data e hora da requisição.

2 Server: tipo de web Server, como Internet Information Services (IIS), Apache, entre outros. Content-Lenght: tamanho da resposta (quantidade de caracteres). Há outras informações menos relevantes no cabeçalho de uma requisição HTTP que não serão tratadas neste documento. GET: Requisições do tipo GET retornam todo tipo de informação relacionada aos parâmetros fornecidos. Dentro do ambiente de WebServices, este tipo de solicitação é muito usada para fazer consultas a banco de dados. Além de retornar estas informações, o método GET também retorna o cabeçalho da requisição, assim como o método HEAD. POST: Este tipo de requisição pode ser utilizada para atualizar uma informação armazenada em uma URI ou para inserir novas informações, dependendo dos parâmetros fornecidos. POST apenas envia uma quantidade de parâmetros de dados para o servidor, sendo ele o responsável por interpretar e utilizar estes parâmetros da maneira que quiser. Na arquitetura REST, Fielding define que devemos utilizar o método POST apenas para inserir novas informações. PUT: O método PUT, ao contrário do POST, envia obrigatoriamente uma nova página (ou atualiza uma se os parâmetros indicarem que já existe uma página onde se está desejando colocar uma nova). Apesar de soarem muito similares, POST e PUT são bastante diferentes. PUT criará ou atualizará uma página que conterá os dados passados pelo URI. POST passa os dados pelo URI para o servidor, que se encarrega de fazer o que quiser com eles. Fielding define o uso do PUT como de atualização de dados, na arquitetura REST. DELETE: Este método exclui a página indicada por determinada URI. TRACE: Rastreia a solicitação, sendo possível, para o solicitante, saber o que acontece com seus dados enviados conforme eles trafegam pela rede até chegar ao servidor de destino. É especialmente importante quando sabemos que nossa informação passará por diversos servidores intermediários, sendo, assim, passíveis de modificações indesejadas. CONNECT: Muda a rota da solicitação atual. Muito utilizada em conjunto com proxys e túneis TCP/IP para conexões seguras (SSL). Cada requisição gera uma resposta do servidor. Esta resposta vem codificada em elementos chamados status-code, que são números acompanhados por uma palavra, seguindo a regra: 1xx Informational: A principal é 100 Continue, que indica que o client deveria continuar sua requisição. Esta classe de status-code é apenas utilizada para a comunicação Server-client, não sendo de grande utilidade para nosso propósito; 2xx Successful: Indica que a requisição foi feita sem problemas. Utilizaremos, principalmente, os codes 200 OK e 201 Created, sendo o primeiro utilizado em solicitações GET, DELETE e PUT normalmente e o segundo em solicitações do tipo POST.

3 3xx Redirection: Classe de status-code criada para indicar se uma solicitação deve ser redirecionada para ser concluída. Isto pode ocorrer devido a uma mudança (moved) de URI ou utilização de servidores Proxy. 4xx Client Error: Indica que houve um erro durante a solicitação causada pelo cliente. Este erro pode ser: 404 Not Found, 403 Forbidden, 409 Conflict, entre outros. Estes 3 serão os mais utilizados em serviços web RESTful. O primeiro indica que a URI não pôde ser encontrada, o segundo que o método utilizado não é permitido e o último que a solicitação já existe. 409 Conflict normalmente ocorre quando tentamos usar o método POST com o mesmo Request Body mais de uma vez. 2. REST e SOAP (na visão de WebService) Como podemos observar, o protocolo HTTP está sendo muito pouco utilizado, tendo capacidade para executar qualquer tipo de requisição. Isto torna desnecessária a criação de novas arquiteturas para a troca de informações na Web (como o SOAP), as quais tornam a conexão mais carregada de cabeçalhos e informações sobre os pacotes de respostas e requisições que estão trafegando. Falando sobre WebServices, no caso do SOAP, a informação é transmitida através de um documento XML. Junto com este documento, trafegam inúmeros outros documentos de especificações, como WS- Notification, WS-Transfer, entre muitos outros WS- (conhecidos como WS-*) que, juntos, formam a especificação WSDL (WebService Description Language), um documento contento todas as definições de metadados utilizados nas requisições. Tudo isto para tornar a arquitetura multiplataforma e garantir a interoperabilidade entre os sistemas. Quando pensamos que o HTTP é um protocolo universalmente aceito e entendido por qualquer sistema, navegador, framework ou servidor, percebemos o quanto é desnecessário trafegar tamanha quantidade de informação. O principal trunfo do SOAP em relação ao REST é sua portabilidade dentro de diversos protocolos. É possível fazer uma requisição SMTP ou FTP, por exemplo, utilizando SOAP. Como o REST é definido e estruturado a partir dos verbos HTTP, ele apenas atua sobre este protocolo de comunicação. Porém, vale ressaltar que REST é uma arquitetura de projeto, portanto, pode ser utilizada para qualquer tipo de aplicação que não seja necessariamente um WebService, enquanto SOAP foi desenvolvido especificamente para este propósito. 3. Mudança de Paradigma: Uma aplicação RESTful exige uma certa mudança no modo de estruturar um projeto. É semelhante ao processo que sofremos quando passamos de uma lógica estruturada para uma orientada a objetos. Até hoje, costumávamos construir nossos WebServices nos baseando em quais métodos eles possuiriam (quais verbos eles atenderiam). A partir disto, criávamos uma estrutura que recebia as definições dos métodos através do WSDL e chamávamos estes métodos em nossas aplicações. Quando pensamos em REST, não estamos pensando nos métodos que nosso serviço web terá, pois estes métodos já estão definidos: são os 8 verbos do HTTP. Temos, então, que nos focar em como utilizar estes 8 verbos para atender nossas necessidades. Exemplo: O HTTP não possui um verbo BuscarContasCorrentes. Se estivéssemos pensando em SOAP, a resposta mais óbvia para este problema seria: Vamos declarar um WebMethod chamado BuscarContasCorrentes e defini-lo. A partir daí, o WSDL se encarrega de fazer nosso verbo ser entendido por todos os clients. Em REST não temos esta liberdade, pois não utilizamos um WSDL. Se pensarmos que temos o verbo GET do HTTP e um URI que podemos definir, já temos todas as

4 ferramentas necessárias para resolver o problema de listar as contas correntes de nosso banco. Poderíamos implementar, então, a seguinte requisição: GET De acordo com a especificação HTTP, esta requisição nos retornará todo o conteúdo da URI pedida, a qual armazena as contas correntes do banco. Ainda no exemplo do banco, se quiséssemos criar uma nova conta corrente, por definição, devemos utilizar o verbo POST (embora PUT também seja possível), com uma requisição do tipo: POST Request Body (corpo da requisição): cliente = NomeDoCliente; (...) Esta requisição criará uma nova página com os dados do novo cliente, passados dentro do Request Body. Neste exemplo, a solução parecia óbvia. Imediatamente imaginaríamos os verbos PUT e DELETE entrando em ação para atualizar ou remover os dados de uma determinada conta. O importante aqui é perceber que com os 8 verbos do HTTP, podemos traduzir qualquer tipo de problema que enfrentamos, sem ter que criar novas interfaces, novos métodos e novas especificações. 4. Limbo: REST é Stateless, pois HTTP é Stateless: Imaginemos a seguinte situação: realizamos uma requisição passando algumas informações. Estas são enviadas para a página definida pelo URI que digitamos. Então nosso servidor nos responde dizendo que recebeu estas informações. Estas informações não poderão mais ser requisitadas. Na verdade, elas não serão armazenadas em cache, ou algum tipo de memória do qual possamos recuperá-las ou tratá-las. Ao receber estas informações, o servidor deverá estar programado para armazená-las em uma base de dados ou session de usuário, por exemplo. Caso contrário, elas serão perdidas, indo para o limbo. Isto acontece devido à característica Stateless do HTTP e, por conseqüência, do REST. Este será nosso intuito quando começarmos a codificar nosso WebService. A priori receberemos as requisições e as passaremos a um banco de dados, retornado ao usuário os resultados ou mensagens do servidor. 5. Estruturando uma aplicação RESTful: A partir de agora começaremos a discutir os procedimentos para modelar uma aplicação RESTful já voltando os exemplos para o desenvolvimento do WebService. Ao final, teremos um exemplo de WebService funcional baseado em REST. O primeiro passo para criar uma aplicação RESTful é definir quais são os problemas que nossa aplicação terá de resolver e tentar modelá-los de forma a usar as definições de GET, POST, PUT e DELETE (os principais verbos do HTTP na arquitetura REST) já discutidas. Nosso produto final será um WebService que recebe mensagens (pode ser de um blog, por exemplo) as quais contém: Texto da Mensagem: string Nome do Usuário: string

5 Data: string ID: string (para facilitar trataremos o ID como string, ao invés de int). Definimos então uma classe Mensagem: public class Mensagem public string ID, Data, Texto, Nome; Como nossas solicitações deverão retornar alguma mensagem mais compreensível para o usuário, vamos criar uma nova classe que contenha a mensagem em si e uma string de resposta com relação a operação: public class TextoMensagem public string resposta; public Mensagem msg = new Mensagem(); Nossa aplicação deverá realizar buscas por ID e por nome, listar todas as mensagens, gravar novas mensagens, atualizar mensagens e apagar mensagens. Iremos implementar todos este métodos, a fim de exemplificar toda a tecnlogia de REST incorporada ao Windows Comunication Foundation (WCF) do.net Framework 3.5, utilizando os dados na forma XML e na forma JSON. Tendo definido os métodos que nosso WebService possuirá, devemos abstraí-los utilizando os verbos do HTTP. Desta forma, definimos: Busca Por ID: GET Busca por Nome: GET Listar mensagens: GET Gravar Mensagem: POST Atualizar Mensagem: PUT Apagar Mensagem: DELETE Algumas observações antes de prosseguirmos. Como podem perseber, nossas URIs coincidem em alguns momentos. A diferenciação quanto ao método a ser empregado se dará através de análise do verbo de solicitação. O uso de id e nome indica que estas URIs serão dinâmicas, ou seja, seu conteúdo dependerá dos valores digitados nestes espaços. Se quisermos buscar a mensagem cujo ID é 14, deveremos realizar uma solicitação do tipo GET sobre Veremos como construir estas URIs e analisá-las em breve. 6. Windows Comunication Foundation (WCF) REST StarterKit:

6 Dentro do framework.net 3.5, com Service Pack 1, é possível instalar certos templates de projetos. Um deles é o WCF REST StarterKit, que possui diversos exemplos, templates e uma nova biblioteca, todos desenvolvidos especialmente para desenvolver RESTful WebServices. Devemos ressaltar que algo semelhante existe dentro da plataforma JAVA. O NetBeans IDE 6.5 possui alguns modelos de serviços RESTful que podem ser remodelados. Neste documento, utilizaremos em nossos próximos passos o Visual Studio 2008 SP1, com.net Framework 3.5 SP1 e construiremos nossa aplicação a partir do modelo WCF REST Singleton Service, contido no WCF REST StarterKit. Você pode obtê-lo aqui: Siga o Instalation Guide para obter sucesso na instalação do StarterKit. Você precisará compilar um projeto após extrair os arquivos (Web.sln) para criar a nova dll Microsoft.ServiceModel.Web. 7. Iniciando o Projeto Crie um novo projeto baseado no template WCF REST Singleton Service a partir do Visual Studio Alguns arquivos densamente comentados, repletos de TO DO s, serão adicionados. Para nosso propósito, você pode apagar todos estes códigos, substtuindo pelos códigos passados ao longo dos procedimentos descritos por aqui. Em nossos exemplos, o nome da aplicação foi definido como RESTStarterKit1. Primeiramente, vamos definir nossos serviços, suas URIs, quais verbos HTTP serão utilizados em cada caso e que tipo de reposta JSON ou XML receberemos. Vamos primeiramente utilizar o VS2008 Refactoring Tool para renomear todas as aparições de Service1 para Service, e de IService1 para IService, inclusive o nome do arquivo Service1.svc criado automaticamente. Expanda o arquivo Service.svc, para editarmos Service.base.svc.cs: using System; using System.Collections; using System.Collections.Generic; using System.Runtime.Serialization; using System.ServiceModel; using System.ServiceModel.Web; using System.ServiceModel.Activation; using System.Linq; using System.Net; using Microsoft.ServiceModel.Web;

7 namespace RESTStarterKit1 #region Service Contracts (Uri Templates e WebMethods) [ServiceContract] public interface IService Isto define nossa interface. A tag ServiceContract indica que os métodos descritos dentro desta interface fazem parte de um serviço, devendo seguir um contrato, ou seja, devendo seguir as propriedades descritas. Continuando: #region XML APIs [WebGet(UriTemplate = "xml/mensagem/id")] Mensagem XMLGetMensagemByID(string id); [WebGet(UriTemplate = "xml/mensagens/nome")] Mensagem[] XMLGetMensagemByNome(string nome); [WebGet(UriTemplate = "xml/mensagens")] Mensagem[] XMLGetMensagens(); [WebInvoke(Method = "DELETE", UriTemplate = "xml/mensagem/id")] string XMLDeleteMensagem(string id); [WebInvoke(Method = "POST", UriTemplate = "xml/mensagens")] TextoMensagem XMLPOSTMensagem(/*Mensagem msg*/); [WebInvoke(Method = "PUT", UriTemplate = "xml/mensagem/id")] TextoMensagem XMLUpdateMensagem(Mensagem msg, string id); #endregion Esta região cria os métodos que trabalharão com respostas em XML. XML é o formato de dados padrão da linguagem, portanto não foi preciso especificá-lo. Cada OperationContract indica um novo WebMethod. Estes WebMethods serão chamados sempre que as situações descritas pelo WebGET ou WebInvoke acontecerem. WebGet é utilizado sempre que a solicitação é do tipo GET. Para os demais métodos utilizamos o atributo WebInvoke, especificando o verbo HTTP que será utilizado. As URI Templates são os modelos de URI que o usuário deverá requisitar, em conjunto com o tipo de solicitação, para se utilizar dos serviços. Este esquema permite um entendimento e uma estruturação perfeitamente análogos ao que realizamos na seção 5. Com um procedimento análogo e continuando a definição de nossa interface, definiremos os métodos que retornarão strings no formato JSON: #region JSON APIs [WebGet(UriTemplate = "json/mensagem/id", ResponseFormat = WebMessageFormat.Json)] Mensagem JSONGetMensagemByID(string id); [WebGet(UriTemplate = "json/mensagens/nome", ResponseFormat = WebMessageFormat.Json)] Mensagem[] JSONGetMensagemByNome(string nome); [WebGet(UriTemplate = "json/mensagens", ResponseFormat = WebMessageFormat.Json)] Mensagem[] JSONGetMensagens();

8 [WebInvoke(Method = "DELETE", UriTemplate = "json/mensagem/id", ResponseFormat = WebMessageFormat.Json)] string JSONDeleteMensagem(string id); [WebInvoke(Method = "POST", UriTemplate = "json/mensagens", ResponseFormat = WebMessageFormat.Json)] TextoMensagem JSONPOSTMensagem(/*Mensagem msg*/); [WebInvoke(Method = "PUT", UriTemplate = "json/mensagem/id", ResponseFormat = WebMessageFormat.Json)] TextoMensagem JSONUpdateMensagem(Mensagem msg, string id); #endregion #endregion Ao acrescentar o atributo ResponseFormat do WebGet e WebInvoke, podemos definí-lo como WebMessageFormat.JSON ou WebMessageFormat.XML (padrão). Com isto terminamos de definir nossa interface para os serviços disponíveis. 7.1 Definindo os Métodos da Interface A interface, por definição, apenas molda um protótipo dos métodos. Agora devemos definir os métodos no arquivo Service.svc.cs. Novamente teremos métodos para XML e métodos análogos para JSON. namespace RESTStarterKit1 [ServiceBehavior(IncludeExceptionDetailInFaults = true, InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)] [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] public class Service : IService #region XML Services public Mensagem XMLGetMensagemByID(string id) return metodo.getmensagembyid(id); public Mensagem[] XMLGetMensagemByNome(string nome) return metodo.getmensagembynome(nome); public Mensagem[] XMLGetMensagens() return metodo.getmensagens(); public string XMLDeleteMensagem(string id) return metodo.deletemensagem(id, "XML"); public TextoMensagem XMLPOSTMensagem() Mensagem msg = new Mensagem(); msg.nome = HttpContext.Current.Request.Form["nome"];

9 msg.texto = HttpContext.Current.Request.Form["texto"]; msg.data = DateTime.Now.ToString(); return metodo.postmensagem(msg, "XML"); public TextoMensagem XMLUpdateMensagem(Mensagem msg, string id) texto = HttpContext.Current.Request.Form["texto"]; return metodo.updatemensagem(texto, id, "XML"); #endregion A classe methods define as funções de banco de dados. Ela foi criada a fim de reaproveitar o código, visto que os WebMethods para XML e JSON são exatamente iguais, diferenciando-se apenas pelo atributo ResponseFormat discutido na seção anterior. O trecho acima define as funções para XML. A seguir as funções para JSON e então exibiremos a classe methods sem entrar em detalhes. Como verão é apenas um conjunto de métodos de conexão a um banco de dados SQL Server que realizam algumas queries SQL. Foge do intuito deste documento discutir as bibliotecas e métodos de conexão do ADO.NET. Todos os fontes poderão ser encontrados no Apêndice. #region JSON Services public Mensagem JSONGetMensagemByID(string id) return metodo.getmensagembyid(id); public Mensagem[] JSONGetMensagemByNome(string nome) return metodo.getmensagembynome(nome); public Mensagem[] JSONGetMensagens() return metodo.getmensagens(); public string JSONDeleteMensagem(string id) return metodo.deletemensagem(id, "JSON"); public TextoMensagem JSONPOSTMensagem() Mensagem msg = new Mensagem(); msg.nome = HttpContext.Current.Request.Form["nome"]; msg.texto = HttpContext.Current.Request.Form["texto"]; msg.data = DateTime.Now.ToString(); return metodo.postmensagem(msg, "JSON"); public TextoMensagem JSONUpdateMensagem(Mensagem msg, string id) texto = HttpContext.Current.Request.Form["texto"];

10 return metodo.updatemensagem(texto, id, "JSON"); #endregion É válido um comentário a respeito da classe HttpContext utilizada nos métodos POST. Esta classe é utilizada para interpretar e realizar requisições HTTP. Em nosso caso, a utilizamos para receber os dados contidos no Request Body da requisição POST (nome e texto) para montar nosso objeto do tipo Mensagem e passá-lo para a função que realiza cadastros no banco de dados. Seus principais atributos e métodos são: HttpContext.Current: possui os atributos HttpContext.Current.Request.QueryString[] e HttpContext.Current.Request.Form[] os quais recebem os valores de variáveis definidas no Request Body de solicitações GET e POST respectivamente. De acordo com a especificação do verbo GET, não devemos enviar dados com este método. Isto é função dos verbos POST e PUT, muito embora seja possível este tipo de requisição. Com isso definimos as operações a serem realizadas a partir da chamada de cada WebMethod, quando uma dada requisição é feita a uma das URIs definidas na seção anterior, finalizando a criação de nosso RESTful WebService. 8. Publicando o WebService no IIS (Internet Information Services): Podemos utilizar a ferramenta Publish do Visual Studio 2008 para publicar os arquivos necessários para a execução dos serviços em uma pasta que esteja configurada no IIS para receber chamadas. Certifiquese de que as configurações de autenticação e de alias da pasta compartilhada na web estejam corretas. Seu WebService deverá estar acessível através do endereço onde RESTWS é o alias definido no IIS para a pasta que contém os arquivos publicados. Os ISS 6.0 e 7.0 não aceitam os métodos PUT e DELETE por padrão. É necessário ativá-los. Para isto, é necessário instalar um novo componente do Windows chamado WebDAV, localizado dentro do componente IIS/Serviço Web em Adicionar ou Remover Componentes do Windows.

11 Além disto, é necessário configurar o IIS para que os arquivos.svc aceitem requisições PUT e DELETE. Na pasta do diretório virtual criado para seu WebService, vá em Propriedades, na aba Diretório Virtual Configurações. Uma lista de extensões de arquivo será aberta. Encontre a extensão.svc e adicione os métodos PUT e DELETE. 9. Consumindo o WebService através de uma página HTML/JavaScript. Esta é, talvez, a parte mais complicada do processo. Com o Visual Studio e WebServices do tipo SOAP, bastaria adicionar uma WebReference ao projeto para ter acesso aos WebMethods e utilizá-los como funções internas ao projeto. Com RESTful WebServices isto não é possível. Devemos criar um client (no caso, uma Web-Page) capaz de realizar chamadas HTTP a partir de diferentes métodos (os 4 definidos pelo nosso projeto: DELETE, GET, POST, PUT). Se você é familiarizado com o desenvolvimento Web, rapidamente perceberá um grande problema: Forms HTML não são capazes de realizar solicitações do tipo DELETE e PUT. Há uma grande discussão dentro da comunidade de desenvolvedores a respeito do release do HTML 5, o qual deverá trazer estas funcionalidades. Enquanto isto não é possível, temos aqui um grande problema. A nova maneira de escrever JavaScript, conhecido como AJAX (Asynchronous Javascript And XML), faz uso de objetos de conexão HTTP nativos dos principais navegadores para realizar transações dentro do protocolo. Desta maneira torna-se possível especificar as URIs de destino, os verbos HTTP utilizados na chamada e os parâmetros do Request Body. Com AJAX também é possível receber os dados em JSON ou XML (sendo mais comum o XML) e tratá-los, expondo-os, por exemplo, com tags HTML em uma página. 9.1 O código AJAX Primeiramente iremos considerar que tanto o WebService quanto a web-page consumidora estão hospedados em um mesmo domínio. Discutiremos os motivos desta separação de casos na próxima seção. Os fontes completos desta etapa estão disponíveis no Apêndice. Vamos nos reter a discutir alguns trechos de código e aspectos importantes do consumo de RESTful WebServices. Para realizar uma requisição por JavaScript (AJAX), devemos instanciar um objeto do tipo XmlHttpRequest. Este objeto é diferente em alguns navegadores, portanto, devemos detectar qual navegador estamos trabalhando e instanciá-lo de acordo. Para isso, usamos a função GetXmlHttpObject(); function GetXmlHttpObject() xmlhttp = null; try // Firefox, Opera 8.0+, Safari xmlhttp = new XMLHttpRequest(); catch (e) // Internet Explorer try

12 xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); catch (e) xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); return xmlhttp; function XMLListarBtn_Click () method = "GET"; url = xmlhttp = GetXmlHttpObject(); if (xmlhttp == null) alert("seu navegador não suporta AJAX."); return; xmlhttp.open(method, url, true); xmlhttp.onreadystatechange = XMLListarMsgs; xmlhttp.send(null); Então, adicionamos uma função ao botão XMLListarBtn em seu evento de onclick. Esta função utiliza o objeto XmlHttpRequest devidamente selecionado e realiza a requisição. No caso, do tipo GET. Cada mudança de estado na requisição (0: Não-Iniciada, 1: Aberta, 2: Enviada, 3: Recebendo, 4: Concluída) gera um evento. Estes eventos são tratados pela função explicitada no atributo onreadystatechange: function XMLListarMsgs () if (xmlhttp.readystate == 1) //diz que a requisicao está sendo carregada (...) //quando a request estiver concluída e a resposta for 200 OK if (xmlhttp.readystate == 4 && xmlhttp.status == 200) //mostra pagina (...) //se a request estiver concluida e a pagina nao for encontrada if (xmlhttp.readystate == 4 && xmlhttp.status == 404) //Not-Found (...) O atributo status recebe o valor do estado da requisição, tratados na Introdução (seção 1.2.1). Para mais detalhes sobre a leitura das respostas às requisições utilizando JavaScript, consulte os fontes comentados no Apêndice. 9.2 Cross-Domain Policy: Um problema para o AJAX Até agora consideramos que client e service estão localizados dentro do mesmo servidor (domínio). Em nossos projetos, dificilmente encontraremos esta situação.

13 Normalmente desenvolveremos clients para consumir WebServices de terceiros, localizados em outros domínios. Da mesma maneira, poderíamos desenvolver serviços que seriam consumidos por outros desenvolvedores que não residem sob mesmo servidor que nós. A Cross-Domain Policy proíbe o uso de JavaScript para se comunicar diretamente com servidores remotos. Ou seja, não é possível realizar requisições HTTP utilizando o objeto XmlHttpRequest do AJAX para outros domínios. Para realizar tais requisições através de uma aplicação Web baseada em AJAX, devemos utilizar um servidor proxy. Este servidor recebe requisições HTTP e as encaminha para seus destinos finais, atuando como mediador na comunicação client-server. Uma aplicação deste tipo teria que ser escrita utilizando alguma linguagem server-sided como C#, Java ou PHP, por exemplo. Isto nos faz refletir em duas possibilidades: 1. Utilizar Web-Client baseado em AJAX com Proxy Server ver Anexo A; 2. Criar uma Web-Page utilizando linguagem server-sided; Na primeira opção temos a possibilidade de criar diversos clients diferentes e centralizar as requisições no servidor proxy, facilitando a manutenção do sistema. Outro ponto importante é que a renderização das páginas ocorre apenas no lado do client, poupando trabalho do servidor, que fica designado apenas para remeter as requisições ao WebService. Desta forma poderíamos ter diversos clients independentes e um único servidor proxy, todos localizados no mesmo domínio, onde o trabalho do servidor é de apenas repassar requisições e respostas. Para a segunda opção, cada client deveria atuar como servidor, para rodar a aplicação. Esta opção exige, além de clientes-servidores, que estas máquinas sejam capazes de renderizar todo o conteúdo das Web- Pages consumidoras e, ao mesmo tempo, realizar as requisições HTTP necessárias ao Web-Service. Isto gera uma grande quantidade de tráfego na rede, tornando as aplicações mais lentas. Existem bibliotecas Java e C# capazes de interpretar e realizar requisições HTTP de todos os tipos. Além disto, o PHP possui uma classe que utiliza métodos do CURL para realizar estas requisições. CURL é um programa de console freeware escrito em C capaz de realizar quaisquer tipos de requisição HTTP. Requisição no lado do Servidor Outra maneira de fugir do problema criado pela Cross-Domain Policy é realizar a requisição HTTP no lado do servidor. Utilizando C#, isto pode ser feito com as classes HttpWebRequest e HttpWebResponse, da seguinte maneira: /*** Cria HTTP Request para serv.baseurl ***/ HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); request.contenttype = "application/x-www-form-urlencoded"; request.method = method; HttpWebResponse response = (HttpWebResponse)request.GetResponse(); Stream responsestream = response.getresponsestream(); StreamReader responsereader = new StreamReader(responseStream); return responsereader.readtoend();

14 O parâmetro url é uma string e define a URI com a qual a requisição deve ser feita. O retorno deste método é uma string, que pode ser um documento XML ou JSON, conforme discutido nas sessões anteriores. O verbo http é definido no parâmetro method em formato de string: GET, POST, PUT ou DELETE, por exemplo. 10. Aplicação ao projeto X-GOV e ao conceito de Cross-Media Durante estas nove seções, discutimos a teoria envolvida na arquitetura REST, os conceitos do protocolo HTTP, como criar uma aplicação RESTful de WebService e como consumí-la. Nesta seção, iremos discutir como esta tecnologia pode ser utilizada no conceito de cross-media, especificamente com relação ao projeto X-GOV. No ambiente de cross-media, aplicações de celular, televisão digital interativa e Web sites convivem juntas. São meios de comunicação muito diferentes, residindo sob plataformas de desenvolvimento distintas e com poucas coisas em comum. Uma delas, é a principal função: transmitir informações. A interligação destas informações através das diferentes mídias existentes é a essência do cross-media. Torna-se necessário, então, que encontremos no meio de tantas diferenças algumas intersseções para explorar dentro das nossas necessidades. Uma aplicação independente de plataforma que se comunica através de um protocolo padrão e entendido por todas as mídias seria excelente. Esta é a deixa para a atuação dos WebServices em mídia cruzada. WebServices, tanto SOAP como RESTful, são portáveis, multiplataforma e se comunicam através de protocolos padrões. Um WebService pode ser acessado tanto por uma aplicação Web (ou Web-Mobile) como vimos anteriormente, quanto por uma aplicação de Televisão Digital, provendo interoperabilidade entre as mídias. O Projeto X-GOV pretende utilizar as diversas mídias, de forma interligada, para desenvolver um framework baseado em serviços de governo, capaz de facilitar o desenvolvimento de aplicações governamentais. Os diversos módulos do framework devem ser comunicar, acessar bancos de dados, interoperar entre as diferentes mídias e devolver informações ao desenvolvedor. Uma boa maneira de resolver todos estes problemas de comunicação interna é por meio de WebServices. Já discutimos anteriormente as vantagens do REST sobre o SOAP (ver seção 2), considerando apenas o protocolo HTTP. Como esta comunicação interna dos módulos do framework e, futuramente, das aplicações governamentais desenvolvidas a partir dele, exige grande agilidade e compactação dos dados transferidos, os RESTful WebServices aparecem como solução melhor que os SOAP. 11. Conclusão Após este estudo, podemos concluir que o projeto X-GOV pode utilizar os WebServices como meio de comunicação interna pois: a) São portáveis e multiplataforma; b) Utilizam protocolos padrões, reconhecidos pelas diferentes mídias; c) Garantem a comunicação cross-mídia;

15 d) São aplicações Web de fácil manutenção, desenvolvimento e uso; e) Podem realizar tarefas em diversos bancos de dados. Além disto, podemos dizer que as aplicações RESTful são mais eficientes que as aplicações SOAP para o projeto pois: a) Não empacotam grandes quantidades de informação; b) Utilizam métodos padrões de um protocolo padrão (HTTP) ao invés de métodos específicos para cada aplicação; c) Podem ser consumidos a partir de simples chamadas HTTP, não sendo necessário importar as classes e métodos do WebService, como feito em SOAP, para a aplicação cliente. d) Dentro do projeto, podem realizar as mesmas tarefas que as aplicações SOAP. Descrição do padrão: Anexo A: Aplicação do Proxy Pattern ao Projeto XGOV O Proxy Design Pattern faz com que clients de uma determinada aplicação se comuniquem com um representante desta aplicação, chamado Proxy, ao invés de se comunicarem diretamente com ela. Desta maneira, é mais fácil restringir o acesso à aplicação e garantir a consistência dos dados trafegados. Contexto: Um client necessita acessar serviços de outro componente, localizado em outra máquina, e uma conexão direta pode ser possível tecnicamente, mas não é a melhor alternativa. Problema: Normalmente não é apropriado acessar um componente diretamente, pois se faz necessário codificar a conexão diretamente no client, o que permite acesso sem restrições ao serviço. Isto gera ineficiência e insegurança ao sistema. Uma solução para este problema deve satisfazer ao máximo as seguintes exigências: Solução: a) O acesso ao componente deve ser em tempo-real, de baixo custo e seguro para ambas as partes; b) O acesso deve ser claro e transparente para o cliente. Ele deve saber para onde está sendo redirecionado e quais etapas do processo estão sendo executadas. O client não deve ter que alterar o comportamento e sintaxe de suas requisições; Faça com que o client se comunique com um representante da aplicação original, ao invés de se comunicar diretamente à ela. Este representante deve oferecer uma interface igual ou semelhante à original, porém pode agregar procedimentos antes e após a requisição, como autenticação, e garantir apenas a leitura dos dados, não permitindo alterações ou gravações diretamente. Implantação: 1. Identifique todas as tarefas que o serviço original provê. Agregue estas tarefas ao Proxy. 2. Se possível, introduza uma classe abstrata que especifica partes comuns entre a interface do Proxy e da aplicação original. Procure fazer as interfaces o mais idênticas possível, para que o client continue pensando que está trabalhando diretamente na aplicação final.

16 3. Programe as funções extras do Proxy, como autenticação e validação de dados. 4. Remova dos clients e da aplicação original todas as funções que agora residem no client. 5. Faça a comunicação entre o Proxy e o original. Esta comunicação pode ser feita através de um socket, ponteiro, referência, porta, endereço, entre outros. 6. Remova todas as ligações diretas entre os clients e a aplicação final, substituindo-as por conexões análogas entre o client e o Proxy e entre a aplicação e o Proxy. Conseqüências: O uso de proxies torna a aplicação menos eficiente devido aos redirecionamentos. Normalmente este problema é compensado pela agilidade adquirida nos processos agregados ao Proxy, que antes residiam no client ou na aplicação original. Outro problema é o uso descontrolado de armazenamento e carregamento de informações em runtime. Isto torna a aplicação lenta e passível de problemas, conforme a aplicação cresce ou exige uma transferência de dados constante e volumosa. Os benefícios do uso de proxies são, essencialmente, a redução de custo do sistema e a eficiência gerada pelas funções agregadas ao Proxy. Além disto, um Proxy retira dos clients informações perigosas de localização do servidor dos componentes, na medida em que se torna mais parecido com a aplicação original. Uso do Proxy Pattern no projeto X-GOV O conjunto de componentes de módulos que o framework X-GOV disponibilizará depende de um grande fluxo de informação interna ao sistema, além de ter de gerir as informações que são requisitadas pelas diferentes mídias quando usadas pelos cidadãos. Toda esta comunicação deverá ser autenticada, para evitar fraudes ao sistema e garantir a segurança das informações contidas. Além disto, muitos usuários e diversas aplicações do framework farão uso de um mesmo conjunto de ferramentas e dados do sistema, o que torna a utilização de serviços web bastante plausível. Todos estes serviços farão a comunicação framework base de dados, framework framework e framework usuário. Este contexto se encaixa perfeitamente ao contexto apresentado pelo Proxy Pattern. Como é necessário esconder dos clients a localização do sistema e diversos métodos internos, autenticar usuários, gerir os dados fornecidos e tratar dos dados apresentados, uma comunicação direta client serviços se torna arriscada e inapropriada. Em muitos casos, a tecnologia empregada como no caso do REST e AJAX impede o acesso direto. Para resolver este problema, podemos adotar um ou mais servidores Proxy. Estes servidores fariam a mediação entre os clients, que podem ser dispositivos do usuário, webservices ou módulos do framework X-GOV, e os servidores de dados ou serviços. Desta forma, centralizamos as chamadas em determinados servidores, que serão responsáveis por garantir a autenticação dos usuários e fazer uma conexão segura com os serviços internos do sistema.

17 Referências Bibliográficas Sites: Wikipedia: realizando buscas por HTTP, REST e Status-Code. W3C: para tutoriais e exemplos AJAX. Vídeos: Getting Started with REST Starter Kit, por Aaron Skonnard. Disponíveis no site da MSDN; WCF: Developing RESTful Services, realizado no PDC 2008, por Steve Maine e Rob Bagby; Artigos: A Guide to Designing and Building RESTful Web Services with WCF 3.5, por Aaron Skonnard. Disponível em: Architectural Styles and the Design of Network-based Software Architectures, Roy Fielding, capítulo 5 Livros: PATTERN-ORIENTED SOFTWARE ARCHITECTURE Vol1. Pág: 263 a 275.