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!