Um Manifesto!

Como disse no texto sobre REST, a cerca de um ano comecei a estudar essa arquitetura. E que maneira melhor de conhecer uma tecnologia do que implementando-a?

Bom com esse intuito apliquei os principios de REST ao longo dos projetos que tive, em paralelo montei uma biblioteca com o pacote de classe uteis aos projetos, que consideirei estável este ano  e então publiquei. Pode conferir o projeto no PHPClasses ou se aventurar no GITHub. 

É um conjunto de classes para PHP que constitui o seguinte:

• RESTAction - Uma interface para ações a serem tomadas
• RESTController - Interface para os controllers que responderão as requisições
• RESTView - Interface para as classes responsáveis pelas respostas
• RESTRequest - Classe que contêm os dados da requisição feita
• RESTResponse - Classe para controlar a resposta
• RESTServer - Principal classe para o controle do fluxo das informações

O Objetivo principal é prover um meio fácil de mapear Métodos e URLs para Controller(ou métodos deste), assim o uso básico é o seguinte:

$rest = new RestServer;
$rest->addMap("GET","/user/[0-9]*","UserController");
$rest->addMap("POST","/user","UserController::insert");

Você escolhe um método HTTP, um padrão de URL (usando regex) e o controller ou até o método especifico.(Pode até mapear direto para uma View, mas isso é feio ;).

O RestServer é passado para o controller para este poder usar o que for necessário. RestServer prove as informações da requisição(URL, método, parametros, mime...) através do RESTRequest e permite configurar a resposta (headers, content...) pelo RESTReponse, além de possuir controle de autênticação.

Mais detalhes pode conferir nos arquivos do pacotes. 

Esotu migrando esta semana alguns projetos para o GITHub, para centralizar esses arquivos e para facilitar quem quiser acompanhar.

No geral são pacotes utilitários nos sistemas que produzo, e atualizo conforme a necessidade. Além disso mantenho ainda a página no PHPClasses.org para alguns pacotes quando já estão "supinpa".

Para quem se interessar: http://github.com/diogok. E o do phpclasses.

Have fun! 

Para meus estudos de J2ME, o primeiro aplicativo que concluí foi um jogo de pedra, papel ou tesoura: o Jan Ken Pon. 

Nele você joga contra um adversário que também tenha o jogo instalado, através de bluetooth. Basta que o oponente tenha o jogo que o aplicativo é lançado em ambos os celulares quando você o desafia ou é desafiado. Além de guardar o score de cada oponente.

Já é até um pouco antigo, mas estava esperando ser publicado no GetJar.com para "lançar" oficialmente.

Nele pude aprender melhor como funciona o bluetooth e os recursos de persistência mobile(RMS), usei o framework bluetooth Marge para o trabalho, que é muito bom. Também pude usar o *chato* (para ser gentil) do Push Registry, para lançar o aplicativo sob requisição.

Divirta-se. 

Um modelo de arquitetura para sistemas web que me chamou muita atenção um ano atrás(tanto que fiz dois trabalhos para faculdade sobre, que infelizmente perdi) foi o REST, elaborado por, nada mais, nada menos, que Roy Thomas Fielding, que participa de muita coisa importante para a internet, essa arquitetura descreve simplesmente a web como ela é.

Consiste em utilizar de os recursos base da web(o HTTP) para construção de webservices, sem overhead e envelopes extras, tornando a interação(e o desenvolvimento) simples e não burocrática, explora os recursos já prontos, suficientes e comprovada eficiencia(afinal toda a web usa) do HTTP. Usa os conceitos que tornam a web o que ela é hoje.

Um serviço REST(ou RESTful) é definido por recursos, que possuem uma representação e um estado, estado esse que pode ser mudado(ou transferido) através de ligações(os links). Não é tão complexo como pode parecer:

Recursos é o item a ser tratado, são por exemplo usuários, produtos ou artigos. A Representação desse recurso é a pagina a ser apresentada, como o HTML ou o XML ou o JSON, essa representação contém o estado do recurso. O Estado são os dados do recurso(nome, preço, texto...), o cliente muda o estado na aplicação através de links, requisitando estados diferentes e trocando o recurso. Links são muito importante, tudo deve estar "hiperlinkado".

Comparado com Orientação a Objetos, o Recurso seria o Objeto, o Estado é o próprio estado do objeto(os atributos) mas os métodos nós vemos logo adiante. A representação é a apresentação desse objeto em um formato de mídia. 

É assim que servimos páginas na web, uma página é um recurso demonstrando o estado da aplicação, e nós mudamos esse estado seguindo os links que nos são apresentados.

Mas e a implementação? Rest se baseia em duas tecnologias principalmente, são itens já muito bem testados e que usamos todo dia: URL (ou URI) e o HTTP.

Cada recurso possui um identificador, que é o seu endereço em um sistema. Cada recurso possui uma URI (Uniform Resource Identifier). Você requisita essa URI e lhe é devolvido o estado desse recurso.

O protocolo para RESTful webservices é o HTTP, dividamos ele em quatro partes:

• O Método da requisição (também chamado de verbo) define a ação que vamos tomar.(PUT, POST, DELETE, GET, OPTIONS, HEAD...).
• A URI da requisição define o recurso sobre o qual aplicar o método.
• E o Tipo (MIME/TYPE) define qual representação vamos renderizar e devolver. É o cabeçalho ACEPT-MIME em preferência a "extensão da URL".
• Com base nesses dados formatamos a Resposta e enviamos de volta ao consumidor.

Na prática funciona mais ou menos assim:

• Uma chamada HTTP "GET /user/login" exibe(get) os dados do usuário(recurso) no formato padrão, já que não especificado.
• O HTTP "GET /user/login/posts.json" retornaria os "posts"(subrecurso de usuário) no formato JSON.
• Já "POST /article" está inserindo um artigo, enquanto "POST /article/12" pode atualizar o artigo 12.(Poderia, ou até deveria, ser usado o PUT para atualizar, mas há controvérsias).
• A requisição "POST /article/12/comment" pode adicionar um comentário ao artigo 12.
• Seguindo assim, a ação de "DELETE /article/12/comment/2" exclui este comentário e "GET /article.xml" retorna a lista de artigos em XML. 
• Pode até usar "GET /article/12.pdf" ou "PUT /user/diogo/picture.jpg".

O que é mais importante aqui é a conformidade do uso do HTTP. Um requisição do tipo GET deve apenas retornar dados, nunca alterar nada. Uma do tipo POST deve atualizar ou inserir um recurso, idem para o PUT. Recuperar dados nunca deve depender de POST, e um GET nunca deve alterar nada. Isso é importante para manter a consistência da aplicação, e podermos confiar nos métodos. Dois acessos seguidos de GET(ou HEAD ou OPTIONS) em um recurso deve ter o mesmo efeito que três ou nenhum, enquanto POST ou PUT podem fazer diferença.

REST trás, pelo HTTP, bons recursos prontos para serem usados:

• Cache eficiente, através dos Headers devidos do HTTP (expires...).
• Autênticação, BASIC ou DIGEST
• Segurança através de SSL (HTTPS)
• Falta de estado(confusão aqui, leia a seguir), por falta de necessidade.

REST é stateless, isso que dizer que ele não mantém o estado do cliente. Bom, nesse caso não é o mesmo estado que falei mais acima. O Estado do Recurso são seus atributos, e são mantidos no servidor(Banco de dados, Filesystem...) e o estado do cliente é o ponto em que a aplicação que consume o serviço esta(ou a seção).

Dessa forma o fluxo ou ordem da navegação do cliente não afeta qual recurso vai ser apresentado, e nem o cliente precisa manter informação sobre em que ponto parou para poder fazer uma requisição.

Um bom link é o REST: Paul James, muito conteúdo bom lá. 

Como podem ver REST não é nada novo, já fazemos a web assim a muito tempo, mas agora temos uma forma mais elegante e um bom motivo para manter a simplicidade que faz da web o que ela é.  

Autoloading no PHP é uma forma prática de incluir classes ao contexto que ainda não tenham sido declaradas, eu já fiz um texto sobre isto. Serve para melhorar o problema de( lembrar de) fazer várias inclusões das várias classes relacionadas em um projeto Orientado a Objeto, e com a SPL o autoloading fica ainda mais flexível uma vez que se pode registrar mais formas de fazer essa inclusão (não use o modo tradicional, por favor prefira a SPL) .

Em sistemas de médio porte em diante(ou qualquer sistema com mais de 10 classes) o uso de autoloading é quase indispensável, já que é bem ruim a cada alteração na estrutura de classes atualizar os includes, mas pior que isso é ter que incluir muitas classes que provavelmente não serão usadas em determinados fluxos, gastando mais memória por requisição atoa. Esse é o principal argumento para o uso do autoload, e é suficiente.

Mas vamos além.

O primeiro problema no autoload é que a cada inclusão de classe a rotina escrita pelo desenvolvedor deve buscar a classe requisitada, isso pode levar a dois pontos:

• Rotinas grandes ou complexas para flexibilizar a inclusão.
• Padrões de nomenclaturas e pastas ruins e/ou restritivos.
• Gambiarras, mas como qualquer coisa pode levar a gambiarras então deixemos esse de lado.

As rotinas grandes podem representar um problema de performance, já que vão ser executadas várias vezes durante a requisição. Para uma requisição chegar ao autoload já é uma “perda de tempo”, já que é o ultimo recurso do sistema e ele tem que deixar uma rotina interna do interpretador para executar uma do usuário.

E os padrões de nomenclaturas podem engessar seu sistema ou mesmo produzir um design ruim de pacotes. EU ( minha opinião apenas), por exemplo, ODEIO o padrão Pasta_Pasta_Arquivo(.php) de nomes de classe que é adotado por muitos frameworks e sistemas, da mesma forma que gosto de colocar as classes nas pastas de seus pseudos pacotes e com nomenclatura NomeDaClasse(.class.php).

Por exemplo, se eu quero usar o Zend framework mais o Outlet e mais um pacote próprio, eu tenho três padrões de nomes a usar e um problemão para o meu autoload (falta de padrão na aplicação causa problemas de qualquer forma, não é culpa da ferramenta).

Isso é melhorado com a entrada dos Namespaces, já que podemos interpretar a estrutura de pastas de forma semelhante com a dos namespace e manter o nome de nossas Classes limpos e precisar de menos “advinhações” para saber aonde esta o arquivo desta classe. Tornamos o autoload mais rápido e prático e deixamos a definição de nomes mais flexíveis.

Apesar do que escrevi, nenhuma dessas razões faz deixar de valer a pena usar o autoload. Além disso, o autoload somado as capacidades de reflexões do PHP nos dá uma poderosa arma.

Já que, virtualmente, todas as classes vão passar pelo autoload, seria realmente fácil criar uma classe padrão que garantisse alguns métodos básicos e estender as classes requisitadas no tempo de carregamento, ou ainda uma classe base para cada pacote da aplicação, assim um controller já estenderia uma classe, uma view outra. Podemos ainda criar classes “onTheFly” ou avaliar anotações e comentários.

Enfim, isso nos traz boas possibilidades que os frameworks podem aproveitar, mas tentem não me obrigar a usar mais padrões próprios e nem alterar minha modelagem para isso ;)