Bom, depois de traduzir um artigo, e conhecer a incrível tradução de Machado de Assis para o … português, o assunto de hoje é tradução.

Poderia falar horas sobre isso, mas o foco aqui será apenas na tradução de uma palavra, que os desenvolvedores fazem (ou fizeram, ou ainda farão) confusão. A razão é que em alguns posts que estão por vir essa confusão pode acontecer.

PADRÃO é uma palavra das mais usadas atualmente, na área de informática . A confusão acontece pois duas palavras em inglês têm a mesma tradução pattern e standard, ambas são “padrão”, mas são “padrões” diferentes e por favor não os confunda, pode ser prejudicial a você.

Agora vamos a semantica da confusão. O padrão “standard”, como em “webstandard”, como os padrões da w3c significa uma norma, ou um padrão de qualidade. Como exemplo temos, o padrão de qualidade do inmetro ou as chaves de boca e as respectivas porcas que são construídas obedecendo uma norma ou padrão para que se encaixem. Ou seja padrões “standard” são para ser seguidos.

Por outro lado padrões “patterns” são modelos a serem repetidos ou serem usados como guia. Entre estes estão os “design patterns”, “architectural patterns”, entre outros. Exemplos de “pattern” são o reconhecimento de padrões (ou seja reconhecimento de repetições) ou padrões utilizados por exemplo nos azulejos. Ou seja, padrões patterns são algo que se repetem comumente ou podem ser usados como referência.

E antes que você ache que MVC, REST são padrões como HTML e CSS que devem ser usados (corretamente de preferência), tente descobrir sempre que ler/ouvir sobre um “padrão” se ele é um “standard” ou um “pattern”.

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