O termo computação em nuvem ficou difícil de definir nos últimos anos. Não dá pra explicar o que ele é sem decorar um monte de letrinhas e conceitos. Decorar as letrinhas é legal, mas saber um pouco da história por trás delas é mais legal ainda. Prometo ser breve!
Tudo começou com virtualização. Se você não conhece o termo, vou dar uma boa definição que serve pra enrolar alguém numa conversa de bar: Com virtualização você pode rodar várias máquinas virtuais menores em uma única máquina real.
Resumindo bem, o termo cloud estava perto de nascer quando descobriram que era possível automatizar a criação e manutenção de máquinas virtuais. O termo nasceu mesmo quando alguém decidiu expor essas automatizações como serviços. Com poucas chamadas de API, você pode contratar um servidor, configurá-lo, aumentar sua memória, desligá-lo e por aí vai.
Essa aí é a primeira sopa de letrinhas, IaaS: Infrastructure as a Service, e isso ficou bem popular. Um monte de gente começou a contratar servidores virtuais pra hospedar sites de tamanhos quaisquer.
Isso tudo é muito legal, mas você ainda é responsável por instalar o sistema operacional, mantê-lo seguro, configurar o banco de dados e tudo mais. Era muito mais simples na época que você contratava um servidor PHP/MySQL com tudo pronto e só subia a aplicação.
É aí que o PaaS: Platform as a Service nasceu. Ele tem toda essa automatização que o IaaS tem pra contratar, subir e manter servidores, mas esses servidores já nascem configurados pra rodar a aplicação que você quiser instalar, de forma similar a um servidor de hospedagem tradicional.
Acredite se quiser, REST não é aquele formatinho babaca pra montar APIs. Ele é fruto de uma dissertação sobre filosofia em informação que descreve um estilo arquitetural de software. Doidera né?
É mais simples do que parece. Vamos fingir que arquitetura é “Como organizar elementos de software para atingir objetivos pré-determinados”, e que um estilo arquitetural é “um conjunto de diretrizes para organizar elementos de software com objetivos pré-definidos”. Conhece estilos de música? É similar: “heavy metal” está pra “REST” assim como “música” está pra “arquitetura”.
Como eu ainda não confio em vocês, eu vou fazer só mais uma analogia pra garantir que tá tudo certo. Da mesma forma que heavy metal tem que ter certos instrumentos e um conjunto de músicos pra conseguir obter o som característico do estilo, o REST tem alguns certos aspectos e mecanismos que o identificam.
Ah, e da mesma forma que alguns se dizem heavy metal mas não são, existem softwares que dizem ser RESTful e não são. À propósito, REST é substantivo, RESTful é adjetivo.
Parece ambicioso, mas o REST possui soluções para todos os problemas que temos hoje em aplicações web. Muitos desses problemas e suas soluções foram escritas na dissertação original:
- Performance, o quão rápida a aplicação é.
- Performance de rede, o quão rápida é sua comunicação.
- Eficiência de rede, o quão mínima é sua comunicação.
- Performance percebida, o quanto o usuário percebe de rapidez.
- Escalabilidade, o quão bem sua aplicação cresce.
- Simplicidade, o quão fácil de compreender e testar a aplicação é.
- Manutenibilidade, o quão fácil é modificar a aplicação.
- Extensibilidade, o quão fácil é estender sua aplicação.
- Modificabilidade, o quão fácil é customizar sua aplicação.
- Configurabilidade, o quão fácil é de configurar a aplicação.
- Evolubilidade, o quão fácil é manter o que já existe funcionando.
- Reusabilidade, o quão fácil é reusar sua aplicação.
- Visibilidade, o quão fácil é monitorar sua aplicação.
- Portabilidade, o quão fácil é fazer sua aplicação rodar em qualquer lugar.
- Confiabilidade, o quão confiável é a sua aplicação.
Parece bom né? Aqui acaba o texto. Obrigado!
O texto não acabou não, fica aí =D
Os doces estão ali na sessão acima, mas pra comê-los você terá que obedecer algumas regrinhas que o REST impõe. Sorte nossa que ele não é mala. Essa primeira regra é quase uma fase bônus: pra você ser RESTful, você tem que ter distinção entre cliente-servidor. Se o browser está independente do servidor, parabéns.
Isso pode parecer idiota, e às vezes pode ser tentador fazer um romance entre cliente e servidor, mas lembre-se que foi a separação entre esses que permitiu que servidores como o Apache não dependessem de navegadores como o IE6 para evoluirem.
Resumão: Sua aplicação opera trocando mensagens entre cliente e servidor.
Esse é o vestibular do REST. Quem não compreende essa regra não consegue ir muito longe nas outras, então preste atenção: O cliente conhece o estado do servidor, o servidor não conhece o estado do cliente.
- O cliente sabe se está logado ou não, o servidor só olha o crachá a cada requisição.
- O cliente sabe em que página está, não o servidor.
- O servidor não conhece a requisição passada (embora ele possa saber dados que foram transferidos nela, jamais seu significado ou ordem).
- Não use Cookies.
É isso.
Resumão: As mensagens entre cliente e servidor devem ser atômicas.
Esse aqui é o curso profissionalizante do REST. Se você compreende essa regra, você aprende a obter as principais características para web hoje em dia: performance e escalabilidade.
A principal preocupação de um iniciante é fazer trabalho o mais rápido possível, de um experiente é fazer o mínimo trabalho possível. É aí que o cache entra.
Uma prática comum em bancos de dados é o cache de consultas. Ao invés de apenas otimizar a consulta e os índices, se a mesma consulta for executada muitas vezes em um determinado período de tempo, os resultados são cacheados, diminuindo o número de consultas lentas e diminuindo o tempo do processador ao todo.
Cache em REST é a mesma coisa, só que você faz isso com o protocolo inteiro. Tudo que navega na web e pode ser cacheado é suportado pelo REST: vídeos, trechos de arquivos de vídeos, imagens, documentos, redirecionamentos, estilos, emails, sistemas de arquivos inteiros.
Resumão: As mensagens entre cliente e servidor podem ser cacheadas.
E se alguém te dissesse que existe um conjunto de camadas no protocolo intimamente relacionado com o conjunto de camadas do seu domínio na aplicação?
Ferramentas de cache, content network distribution, balanceadores de carga e proxies podem todas ser implementadas por camadas HTTP.
Resumão: Pode haver um ou mais caras em qualquer ponto entre o cliente e servidor.
Essa só tem o...
Resumão: A aplicação pode ser feita em qualquer linguagem, mas ela distribui alguns pedaços pro cliente rodar em linguagens comuns como HTML, CSS e JavaScript.
A última e definitiva.
Sabe quando você visita uma página e clica em um link ou vê uma imagem? Esse link pode ir pra qualquer lugar, e uma imagem mostrando qualquer coisa pode vir de qualquer lugar.
Vamos um pouco além. Sabe quando você clica no botão Like do Facebook em alguma página da web? Esses dados estão saindo de uma página X e indo para a página Y.
Quem permite todas essas coisas simples e maravilhosas é a interface uniforme do HTTP, que é RESTful. A web funciona mais ou menos assim:
- Traz Banana
- Envia Abacate
- Traz Laranja
- Traz Laranja Lima
Só que um pouco mais assim:
- GET Banana
- POST Abacate
- GET Laranja
- GET Laranja Lima
Ou talvez assim:
- GET /home
- POST /articles
- GET /tags/
- GET /tags/architecture
Bem melhor. Sabe o que não está claro aí? Qual é a ordem. Sabemos que uma sequência dessas gracinhas faz o usuário feliz, mas como eu guio ele para a próxima? Qual é a próxima? Quantas próximas existem?
Links resolvem esse problema, sempre que você GET algo, esse algo pode ter links pra você fazer GET ou POST em outro lugar. O usuário pode até escolher que links ele carrega automaticamente, como imagens.
Resumão: As mensagens entre cliente e servidor tem que ser semânticas.
A ser continuado...