Zapt.In : Entendendo e brincando com os encurtadores de URL

Zapt.In : Entendendo e brincando com os encurtadores de URL

Quase todo mundo já deve ter esbarrado (e se perguntado sobre o que são) umas URLs estranhas com domínios mais estranhos ainda, como por exemplo: bit.ly/7XC3Lo, migre.me/ck3k, tinyurl.com/yge8jzg, j.mp/7XC3Lo e zapt.in/k. A maior parte do mistério é esclarecida quando clicamos num link destes e somos redirecionados para um outro site. Tratam-se de URLs encurtadas através de algum serviço de encurtamento de URLs (Wikipedia: URL shortening).

Bom, mas pra que precisamos disto. Afinal os browsers evoluíram para aceitar URLs de tamanhos gigantescos (não existe um consenso quanto ao tamanho máximo de uma URL, mas elas podem passar dos milhares de caracteres na maioria dos browsers e web servers). Na realidade existem várias utilidades para estes encurtadores de URL como facilitar a digitação e a verbalização de URLs (é melhor usar/ditar/digitar uma dezena de caracteres do que milhares de caracteres), permitir que URLs grandes fossem compartilhadas em mensagens SMS (imagine passar a URL toda deste post numa mensagem de texto) ou até mesmo fazer o tracking de clicks/visualizações de um determinado link. Mas a coisa decolou mesmo foi com a popularização do Twitter, que permite apenas mensagem com no máximo 140 caracteres. Ou seja, qualquer caractere é valioso ao se compartilhar um link em um tweet. Fica claro que na hora de compartilhar aquele link do torrent do Ubuntu 9.10 no Twitter é melhor usar a URL encurtada http://zapt.in/m com apenas 16 caracteres do que a original http://releases.ubuntu.com/9.10/ubuntu-9.10-alternate-i386.iso.torrent com 70 (e olha que esta é relativamente curta).

Mas como funcionam os encurtadores (ou compressores) de URLs?

Bom, na prática (pelo que vi até o momento), nenhum “encurtador” de URL faz realmente a compressão da URL. Entendendo como compressão de dados a utilização de algoritmos como o Lempel-Ziv (LZW – utilizado no winzip, gzip, etc) ou o Run Length Encoding (RLE – utilizado em máquinas de fax).

O que eles fazem, em geral, é construir uma função bijetora que leva cada URL longa para uma URL ou chave menor (e vice-versa), tentando minimizar ao máximo o espaço necessário para esta nova URL ou chave. Existem variações quanto aos modelos de funções de mapeamento utilizadas (algumas não sendo de fato bijetoras) e também em como as URLs menores ou chaves são geradas.

Para a geração das chaves, muitas vezes se utiliza um hash único calculado aleatoriamente (para evitar que se possa prever as sequências) ou mesmo uma chave calculada através da transformação de um número sequêncial (cada URL encurtada incrementa a sequência) utilizando uma base de representação maior do que a decimal. A idéia é utilizar menos posições (caracteres) para representar o mesmo número (índice). Por exemplo:

Número 70015 (setenta mil e quinze) representado em diferentes bases numéricas:

  • Base 2 (binária) : 10001000101111111 : 17 caracteres
  • Base 8 (octal) : 210577 : 6 caracteres
  • Base 10 (decimal) : 70000 : 5 caracteres
  • Base 16 (hexa-decimal) : 1117f : 5 caracteres
  • Base 32 : 24bv : 4 caracteres
  • Base 62 : IDH : 3 caracteres

Observe que para representar o mesmo número, podemos entre 17 e 3 caracteres (somente com os exemplos de representações utilizados no exemplo).

Me parece que o Migre.Me utiliza Base 62 e um índice sequencial de URLs, já o Bit.Ly parece usar Base 62, mas com algum esquema de sequenciamento estranho (talvez ele use algum particionamento do espaço a partir da URL original).

Bom, depois de mapear a URL original para uma encurtada, e armazenar isto num banco de dados, o que o “encurtador de URLs” faz é redirecionar um visitante que segue a URL encurtada para a URL original. De preferência os serviços utilizam o redirecionamento do tipo permanente (HTTP 301 – Permanent Redirect), já que este tipo de redirecionamento preserva as características da página destino para fins de web crawling, SEO, rankings, etc. Digamos que ele é o tipo de redirecionamento mais amigável com os motores de busca.

O interessante é que entre receber a requisição na URL encurtada e redirecionar o visitante para a URL original, o encurtador pode capturar vários tipos de estatísticas para aquele link. Ele pode contar quantas vezes o link foi clicado, qual o tipo de browser que foi utilizado, etc. Isto torna os serviços ainda mais úteis, podendo ser utilizados para medir taxas de conversão de clicks, eficiência de campanhas online, concursos e outros.

Joia, mas agora vamos falar do Zapt.In…

Bom, a idéia do Zapt.In nasceu há alguns meses quando este tipo de serviço começou a explodir pela rede: o Brasil ainda não tinha um encurtador de URL decentes – Leia-se: o Jonny Ken ainda não havia criado o Migre.Me ;-), eu trocava várias ideias sobre as possibilidades de um serviço destes associado ao BlogBlogs e o LiveStream com Manoel Netto e eu acabei me esbarrado em alguns domínios interessantes (bem curtos) como foi o caso do ZAPT.IN. Acontece que o tempo passou, muita coisa aconteceu e nunca rolou de fazermos o tal encurtado.

Mas como para tudo chega a sua hora, neste feriado (última semana) aconteceu o alinhamento planetário perfeito: a Isabella passou a semana em Uberaba, as coisas estavam mais tranquilas no trabalho e, no final de semana prolongado, minha mãe e irmã vieram para Sampa e passaram grande parte dos dias caminhando pelos shoppings e ruas do centro (com a Isa que já havia retornado), deixando o viciado em codar (eu mesmo) livre para criar, hehe. Amo muito tudo isto!!!

Bom, ai foi a hora de arregaçar as mangas, abrir o TextMate e começar a codar. Com algumas boas horas de coding e pesquisa consegui colocar a primeira versão (bem tabajara, mas lembrando que ‘shipping is a feature‘) para rodar na plataforma de Cloud Computing da Heroku. Na realidade passei mais tempo estudando algumas coisas (algoritmos, Heroku, Git, etc) do que codando, mas na hora de mandar brasa no “POG” e escrever o Zapt.In a coisa andou bem rapidamente.

É isto, agora o Zapt.In está no ar em versão nem-alpha-ainda. Claro, cheio de bugs, sem logo, sem layout, com poucas funcionalidades e sem a menor preocupação, ainda, com escalabilidade. Mas um dia ele chegará lá, para isto preciso da ajuda de vocês (para usarem, testarem e enviarem suas ideias).

Tá, mas por que fazer MAIS UM encurtador de URLs?

Esta é uma boa pergunta. O Brasil já tem o Migre.Me e existe mais de uma centena de serviços parecidos por ai. Então por que?

Ué, porque é divertido! ;-) Porque serviços como o BlogBlogs e vários outros nasceram assim. Porque não?

É isto, depois escreverei alguns posts sobre os desafios, os perrengues e as aventuras de colocar mais uma aplicação no ar. HeyHo!!!!