Cannonball 0.2 lançado para testes

A versão 0.2 do Cannonball, um sistema de gerenciamento de conteúdo (CMS) escrito em PHP no qual estou trabalhando, está lançada. O projeto é de código aberto e pode ser baixado em: http://sourceforge.net/projects/getdown/.

O projeto aborda gerenciamento de conteúdo de uma forma diferente, funcionando em cima de um “motor” MVC e com orientação a recursos. O sistema ainda é um protótipo, disponibilizado apenas para testes, logo o código tem vários furos, processos redundantes e outros detalhes; a versão 0.3 deve trazer uma refatoração de código para as funcionalidades existentes, agora que o sistema já tem uma arquitetura razoavelmente bem definida.

Vou preparar um rascunho da documentação e um anúncio de lançamento mais completo, com mais detalhes sobre o projeto; neste meio tempo, fica o link para o download:

http://sourceforge.net/project/showfiles.php?group_id=236635

O repositório deve se tornar público ainda esta semana.

Web Services com REST e PHP

*Notei que a parte 1 deste artigo (esta que você está lendo) tem tido muito mais visualizações do que a parte 2, o que me deixou um pouco receoso; isto é uma introdução programática ao REST, uma abordagem apenas focada em código, ignorando boa parte dos conceitos. Isto é intencional, pois queria mostrar que do ponto de vista da escrita de código não é necessário nada absurdamente diferente do que você já faz; mas se você está lendo este artigo como um introdução ao REST eu recomendo que leia também a parte 2, na qual eu tentei abordar REST de forma mais conceitual,  para não sair por aí falando e fazendo besteira!

REST (Transferência de Estado Representacional, ou Representational State Transfer) vem ganhando cada vez mais espaço entre os desenvolvedores, e motivos não faltam: simplicidade, objetividade e mais várias outras vantagens que você vai acabar descobrindo por si mesmo. Até aí, tudo bem; novas tecnologias geralmente aparecem visando exatamente estas coisas. A genialidade do REST é oferecer tudo isto ao preço de… nada. Tudo bem, quase nada.

REST é um paradigma arquitetural, não uma especificação de linguagem ou de protocolo. Pra desenvolver aplicações RESTful você não precisa ler nenhuma das muito organizadas, porém nada objetivas especificações da W3C, nem aprender outra linguagem ou qualquer coisa parecida. REST se baseia nos mesmos métodos GET e POST que você sempre usou, e a parte técnica da coisa para por aí*.

Se você estranhou quando eu falei que “a parte técnica da coisa para por aí”, é isso mesmo que você leu: o resto é conceito e filosofia e, como qualquer coisa envolvendo tecnologia, vai acabar esbarrando em outras tecnologias. No entanto, este artigo visa uma introdução programática ao REST, e não vamos discutir absolutamente nada disto aqui.

Já que a parte técnica é tão pequena, vamos logo pra ela. A parte que mais consumiu meu tempo neste artigo foi decidir sobre o quê usar como primeiro exemplo. Não queria nada que envolvesse banco de dados, nem nenhuma estrutura complexa de diretórios, nem arquivos de configuração de servidor, nem envolvesse mais do que dois arquivos: o cliente e o webservice em questão. Pensei na seguinte função:

function soma($numero1,$numero2) {
  return $numero1+$numero2;
}

Mais claro impossível; esta função recebe dois valores e retorna a soma deles. Só isso. Esta vai ser o serviço oferecido: somar dois valores. Agora, vamos implementar isto de um jeito RESTful. O acesso vai ser feito por método GET, e os parâmetros vão se chamar n1 e n2 (que vão ser usados como os dois parametros da função soma). O conceito chave do REST é que tudo deve ser um recurso com um endereço único, e a manipulação deste recurso acontece pela troca de informações através de um protocolo.

No nosso caso o protocolo é o HTTP, o endereço único é a URI do webservice e as informações são os parametros enviados via GET. Resumidamente, isto significa que para utilizar o web service para saber o resultado da soma de 2 + 3, basta acessar a seguinte URL**: seudominio.com/soma.php?n1=2&n2=3 E o web service (o arquivo soma.php) seria assim:

function soma($numero1,$numero2) {
  return $numero1+$numero2;
}
echo soma($_GET['n1'],$_GET['n2']);

Ao acessar a URL, o resultado da operação (neste caso, 5) é exibida no navegador. CERTO. Se você está lendo este artigo como iniciação ao REST, existem grandes chances de você estar pensando algo como “ou este cara está tentando me enganar ou alguém está tentando enganar todo mundo”. Respire fundo e analise bem a situação. Pense sobre os web services que você já desenvolveu, caso tenha desenvolvido, e no que eles faziam. Eu avisei que REST não envolvia nada de novo, é só uma maneira diferente de abordar as coisas.

Vamos implementar o cliente de um jeito diferente; ao invés de web, vamos fazer uma aplicação para rodar na linha de comando. O código é simples:

$resultado = file_get_contents('http://sdc/soma.php?n1='.$argv[1].'&n2='.$argv[2]);
echo $resultado;

Pronto! O método file_get_contents recebe um caminho de arquivo e retorna seu conteudo em uma string. No nosso caso, o “arquivo” é qualquer coisa que o nosso service retornar. Salve o trecho de código acima num arquivo chamado cliente.php e acesse agora via linha de comando:

php cliente.php 2 3

O resultado será:

5

Sendo que o processamento da soma aconteceu remotamente, no servidor, através do seu web service RESTful. Até aí, tudo bem. Mas não queremos viver num mundo onde os webservices se limitam a simplesmente retornar a soma de dois valores; se é pra ser assim, que pelo menos eles retornem isto num XML. Vamos alterar nosso código:

function soma($numero1,$numero2) {
  return $numero1+$numero2;
}
header('Content-Type: text/xml');
echo '<?xml version="1.0" encoding="iso-8859-1"?>';
echo '<resultado>'.soma($_GET['n1'],$_GET['n2']).'</resultado>';

Pronto. O resto agora fica a cargo da sua imaginação; não é difícil imaginar como extender isto para acessar bancos de dados e consequentemente realizar ações de entrada e persistência de dados (via POST) e recuperaçao de dados persistentes (via GET) ao invés de somente processamento de dados. Este artigo já ficou longo demais, e já cumpriu seu objetivo de dar uma visão geral sobre REST sob uma perspectiva prática.

Vale lembrar que o assunto é extenso, e merece ser estudado a fundo principalmente no que tange a arquitetura do seu sistema (afinal, REST é um estilo de arquitetura) e disponibilização de recursos.

* REST utiliza também os métodos PUT e DELETE, mas vamos ignorá-los aqui impiedosamente (se é que você já não os está ignorando a vida toda). Vários servidores não implementam esta parte do protocolo HTTP, e honestamente, não vejo porque se incomodar com isto, pelo menos por enquanto.

** Como eu disse, estou tentando simplificar as coisas; existem padrões de URL que vão de acordo com a filosofia de arquitetura de aplicações REST, e que merecem destaque em outros artigos. Neste caso, seria mais correto seria disponibilizar o serviço através de uma URL como “seudominio.com/soma/2+3″, mas falar sobre tratamento de URIs não faz parte do escopo deste artigo.