Quando fazemos uma reflexão sobre o desenvolvimento de sistemas, supondo desde 1995, podemos observar que o termo evolução está intimamente ligado a separação entre dados e conteúdo. Vamos voltar a 1995, quando o web estava nascendo e não havia praticamente nada definido em termos de sites e aplicações 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 separação entre duas camadas: modelo e visão.

Com o passar dos anos, o desenvolvimento web ganhou força 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 conteúdo e o modelo de negócios deveriam estar separados em camadas, sendo controlados através 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 evolução aponta nesta direção; cada vez mais os dados estarão separados da tela que o manipula, da camada de visualização.

Dada esta introdução, vamos agora ilustrar como uma empresa de desenvolvimento de software atravessa diversos problemas na criação de sistemas:

Vamos supor que a empresa entrou em operação em 1995, no começo do Delphi, e começou bem porque estava usando uma das melhores ferramentas da época. O sistema em si era criado de forma a ter SQLs nos próprios formulários (TForm, alguém lembra?), e com isso surgiram os primeiros problemas daquela época. Como manter o código 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 força. Existiam diversas vantagens em ter um sistema web, e mesmo com poucos componentes disponíveis, a empresa migrou o sistema para a linguagem PHP 3 (alguém lembra do .php3?). Veja que a empresa mudou de linguagem e manteve o seu padrão “despadronizado” de código. Os SQLs que manipulavam dados estavam misturadas a tags HTML, o que gerou muita manutenção corretiva. Mais alguns anos se passaram e, apesar da empresa já possuir uma biblioteca de classes com as regras de negócio do sistema, o mesmo ainda tinha uma manutenção complexa já que exibir estes dados era complexo. Apesar dos dados estarem separados do conteúdo, era complexo manter isso. Então, veio o conceito MVC e de como tudo seria mais fácil se o padrão fosse implementado. Para se manter no mercado de forma ativa e competitiva, a empresa decide realizar mais uma migração, 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 visualização, 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 ascensão do HTML 5, a empresa se vê novamente em uma posição onde deverá alterar a tecnologia para se manter no mercado.

Chegamos então ao atual estágio 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 conteúdos existentes – sejam eles desktop, web ou mobile. Assim como a Web diminuiu o mercado desktop, o mobile está tomando o espaço do mercado web, e a empresa quer mudar de forma que esteja preparada para futuras mudanças no cliente.

Nos dias atuais, o melhor caminho a seguir é realizar uma mudança de paradigma entre o MVC e sistemas REST. O REST é caracterizado como um paradigma de desenvolvimento de software semelhante aos webservices, no qual um serviço (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 atômica, sem acoplamento entre as partes. Ou seja, o REST é usado para receber uma requisição HTTP e retornar uma resposta que na maioria das vezes contém dados.

Sistemas REST costumam possuir uma implementação totalmente separada entre dados e design, sendo que até o processo de desenvolvimento de software é separado. Existem diversas características que definem um sistema como REST, mas vamos nos contentar apenas com o básico por enquanto, que é o seguinte: um sistema REST recebe uma requisição 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 métodos que manipulam os dados, e depois decidimos quem vai usar estes dados. Com isso, nosso “núcleo” que manipula dados está invariável em relação as constantes mudanças de tecnologia em relação ao cliente. Poderemos usar Apache Flex, jQuery, javaFX, extjs, entre outros.

Vamos criar a partir deste artigo, uma série de artigos que explicam na prática como a teoria REST é aplicada, fazendo com que o núcleo que gerencia dados é o mesmo independente dos seus consumidores. Aguardem!