A evolução do MVC para REST

PorDaniel Schmitz em

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!

Deixe um comentário! 65

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

  1. Excelente artigo!

    Acho que a grande maioria dos devs vão se sentir como parte dessa empresa que você citou pois hoje existe consenso entre os profissionais é justamente sobre a insegurança com relação ao futuro o que torna as decisões de médio e longo prazo difíceis de tomar.

    Temos ciclos cada vez menores e mais e mais conceitos e ferramentas surgindo e é extremamente necessário ter uma padronização em como tratar a parte de dados, não conhecia REST e esse artigo me deixou mais esperançoso sobre como trabalhar pensando no futuro sem ficar tão vinculado às novas tecnologias; (ou ao desuso de outras como parece estar acontecendo com o Flex.

    Estou ansioso pelos exemplos!

  2. Uma pergunta: visto esse design que o REST tem, não haveria perda de performance com esse método?

    Já que precisa-se formar os dados em JSON para depois serem traduzidos novamente em um formato de apresentação para os clientes…

    1. Sim, há uma perda de performance. Em termos práticos, se você fizer um select que retorna um milhão de registros, e converter isso tudo em json, haverá uma perda muito grande de performance. Para isso existe paginação, e você usa ela com certeza, já que ninguém cria um table em html com um milhao de linhas.

      O bom disso é que na paginação, você retorna 20, 30 registros, e essa perda de performance em converter e desconverter é insignificante. Resumindo, há uma perda insignificante em conversão se você fizer direito.

  3. Muito interessante, passei por isso recentemente na empresa onde estou desenvolvendo um projeto que utiliza o flash como frontend da aplicação, o backend é todo em PHP, e usei a arquitetura REST para disponibilizar os dados do backend atravéz do AMFPHP.

    Sinto a necessidade que essa arquitetura seja melhor divulgada, e que tenha artigos falando sobre AMFPHP, e SOA.

    Eu não escrevo nada pois tenho preguiça misturada com falta de tempo.

  4. Ótimo artigo! trabalho com php/codeigniter e estou desenvolvendo o app mobile usando a arquitetura REST, porém o meu site suportará a criação de aplicativos como o twitter e facebook. A dúvida é: A aplicação REST que estou desenvolvendo para os meus aplicativos nativos do meu site será a mesma aplicação que vou disponibilizar para a criação de apps por terceiros através de token e etc.. ?

  5. Daniel, seu artigo está equivocado de tantas formas que, além de dar preguiça, não seria prudente tentar esclarecer tudo em um comentário.

    Por favor comece apagando esse post, depois leia esses artigos [1][2], então leia um livro descente [3][4] sobre o assunto, de preferencia desenvolva pelo menos um sistema usando essa arquitetura, e só então volte a escrever um artigo a respeito.

    [1] http://en.wikipedia.org/wiki/Representational_state_transfer
    [2] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
    [3] http://shop.oreilly.com/product/9780596805838.do
    [4] http://shop.oreilly.com/product/9780596529260.do

    1. Você trabalha com o Luis Cipriani não é? Não foi atoa que postei no twitter q estava criando um artigo polêmico, já esperava críticas. Primeiro, se meu artigo dá preguiça de ler, me desculpe, não posso agradar todo mundo.

      O Post não será apagado, porque ele é uma série com exemplos práticos que os leitores gostam. Se eles compreenderem 10% do que o REST é, estou satisfeito. Não vou no primeiro artigo colocar toda a teoria REST, sei que ela é complexa e aí sim, os leitores vão dormir. Deixo a teoria complexa para os livros.

      A ideia aqui é abordar uma mudança de paradigma. Se hoje só falamos em MVC, vamos voltar nesse artigo daqui a 5 anos e rir da situação.

      1. Daniel, não leve tão a sério a forma “grosseira” do meu comentário, a idéia era ser o mais enfático e direto possível. Mas vamos aos esclarecimentos dos pontos mais críticos:

        A questão aqui não é a completude com a qual você trata o assunto, e sim o fato de simplesmente estar errado.

        REST não é “semelhante aos web services”, mas sim uma das formas de se implementar um. Nessa lista entram JSON|XML-RPC, SOAP, entre outros. Infelizmente o termo “web services” foi históricamente associado a SOAP e acaba causando confusão, mas considere o seguintes: ‘The W3C defines a “Web service” as “a software system designed to support interoperable machine-to-machine interaction over a network”‘ [1].

        Eu até entendi o ponto onde você queria chegar, e isso se chama Service Oriented Architecture (SOA), mas não tem absolutamente nada a ver com MVC, que como o Luis Cipriani já apontou, é um design pattern utilizado para separar as responsabilidades no contexto de uma aplicação, o que leva, além de outras coisas, a uma melhor manutenção e reutilização de código.

        Ninguém está deixando de usar MVC, ou qualquer outro design pattern, em função da adoção de arquiteturas orientadas a serviço. O que está acontecendo é que estamos cada vez mais implementando serviços na forma de APIs que são consumidos por outros serviços ou aplicações, que por sua vez podem ou não utilizar o padrão MVC em seu design. O principal shift aqui é que o Model (M), ao invés de acessar diretamente um banco de dados, acessa um serviço através de uma API, mas continua tendo exatamente a mesma responsabilidade que tinha: abstrair do resto da aplicação a lógica de negócio e o acesso aos dados.

        [1] http://en.wikipedia.org/wiki/Web_service

      2. Em nenhum momento disse que você era grosseiro. Apenas disse que se o artigo te deixa com sono, que não poderia agradar a todo mundo. E tb que nao ia tirar o artigo do ar. Obrigado pelos links, vamos aguardar os próximos artigos e que sabe, você até aceita o meu ponto de vista. Claro que eu vou ter que criar um artigo somente para lhe explicar o que estou afirmando, entre a evolução do mvc ao rest, será um artigo mais avançado e espero que lhe agrade.

    2. marcoshack@gmail.com, Você é mal educado. Você tem todo o direito de criticar determinado assunto, mas seja educado para que o seu comentário possa ser levado em consideração. Essa sua falta de educação e arrogância não ajudam em nada a esclarecer onde o artigo acerta e onde erra. Aproveito a sua arrogância para te dar um leve tombo, antes de sair por aí escrevendo grosserias, frequente aulas do seu idioma nativo. Abraços.

      1. Oi Denis, você acha mesmo que sou mal educado e arrogante? Coloquei até links para artigos e livros que nosso amigo poderia ler pra não falar tanta besteira, poxa. Mas sei que é bastante coisa pra ler, né? Então resolvi fazer um comentário mais educadinho esplicando os principais errinhos do artiguinho, tá bom?

        Abracinho.

      2. Quem manda o ‘s’ estar tão perto do ‘x’. Culpa do meu corretor ortográfico que não apontou o erro :)

    3. Marcos,
      por favor reveja urgentemente suas referências, pois wikipedia não pode ser considerada como uma fonte confiável (Não sei se você aprendeu isso na sua graduação, mestrado, doutorado).
      Gostaria de ver você publicar artigos tão bom quanto do Daniel, pois é muito mais facil para nós criticar enquanto do que sugerir educadamente uma contribuição para um trabalho como apresentado pelo Daniel.
      Considero as observações do Daniel pertinentes, porém um pouco mais futurista, mas valido tudo o que ele disse.
      Trabalho na área de pesquisa em universidades com Web Semântica, agentes inteligentes e utilizo muito REST, então sei bem do que estou falando.
      Sugestão mais uma vez: Sempre faça criticas CONSTRUTIVAS.

  6. É um absurdo sugerir que existe uma evolução do MVC para REST, seria a mesma coisa que sugerir que há uma evolução entre uma pedra e uma minhoca. REST é um conjunto de restrições arquiteturais para aplicações baseadas em rede de computadores; MVC é um design pattern.

    1. Olá, eu estou comparando conceitos e não designs. Se seguir o seu pensamento, é um absurdo comparar a nossa evolução, de uma bactéria no oceano até os mamíferos de hoje. Meu foco não é teoria, mas sim a visível separação de dados em cada processo.

      1. Repito: REST é um conjunto de restrições arquiteturais para aplicações baseadas em rede de computadores. Não tem como dizer que há visível separação de dados, pois isso não é nem o objetivo principal de uma arquitetura distribuída, cujo foco é a disponibilização eficiente dos dados entre os vários nós da rede. O desacoplamento que há é entre o conjunto de funcionalidades que o arquiteto decide colocar no client e no server de modo a otimizar o acesso.

        Dê uma olhada na palestra: http://www.infoq.com/br/presentations/rest-arquitetura-abril
        Isso vai te ajudar a entender melhor o que quero dizer.

      2. Luis,
        reveja urgentemente suas referências também, pois estas não podem servir como base para você realizar criticas em cima do trabalho do Daniel, você poderá estar se contradizendo. Eu não perderia tempo em entrar nos links que você e o Marcos colocaram para a gente validar o que vocês disseram.
        Sugestões: Pesquisa em bases cientificas reconhecidas, como:

        http://ieeexplore.ieee.org/Xplore/guesthome.jsp?reload=true
        http://www.sciencedirect.com/
        http://dl.acm.org/

    2. Sou completamente de acordo com MarcosHack. PORQUE:
      Se vc le alguma besteira numa pergunta é uma coisa. agora ler dizendo q Rest é evolução do MVC, nao tanto pelo fato de ser errado, mas o pior que o erro de nao saber, é a falta de humildade e a ganancia de querer aparecer como mestre e escrever artigos. sem ter discernimento. Cara me desculpe mas pra escrever tem q ler mais.

  7. Daniel Schmitz, por favor, não leve em consideração o comentário de pessoas que em nada agregam ao conteúdo do artigo, continue a série pois tem mais gente interessada do que gente que prefere se prender a pontos inúteis…

    Pessoas que se prendem a normas, nomes e siglas bonitinhas, e levam as as coisas somente ao pé da letra, são desenvolvedores burocráticos que para fazer um simples CRUD precisam antes fazer documentos e reuniões…

    Quem não gostou do material ou se sentiu ofendido por misturar MVC com REST, não leia o artigo, tome seu tempo livre para fazer um artigo melhor… Muito ajuda quem não atrapalha!!!

      1. A melhor coisa cara é você continuar com o tema e mostrar na prática como funciona… pq na nossa área de TI tem um monte de gente que fala que faz e acontece, e sabem apenas a teoria, quem critica tem que criar um tutorial melhor, coisa que nenhum dos que criticam fazem, acompanho os seus artigos e são todos muito bons.

  8. Pessoal, escrevo para a iMasters faz 9 anos, sempre esporadicamente… Mas estou tentando me dedicar mais a isso e dependo de vocês me ajudarem nessa tarefa. A minha motivação é diretamente proporcional ao retorno de vocês e como existem muitas tecnologias a serem abordadas hoje em dia, eu criei uma forma de poder reunir e analisar quais seriam os meus próximos artigos.

    Para me ajudar, acesse http://artigos.userecho.com/ e contribuam votando ou sugerindo artigos. O retorno de vocês é muito importante!

    1. Daniel,
      parabéns e não desista. A partir de hoje irei acompanhar mais teus artigos, pois entendo que comentarios como os vistos anteriormente não ajudam na construção de um mundo melhor. E certamente irei contribuir positivamente para que possamos disseminar o conhecimento.
      Existem muitas pessoas no meio da informatica que se acham “os caras” e vimos claramente isso nesses posts. Já trabalhei como muitos desses caras, e te garanto que atualmente eles estão excluidos do mercado, pois o mercado exige que cooperamos e trabalhamos em grupo, e certamente o pensamento dos colegas são totalmente ao contrario.

  9. Boa noite caros,

    Estou interessado em aprender mais aprofundadamente sobre REST, então, o que vocês me recomendariam de artigos, livros científicos sobre o assunto?

    Abs.

  10. Cara, o artigo é interessante, mas como o nosso português pode causar conflitos não é mesmo? acredito que o ideal para o título seria “A evolução do mvc COM rest” e não a evolução do mvc para rest. Bom é só uma dica, mas resolveria a maioria dos comentarios, lembrando que pra quem está começando agora, embasamento técnico e termos corretos são de grande importância!

    1. Pois é, “pior” que é “para” mesmo, pq se hoje o conceito de MVC está bem difundido, amanhã REST será a bola da vez. Claro que dá pra usar MVC no cliente e MVC no servidor, mas a comunicação entre eles será REST.

      Lembrando que virão mais artigos pra explicar tudo de forma mais clara. Tenho que fazer passo a passo para facilitar o aprendizado.

  11. Eu concordo com o marcoshack e com o Luis Cipriani. São conceitos diferentes, por isto não é uma evolução de um para outro.

    Você pode desenvolver REST usando MVC ou não. Uma coisa não tem a ver com a outra. Tanto que muitos frameworks MVC apresentam recursos para facilitar a criação de aplicações baseadas em REST (ou seja, uso de MVC numa aplicação baseada em REST).

    1. Sim, concordo. Mas como foi dito no exemplo, se hoje MVC é a bola da vez, amanhá será o REST. É desta evolução que estou falando. Mas o artigo é pra gerar polêmica mesmo, pra chamar a comunidade e fazê-la pensar, e não dizer que uma tecnologia vai matar outra, muito menos pra dizer que nao tem nada a ver.

  12. Engraçado que esses dias mesmo na faculdade fiz um trabalho a respeito de SOAP e RESTful.

    Não acho que tenha sido um artigo para dormirmos, acho que até poderia ter sido maior que não teria tirado o interesse no assunto , foi até interessante rever o passar dos anos e avanço da tecnologia focado em melhorar o desempenho e fazer o programador aprender a separar a bagunça .

  13. Daniel, primeiramente te dou os parabéns pela sequencia de artigos e pelo artigos.userecho.com.
    Gostaria de registrar a (eterna) confusão que se faz com o termo MVC. Ao contrário do que a maioria tem por verdade, o MVC NÃO É UM DESIGN PATTERN! Afirmo isso com base na origem do conceito (http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html). É um modelo de arquitetura onde existem 3 objetos fisicamente separados, cada um com sua função. Em termos práticos: criar 3 classes diferentes (Model, View e Controller) no mesmo “programa” não é implementar MVC. E REST é outra coisa, que você mesmo começou a explicar, e muito bem por sinal.
    Portanto, concordo que o título do artigo talvez pudesse ser melhor expressado, com algo do tipo: “Já domina MVC? Então aprenda REST o quanto antes!”.
    ps: eu não tive sono enquanto lia o artigo; tive um pouco nos comentários de alguns…

  14. Pingback: Api Rest PHP
  15. Cara, muito boa sua explicação! Estarei vendo seus livros e com certeza irei adquirir um deles.

    Obrigado por compartilhar seu conhecimento!

leia mais