A evoluo do MVC para REST

22 de outubro de 2012 por Daniel Schmitz

Quando fazemos uma reflexo sobre o desenvolvimento de sistemas, supondo desde
1995, podemos observar que o termo evoluo est intimamente ligado a separao
entre dados e contedo. Vamos voltar a 1995, quando o web estava nascendo e no
havia praticamente nada definido em termos de sites e aplicaes web. Neste tempo, o
Delphi ganhava mercado e se tornou, nos anos seguintes, uma boa ferramenta de
desenvolvimento Desktop. Naquela poca, o conceito de MVC j era conhecido e se
iniciava um movimento rumo a separao entre duas camadas: modelo e viso.
Com o passar dos anos, o desenvolvimento web ganhou fora e, por volta do ano 2000,
linguagens como PHP e ASP estavam se consolidando no mercado, sendo que outras
surgiriam gradativamente. Independente da linguagem, o que se pode observar entre os
anos de 2000 e 2010 um crescimento muito forte do termo MVC. A sigla MVC
pregava que o contedo e o modelo de negcios deveriam estar separados em camadas,
sendo controlados atravs da terceira camada controller. Nos dias atuais, este termo
faz parte de qualquer tipo de desenvolvimento web, mas importante salientar que,
independente da sigla ou conceito, a ideia que DADOS e TELAS estejam separados.
A evoluo aponta nesta direo; cada vez mais os dados estaro separados da tela que
o manipula, da camada de visualizao.
Dada esta introduo, vamos agora ilustrar como uma empresa de desenvolvimento de
software atravessa diversos problemas na criao de sistemas:
Vamos supor que a empresa entrou em operao em 1995, no comeo do Delphi, e
comeou bem porque estava usando uma das melhores ferramentas da poca. O sistema
em si era criado de forma a ter SQLs nos prprios formulrios (TForm, algum
lembra?), e com isso surgiram os primeiros problemas daquela poca. Como manter o
cdigo se tudo estava misturado? Muitas foram as noites em claro para que os
programadores pudessem ter um software sem bugs para seus clientes.
Com o passar dos anos, o desenvolvimento web ganhou fora. Existiam diversas
vantagens em ter um sistema web, e mesmo com poucos componentes disponveis, a
empresa migrou o sistema para a linguagem PHP 3 (algum lembra do .php3?). Veja
que a empresa mudou de linguagem e manteve o seu padro despadronizado de
cdigo. Os SQLs que manipulavam dados estavam misturadas a tags HTML, o que
gerou muita manuteno corretiva. Mais alguns anos se passaram e, apesar da empresa
j possuir uma biblioteca de classes com as regras de negcio do sistema, o mesmo
ainda tinha uma manuteno complexa j que exibir estes dados era complexo. Apesar
dos dados estarem separados do contedo, era complexo manter isso. Ento, veio o
conceito MVC e de como tudo seria mais fcil se o padro fosse implementado. Para se
manter no mercado de forma ativa e competitiva, a empresa decide realizar mais uma
migrao, saindo do PHP e utilizando Ruby On Rails como framework, onde tudo est
bem separado. Tudo funciona bem at que a empresa decida implementar uma camada
rica na visualizao, j que poderia usar componentes mais complexos. Cria algumas
telas em Adobe Flex e tem uma extrema dificuldade em integr-la ao Rubi on Rails.
Agora, com o Flex em desuso e com a ascenso do HTML 5, a empresa se v
novamente em uma posio onde dever alterar a tecnologia para se manter no mercado.
Chegamos ento ao atual estgio de maturidade da empresa. Eles precisam novamente
alterar a tecnologia, de forma que a camada cliente possa mudar sem estar ligada a
camada de dados. Veja que a ideia dos desenvolvedores agora separar ainda mais o
MVC, de forma que os DADOS sejam trabalhados de forma independente nos mais
variados contedos existentes sejam eles desktop, web ou mobile. Assim como a Web
diminuiu o mercado desktop, o mobile est tomando o espao do mercado web, e a
empresa quer mudar de forma que esteja preparada para futuras mudanas no cliente.
Nos dias atuais, o melhor caminho a seguir realizar uma mudana de paradigma entre
o MVC e sistemas REST. O REST caracterizado como um paradigma de
desenvolvimento de software semelhante aos webservices, no qual um servio (que
podemos chamar de API) fornecido para consumo de forma independente. Em outras
palavras, REST garante que a troca de dados entre cliente e servidor seja feita de forma
atmica, sem acoplamento entre as partes. Ou seja, o REST usado para receber uma
requisio HTTP e retornar uma resposta que na maioria das vezes contm dados.
Sistemas REST costumam possuir uma implementao totalmente separada entre dados
e design, sendo que at o processo de desenvolvimento de software separado. Existem
diversas caractersticas que definem um sistema como REST, mas vamos nos contentar
apenas com o bsico por enquanto, que o seguinte: um sistema REST recebe uma
requisio HTTP (seja ela GET, POST, PUT, DELETE) e retorna uma resposta em
formato de texto, que neste caso usaremos um formato de dados chamado JSON.
Isso garante que podemos construir um sistema no qual nos preocupamos apenas com
os mtodos que manipulam os dados, e depois decidimos quem vai usar estes dados.
Com isso, nosso ncleo que manipula dados est invarivel em relao as constantes
mudanas de tecnologia em relao ao cliente. Poderemos usar Apache Flex, jQuery,
javaFX, extjs, entre outros.
Vamos criar a partir deste artigo, uma srie de artigos que explicam na prtica como a
teoria REST aplicada, fazendo com que o ncleo que gerencia dados o mesmo
independente dos seus consumidores. Aguardem!