Voltando a escrever

10 junho, 2008

Após um tempo sem escrever, algumas palavras:

  • Fiquei apenas com o notebook por enquanto, o desktop parece que queimou a fonte … O que me rendeu inúmeros problemas.
  • No momento estou trabalhando num projeto, então meu tempo para escrever diminuiu.
  • Fim de semestre pra quem estuda é sempre complicado, e comigo não é diferente.
  • Estou brigando feio com a AST de Lua para adaptar nos moldes do DLTK
  • Já que eu fiz o comentário, quem puder dê uma olhada no projeto LuaEclipse é uma IDE para Lua uma linguagem brasileira, que não deve nada para as linguagens atuais, só pra ter uma idéia ela é usada no World of Warcraft e também pela Adobe … Pronto, já fiz minha propaganda.

Mas as boas novas. O que vem por aí?

  • Vou continuar a série de explicações sobre REST, e colocarei um exemplo prático.
  • Ainda sobre REST, alguns tutoriais de Ruby on Rails, que é o framework que eu conheço que tem melhor suporte a REST.
  • Estou trabalhando num projeto de tradução de livros, é bem interessante, estou precisando de ajuda, mais detalhes em breve.
  • Consegui uma conta para teste da nova hospedagem de Ruby on Rails da Locaweb então como eu critiquei a hospedagem anterior, logo eu publicarei o que eu achei para ser justo.
Anúncios

Como início da explicação sobre REST resolvi traduzir o How I Explained REST to My Wife um texto antigo (2004), mas muito explicativo. Ainda empolgado como o Gil Giardelli utilizou várias citações clássicas, aqui vai uma pergunta que está no What do HTTP URIs Identify?.

O que a URL “http://www.vrc.iastate.edu/magritte.gif” representa?
A traição da imagem

  1. Um cachimbo.
  2. Não sei o que é, mas não é um cachimbo.
  3. Uma contradição.
  4. Uma pintura do Magritte
  5. A fotografia de uma pintura do Magritte
  6. Uma representação na forma de 341632 bits de uma foto de uma pintura.
  7. 4, 5 e 6 estão corretas, mas 1 não.

Nesses últimos dias acabei fazendo uma pesquisa informal com desenvolvedores web de vários níveis, desde quem está iniciando, a quem já trabalha a alguns anos com isso. E o resultado foi o que eu infelizmente esperava, nem todos sabem o básico. Estranho? Acho que não. Antes de continuar pense na resposta para a seguinte pergunta “Para que serve no protocolo HTTP os métodos GET e o POST e quais suas diferenças?”.

As respostas foram as mais variadas, algumas muito boas, melhores até do que a explicação que vou dar a seguir, mas a maioria foi focada nas diferenças, essa sim todo mundo sabe. O GET coloca os parâmetros na URL da requisição e o POST coloca os parâmetros no corpo da requisição. Exemplificando, quando você envia por um formulário por GET a URL expõe todos os parâmetros e o POST esconde-os. Ótimo isso é uma das diferença, mas não responde para que serve, pois o GET não serve para passar parâmetros e o POST pra escondê-los. Dos que se arriscaram a dizer para o que servia o POST a maioria respondeu assim: é para tratar submissões de formulários. Nada errado com a reposta, mas não é apenas isso.

Segundo a rfc do HTTP o GET serve para recuperar conteúdo, e o POST para enviar dados a serem processados. Mas não é isso que os formulários fazem? Sim, é. Mas o ponto é que muitos desenvolvedores acabam além de processar os dados exibindo conteúdo na requisição POST. Ou seja utilizando o POST para uma coisa que ele não foi feito para ser usado, a mesma coisa é passar os parâmetros a serem processados por GET. Mas, o que tem de ruim nisso?

Bom, usar uma ferramenta errada para o problema certo é algo certamente ruim. Mas desenvolvedores insistem no lema “Se tudo que você tem é um martelo, trate tudo como se fosse prego”, e acabam martelando muitos parafusos, mesmo tendo uma chave de fenda também. Que é claro, esses mesmo desenvolvedores não vêem que tem. Mas voltando a prática, o problema de exibir informações depois de um POST é que o browser guarda a última requisição para caso você queira fazer um refresh da página. Ou seja mesmo que não tenhamos um formulário na página, o usuário pode acabar reenviando os mesmos dados novamente apenas apertando F5 (ou ⌘+R), e isso logicamente é ruim. Usar GET para passar dados é mais sutil, pois a intenção do GET é ser uma requisição que não tenha efeitos colaterais, ou seja não mudem o estado de uma aplicação. Mas, o que eu ganho com isso? Bom, tem a ver com o fato de o HTTP ser um protocolo sem estado. Mas também tem a ver com a capacidade de você paralelizar sua aplicação, ou seja, rodar eficientemente em vários servidores. Mas para explicar isso é preciso saber o porquê de as linguagens puramente funcionais serem trivialmente paralelizáveis (vou explicar isso em um post futuro, mas se tem curiosidade, procure saber sobre isso, é algo que com toda certeza vale a pena aprender).

E como eu critiquei aqui por fazerem confusão com REST, que tem tudo a ver com métodos HTTP, os próximos posts vão ser sobre isso, afim de explicar este padrão arquitetural. Que não é tão complicado, é só pensar na razão de URL significar “Uniform Resource Locator”, ou seja “Localizador uniforme de recursos”.