Como e por que as estruturas modernas de aplicativos da web evoluíram para separar as rotas de URL do sistema de arquivos?

Comparado a cerca de 10 anos atrás, observei uma mudança em direção a estruturas usando o estilo de roteamento que desacopla o caminho da URL do sistema de arquivos. Isso geralmente é realizado com a ajuda de um padrão de controlador frontal.

Nomeadamente, quando antes, o caminho da URL era mapeado diretamente para o sistema de arquivos e, portanto, refletia arquivos e pastas exatos no disco. Atualmente, os caminhos da URL reais são programados para serem direcionados a classes específicas via configuração e, como tal, não refletem mais o arquivo pasta do sistema e estrutura de arquivos.

Pergunta, questão

Como e por que isso se tornou comum? Como e por que foi decidido que é "melhor" ao ponto em que a abordagem direta ao arquivo, antes comum, foi efetivamente abandonada?

Outras respostas

Há uma resposta semelhante aqui que entra um pouco no conceito de rota e alguns benefícios e desvantagens: Com estruturas PHP, por que o conceito de "rota" é usado?

Mas ele não trata dos aspectos históricos da mudança, ou como ou por que essa mudança aconteceu gradualmente, para onde novos projetos atualmente estão usando esse novo padrão de estilo de roteamento e o arquivo direto está desatualizado ou abandonado.

Além disso, a maioria dos benefícios e desvantagens mencionados não parece ser significativa o suficiente para justificar uma mudança global. O único benefício que posso ver impulsionando essa mudança talvez seja ocultar o sistema de arquivos / pastas do usuário final e também a falta de ?param=value&param2=value, o que faz com que os URLs pareçam um pouco mais limpos. Mas esses eram os únicos motivos da mudança? E se sim, por que essas razões estavam por trás disso?

Exemplos:

Eu estou mais familiarizado com estruturas PHP e muitas estruturas modernas populares usam essa abordagem de roteamento desacoplado. Para fazê-lo funcionar, você configura a reescrita de URL no Apache ou em um servidor da Web semelhante, para onde a funcionalidade do aplicativo da Web geralmente não é mais acionada por um caminho de URL direto para o arquivo.

Zend Expressive

https://docs.zendframework.com/zend-expressive/features/router/aura/
https://docs.zendframework.com/zend-expressive/features/router/fast-route/
https: //docs.zendframework. com / zend-expressive / features / roteador / zf2 /

Zend Framework

https://docs.zendframework.com/zend-mvc/routing/

Laravel

https://laravel.com/docs/5.5/routing

CakePHP

https://book.cakephp.org/3.0/en/development/routing.html

Na sua forma mais básica, um site serve arquivos estáticos. Mapear o caminho da URL para o caminho do arquivo é a escolha mais óbvia; essencialmente, é um site FTP somente leitura.

As pessoas queriam alterar o conteúdo da página com alguns scripts. A maneira mais fácil é incorporar uma linguagem de script à página e executá-la através de um intérprete. Novamente, dado o caminho já existente -> roteamento do caminho do arquivo, isso foi bastante simples.

Mas, na verdade, você está executando esse arquivo como argumento para o intérprete agora. Você precisa identificar quando a solicitação é para um arquivo estático e quando é para algo que você precisa interpretar.

Depois de começar a usar idiomas compilados mais avançados, você fica ainda mais divorciado do local do arquivo.

Além disso, seu servidor da web já está armazenando em cache arquivos estáticos e fazendo todo tipo de otimização, o que significa que atingir o sistema de arquivos é a exceção e não a regra. Nesse ponto, o caminho antigo do sistema de arquivos de link é mais um obstáculo do que uma ajuda.

Mas acho que a verdadeira mudança ocorreu quando os usuários queriam se livrar da extensão do arquivo do caminho. Obter myPage.asp ou myPage.php era algo que confundia pessoas 'normais' e interferia no SEO.

Como o usuário vê o caminho, ele se tornou parte da interface do usuário da Web e, como tal, precisa estar completamente livre de quaisquer limitações técnicas. Perdemos o 'www' e praticamente tudo é um '.com'. Vários URLs apontam para a mesma página.

Se eu ganhar mais dinheiro com mydomain.com/sale vs www.mydomain.co.uk/products/sale.aspx, não quero que nenhuma limitação técnica fique no meu caminho.

Você pode ler um artigo de Roy Fielding sobre REpresentational State Transfer (REST) sobre o quando e o porquê . A primeira estrutura que eu sabia que fazia a distinção entre um recurso e um arquivo era o Ruby on Rails - introduzindo o conceito de URL no roteamento de código.

Os principais conceitos por trás do REST que foram transformacionais foram:

• Um URL representa um recurso
• Esse recurso pode ter várias representações
• O URL não deve quebrar se o aplicativo for reestruturado
• Os aplicativos devem adotar a apatridia da web

A principal desvantagem de ter arquivos sendo atendidos diretamente pelo URL é que você enfrenta os seguintes problemas:

• Links de recursos são constantemente quebrados à medida que os sites são reorganizados
• Recurso e representação estão ligados

Eu acho que é importante fornecer um equilíbrio justo também:

• Nem todos os recursos são iguais em importância. É por isso que você ainda tem recursos baseados em estilo exibidos diretamente (CSS, JavaScript / EcmaScript, imagens)
• Existem refinamentos do REST, como o HATEOAS, que suportam melhor aplicativos de página única.

Não acho que seja um artefato de estruturas modernas de aplicativos da Web, é principalmente um artefato de página dinâmica que serve em geral.

Nos velhos tempos foram principalmente páginas estáticas, onde um software serviram arquivos individuais do sistema de arquivos pelo seu caminho. Eles o fizeram principalmente porque o mapeamento 1: 1 dos caminhos da URL para os caminhos do sistema de arquivos (com um diretório designado como raiz da web) era a escolha óbvia, embora a reescrita da URL (por exemplo, para redirecionar após mover arquivos) também fosse comum.

Então chegou a era de veicular conteúdo dinâmico. Os scripts CGI (e tudo o que foi desenvolvido a partir deles) criaram as páginas rapidamente, sendo apoiadas por algum tipo de banco de dados. Os parâmetros GET no URL tornaram-se comuns, por exemplo, en.wikipedia.org/w/index.php?title=Path_(computing) .

No entanto, é mais amigável ter um URL legível que consiste apenas em segmentos de caminho. Portanto, os aplicativos dinâmicos mapearam caminhos simples (por exemplo, en.wikipedia.org/wiki/Path_(computing) ) para parâmetros, e esses mapeamentos são conhecidos como "rotas".

Talvez essa abordagem pareça mais recente, pois ganhou popularidade quando a importância da usabilidade foi reconhecida mais amplamente e também se tornou parte do SEO. Essa é provavelmente a razão pela qual foi criada diretamente nos grandes quadros da web.

Uma razão é que o carregamento de um arquivo do disco em todas as solicitações é lento; portanto, os servidores da Web começaram a criar maneiras de armazenar em cache os arquivos na memória; se você quiser mantê-lo na memória, por que isso importa onde ele está? disco?

Uma razão é que muitas estruturas da Web são escritas em linguagens compiladas, para que você nem tenha uma estrutura de arquivos em disco, apenas um jararquivo ou o que for. Os idiomas interpretados pegaram emprestado as idéias de que gostavam dos compilados.

Uma razão é o desejo de rotas mais semânticas e dinâmicas https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes. Obviamente, você não quer um /var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.phparquivo. Você costumava criar regras de reescrita de URL na configuração do servidor da Web para criar rotas como esta. Agora é apenas uma alteração de código, que é muito mais simples operacionalmente.

Um dos principais motivos é provável que essa abordagem de mapeamento de URIs para caminhos de arquivo tenha levado a um grande número de liberações acidentais de dados via File Path Traversal

Quando você mapeia o caminho para o sistema de arquivos, significa que você precisa verificar se todos os caminhos que você recebe como solicitação são mapeados para arquivos que devem ser acessíveis aos clientes. Uma abordagem simples para garantir que isso não está acontecendo é eliminar o mapeamento transparente e fazê-lo de forma mais explícita.

Este não é um problema apenas do PHP. Como evidência, aqui está uma seção relevante de um guia de proteção do Apache .

Não posso responder pela indústria, mas posso dizer por que me mudei do sistema de arquivos URL = no início dos anos 2000 para as 'rotas' virtuais.

Trabalhando com o PHP 'old school', se você tiver 1000 páginas PHP, terá 1000 arquivos PHP representando essas páginas. Cada cabeçalho / rodapé duplicado inclui e possivelmente alguma outra lógica. Agora, digamos que você precise mudar isso. Que bagunça agora você tem em suas mãos! Você precisa alterar todos os 1000 arquivos ou acabar com uma mistura de códigos muito feios no cabeçalho / rodapés para lidar com todos os casos. Usando rotas virtuais, sua lógica de cabeçalho / rodapé, lógica de conexão com o banco de dados e outras inicializações são incluídas uma vez por ponto. Muito melhor para trabalhar.

Outro motivo é evitar ambiguidade. À medida que os aplicativos crescem, os cabeçalhos / rodapés que são incluídos se tornam mais complexos. Eles geralmente tinham aninhados próprios, que dependiam de várias coisas. No arquivo PHP da 'página', frequentemente você encontra ambiguidade sobre se uma variável isset () ou não. Usando rotas virtuais e um aplicativo em que tudo o que você precisa é carregado em cada carregamento de página, você não tem mais essa preocupação.

Por fim (embora existam outros motivos, mas seja o último que listarei), muitas dessas 1000 páginas representam código que seria duplicado. Portanto, após refatorar para um conjunto adequado de classes e modelos, o código é bastante simplificado e você pode fazer tudo o que deseja sem os 1000 arquivos.

Não entrarei em muitos detalhes sobre por que essa separação é benéfica. O argumento principal é que ele separa a semântica (o que você realmente está tentando acessar) da implementação subjacente.

Considerando que os benefícios superam os custos, o que seria uma pergunta à parte, não é difícil ver por que foi adotado gradualmente. Eu não acho que houve um único evento que causou isso, embora eu certamente estivesse aberto a ser educado sobre isso.

Pelo menos na minha experiência, inicialmente isso costumava ser feito através da configuração do Apache - e, presumivelmente, outros servidores da Web também suportavam isso. No entanto, conceitualmente, não há uma boa razão para o servidor ser encarregado disso. Afinal, as rotas são específicas para a aplicação real, por isso faz sentido defini-las lá.

Isso mudou globalmente, mas, como você aponta, gradualmente. A razão para isso é quase certamente muito simples: boas idéias se espalham ao longo do tempo. É também por isso que não é uma surpresa que a mudança tenha acontecido globalmente. Não é que todos se reuniram e decidiram fazer dessa maneira. Em vez disso, todos os projetos adaptaram essa abordagem quando pensaram que seria benéfico (e os projetos que não a apoiavam acabaram desaparecendo).

Os RFCs já construíram os conceitos desde o início, com URIs (que não anexavam nenhuma semântica à parte local) e URLs como um caso especial que introduziu semântica semelhante a caminho para permitir que documentos HTML usem links relativos ao documento URL base.

A implementação óbvia é mapear a parte local da URL diretamente para o sistema de arquivos, e é isso que as configurações simples fizeram - se você usa um banco de dados relacional dedicado para procurar um documento ou tira proveito da chave de baixo custo indireto altamente otimizada A loja de valores que você já possui não importa para o exterior, mas certamente afeta sua estrutura de custos para a veiculação dos documentos.

Se você possui um aplicativo da Web com dados persistentes, essa estrutura de custos muda: você sempre tem a sobrecarga de executar o aplicativo e a integração da decodificação de URL nele facilita a implementação de muitos recursos, reduzindo o custo.

No início, os URLs mapeados diretamente para os caminhos de arquivo no servidor, porque é fácil e não há outra maneira de fazê-lo, existe? Se eu pedir /path/to/index.php, /path/to/index.phpcomeçarei a partir do diretório raiz do site (geralmente não do próprio servidor, o site deve ser mantido em um diretório ou subdiretório mais abaixo).

Depois de alguns anos, começamos a aprender a reescrever, que está servindo um recurso diferente daquele que aparentemente foi solicitado. /request/path/to/index.phppode realmente servir /response/path/to/index.php.

Outro truque está escondido index.php. Se eu pedir que /index.php?foo=bar&baz=quxo servidor possa responder, oculte-se da seguinte index.phpmaneira: /?foo=bar&baz=quxo tempo todo, na verdade, servindo de index.phpqualquer maneira.

O próximo passo, que é o mais importante, é que aprendemos a redirecionar todos os URLs para /index.php. Então agora, /path/to/some/pageé silenciosamente redirecionado para /index.php?path/to/some/page. Isso é um pouco complicado, porque normalmente cada barra representa um novo subdiretório, mas nesse caso o servidor da Web está configurado para enviar o caminho como um parâmetro, em vez de procurá-lo.

Agora que temos isso, precisamos de uma maneira completamente diferente de pensar sobre como o site está organizado. Antes, era uma coleção solta de páginas diferentes. Agora, tudo é roteado através de uma única página de entrada. Isso torna o site muito mais complicado, mas oferece oportunidades que não estavam disponíveis antes, como autenticação de usuário em todo o site, aplicação uniforme de cabeçalhos, rodapés e estilos, etc.

Ele efetivamente transforma seu site de cem ou mil aplicativos (se você considerar cada arquivo como seu próprio aplicativo) em um único aplicativo muito mais complicado, mas muito mais consistente.

Este é um grande salto, pois você não pode mais dizer qual código será executado simplesmente olhando para o URL. Agora você precisa ter um entendimento profundo de como sua estrutura específica traduz caminhos de URL em caminhos de código e, embora existam semelhanças entre estruturas, a maioria é diferente o suficiente para que você precise de familiaridade para poder trabalhar com o código.

Para encurtar a história, foi uma evolução gradual da descoberta, não um salto repentino, e cada desenvolvedor praticamente teve que passar pela mesma jornada de descoberta. A curva de aprendizado é bastante íngreme, a menos que você possa entender conceitos abstratos muito rapidamente.

Como webdev de longa data, acho que o advento do controle de histórico sem navegação ( history.pushState()) na época do HTML5 tornou isso prático. Antes disso, era necessário recarregar a página para atualizar a barra de URL, a menos que você atualizasse apenas o fragmento ( /path#fragment). Esse fragmento era invisível para o servidor (não é roteado), portanto, a única maneira de atualizar ou marcar uma página dinâmica era via JavaScript.

Isso tem implicações importantes para o SEO e levou o Google a desenvolver um esquema "hashbang" raramente usado, que exigia um mapeamento no servidor de hashes dinâmicos para URLs físicos. Isso era pesado e não universal entre os robôs, levando o axioma (falso): "aranhas não podem rastrear conteúdo de ajax". Mas os benefícios do conteúdo ajax são tangíveis: tente usar o google maps sem JS, por exemplo.

A solução foi uma maneira de atualizar a barra de URL com um valor que pode ser espelhado no servidor (permitindo favoritos e atualização sem JS), SEM recarregar a página. Quando esse recurso estivesse disponível, os desenvolvedores poderiam "navegar" em um site simplesmente atualizando uma "seção de conteúdo principal", barra de URL e trilhas de navegação. Isso significava que todo o JS + CSS não precisou de refetch + analisado, permitindo uma transferência MUITO mais rápida de página para página.