• 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.

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”.