/Desenvolvimento

voltar
/Desenvolvimento

Exemplo de integração REST entre servidor e cliente

PorDaniel Schmitz em

Este é o nosso segundo artigo sobre a arquitetura REST. No primeiro artigo, nós propusemos que a arquitetura REST é uma evolução em relação a MVC, no que diz respeito à separação entre dados e visualização. Neste artigo, iremos reforçar essa separação, além de apresentar um exemplo simples envolvendo as linguagens PHP, jQuery e Flex.

Ao imaginarmos como essa separação é importante para futuros sistemas, podemos fazer uma analogia entre duas pessoas conversando em idiomas diferentes. Se você fala português e quer conversar com um russo, ou você aprende russo (e vice-versa) ou não haverá comunicação. Esse é o MVC, se você obtém dados de um banco e quer exibi-los no navegador do cliente, você deverá aprender como obter esses dados e como exibi-los segundo o framework que está usando. Para resolvermos o problema da comunicação entre você e o russo, podemos adicionar uma terceira linguagem no meio, por exemplo o inglês: você pode perguntar em inglês e o russo responder em inglês e, a partir desse momento, haverá uma comunicação. Mesmo que o russo pense em russo, se na hora de responder ele usar o inglês, você entenderá!

Fazendo uma analogia com o MVC, você precisa de algo em comum entre o servidor e o cliente, algo que todos possam entender. Se o servidor responder nesse padrão e o seu cliente souber ler esse padrão, a comunicação será realizada independentemente de tecnologia. E esse padrão é justamente a linguagem JSON, ela é o elo entre servidor e cliente. Na figura abaixo, temos um exemplo completo de como funciona esse fluxo. Recomendo abrir em outra janela e acompanhar a sequência apresentada abaixo da figura.

Em 1, temos a requisição http feita do cliente ao servidor. Todo processo de acesso à camada de negócios começa com uma requisição HTTP, que é o processo natural de uma página Web. Essa “pergunta” deve estar em um formato conhecido pelo servidor (lembre-se da analogia de que você deve perguntar em inglês ao russo). Esse formato é REST, em 2, compreendido por pedidos POST ou GET (existem outros) e por um formato de URL que seja válido.

O serviço REST irá trabalhar esse pedido, realizar o processamento da camada de negócios e gerar uma resposta HTTP (3). Essa resposta também deve estar em um padrão (lembre-se, agora o russo está respondendo à sua pergunta). E esse padrão é o JSON, em 4, que é o formato de dados mais leve existente. Se a resposta é comum, em JSON, qualquer tipo de aplicação que souber usá-la poderá acessar o servidor e obter dados. Então, em 5, podemos criar layouts diferentes em tecnologias diferentes.

Uma observação importante que você deve compreender é que o servidor pouco sabe de quem o está usando, se é um dispositivo móvel, um computador ou uma geladeira. Alguém pediu a ele algo, e ele está apenas respondendo. No outro lado, o cliente não sabe o que está acontecendo no servidor, ele não sabe se é PHP, Java ou Rails. Ele não precisa saber, já que a resposta em JSON é o que definitivamente importa para ele.

E como isso pode salvar o seu projeto? Como ambos (cliente e servidor) “não se bicam”, você pode trocá-los à vontade, contanto que respeitem o REST. Pode-se melhorar o servidor, trocando de framework ou tecnologia, como pode-se melhorar o cliente e, o mais importante, ter múltiplos clientes. No momento em que você enxergar que somente com um código no servidor poderá ter um cliente web, outro mobile, outro no tablet e mais um em um dispositivo embarcado, você começará a ver que a tendência do desenvolvimento de software é separar dados de sua visualização.

Para fixar, vou comentar um caso pessoal em um projeto de que participo. Nós criamos tudo em PHP e usamos cakePHP para a view, isso em 2007. Até aí, tudo bem, mas veio o Adobe Flex e decidimos portar a tecnologia para ele, usando AMF. Isso envolveu mexer 100% na view (criá-la de novo), e mexer 50% nas regras de negócio para se adequar ao AMF. Depois de pronto, tudo ótimo e todos felizes! Mas, agora, o Flex vai ser trocado pelo sencha e o cliente precisa de portabilidade para tablets (Android). Novamente, estamos alterando 100% view (descarte) e 50% do servidor que, claro, agora usará REST. Na próxima mudança de tecnologia, ou se formos adicionar uma nova view, basta respeitar o REST que não precisaremos alterar em nada o servidor.

Exemplo prático

Chega de blábláblá! Vamos a um exemplo! Inicialmente, vamos criar algo muito simples, apenas para entender o processo como um todo. Você precisará de um servidor Apache/IIS com PHP . Não mostrarei como instalar isso para não perder o foco, mas, resumindo, você pode instalar o WampServer em seu Windows. Se você tiver dúvidas sobre isso, comente que eu te ajudo.

Com o WampServer instalado, sabemos que ao acessar http://localhost/ estaremos acessando o diretório web root do apache, que fica precisamente em c:\wamp\www, caso tenha instalado o wampserver no padrão. Nesse diretório, vamos criar um arquivo chamado json.php, que irá simular uma saída JSON. Vamos lá:

<?php
//Uma simples saída JSON
$object = new stdclass();
$object->mensagem = "Hello World!";
echo json_encode($object);
?>

Esse código produz a seguinte saída no navegador:

A resposta que você vê no navegador é uma representação em texto do objeto que foi criado através do stdclass do PHP. Essa representação segue um formato que você pode entender melhor em www.json.org. Independentemente do cliente que vai consumir essa resposta, ela também usará a notação JSON para voltar com a string serializada em um objeto.

Lendo a resposta através do jQuery

jQuery é uma biblioteca JavasScript que, se você não a conhece, você não é programador web. Vamos criar o arquivo c:\web\www\json-jquery.php e implementar a leitura do json pela biblioteca (o que também chamamos de ajax, você conhece?). Segue o código:

<html>

<head>

<title></title>

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>

</head>

<body>

<form>

<input id="go" type="button" value="Diga ola ao REST"/>

</form>

<script type="text/javascript">

$(document).ready(function() {

$('#go').click(function()

{

$.ajax({

url: "json.php",

dataType: 'json'

}).done(function(data) {

alert(data.mensagem);

});

})

});

</script>

</body>

</html>

Melhor formatado:

Esse código usa jQuery para realizar uma requisição HTTP ao arquivo json.php, que já está respondendo em JSON. Como no objeto ajax do jQuery foi configurado que o formato é JSON, a resposta será convertida para um objeto JavaScript. Esse objeto é a variável data, na qual faço um alert de data.mensagem.

Perceba que $object->mensagem do php foi lido como data.mensagem no Javascript.

Lendo a resposta com Flash Builder

Flash Builder é uma ferramenta para criar aplicações ricas com Flex, e você pode usá-la para consumir novamente o arquivo json.php, mostrando assim que temos duas tecnologias completamente diferentes lendo o mesmo servidor. Não é o foco deste artigo mostrar como usar o Flash Builder, mas você pode seguir as imagens a seguir para ter uma boa ideia de como funciona. Inicialmente, criamos o projeto Flex, que chamamos de “json-flex”:

Após criar o projeto, vamos acessar o servidor. Para isso, na aba Data/Services, clique em “Connect to data” e escolha o método HTTP:

Clique em next e configure o nome do serviço e o método, conforme a tela a seguir:

Após criar o serviço, vamos testá-lo. A meta aqui é somente testar o acesso e ver a resposta, sem nenhuma tela. Para isso, clique no método getHelloWorld e acione o menu “Test Operation”. Clique no botão “Test” e veja a resposta:

Veja que, com o Flex, conseguimos ler o mesmo conteúdo que o jQuery leu. O cliente é diferente e a forma de configurar também, mas como o padrão de resposta é o mesmo, podemos usá-lo para na tecnologia que desejarmos.

Todo o objetivo do nosso sistema será este: separar a camada de dados e de visualização, se possível inclusive em equipes diferentes, de forma que cada uma possa concentrar seus esforços no que realmente interessa. Assim, começamos a desmistificar o REST, apresentado aqui com uma arquitetura onde existe um padrão de comunicação entre diferentes tecnologias. Até então não abordamos teoricamente o que é REST, e não vamos fazer isso por enquanto, dedicando-se apenas a prática.

Com isso, terminamos nosso segundo artigo e no próximo iremos abordar com mais detalhes a tecnologia REST para servidores PHP.

Aguardem e contribuam com sugestões!

Deixe um comentário! 30

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

  1. Pessoal, escrevo para a iMasters faz 9 anos, sempre esporadicamente… Mas estou tentando me dedicar mais a isso e dependo de vocês me ajudarem nessa tarefa. A minha motivação é diretamente proporcional ao retorno de vocês e como existem muitas tecnologias a serem abordadas hoje em dia, eu criei uma forma de poder reunir e analisar quais seriam os meus próximos artigos.
    Para me ajudar, acesse http://artigos.userecho.com/ e contribuam votando ou sugerindo artigos. O retorno de vocês é muito importante!

    1. Antes que venham “as bombas” :) não há nada de REST neste artigo, mas ele é vital para que possamos entender como o REST funciona. Próximos artigos veremos RESTful que vai abordar melhor este processo. Até lá :)

      1. Daniel, devo meus sinceros parabéns, seus artigos são bem explicativos e práticos, estou ansioso para o próximo!

        Estou trabalhando em um projeto semelhante, só que estou usando AS3 com AMFPHP.

  2. Você está de parabéns. Seus textos são bens escritos e num tom correto de programador para programador, claro, além de ser muito fácil de entender. Muito diferente de textos arrogantes e mal feitos que se vê por aí.

    Abraços.

  3. Parabéns Daniel… muito melhor assim, mostrando na prática e bem comentado… passo-a-passo…

    Dá de 1000 em textos super-técnicos e que são feitos para uma elite que provavelmente nem entende direito e finge que entende, hehehehe… do seu modo, alcança qualquer tipo de leitor, desde o de conhecimentos avançados até o iniciante!

      1. Verdade… alguns assuntos apesar de necessários, são realmente maçantes… mas faz parte, hehehehe. Cada ponto com seu público ou críticos. E se houver crítica que seja de forma civilizada para ajudar a construir!

        Parabéns Daniel, provou que é um escritor completo, escreve temas de todos os sabores; não tem pra ninguém. Aliás, tem pra todo mundo ;-D

  4. Cara, muito show essa coisa de REST. Será que grandes sistemas como o Magento podem vir a adotar esse padrão um dia? Eu pelo menos vou adotar. Valeu, pode continuar tranquilo com os artigos cara!

      1. Daniel …eu tenho outra duvida….eu fiz o download desse solftware e o instalei…só que quando eu fui programar html as letras naum ficam coloridas e tb quandu eu começo a digitar uma palavra esse programa naum me dá as opcões(o resto da palavra)…eu queria saber o motivo…ce sabe???

  5. Adorei o artigo, mas não entendi a diferença entre REST e WebServices, pois me parecem a mesma coisa. Poderia me ajudar a entender a diferença? Obrigado e Parabéns!

leia mais