Como e por que os frameworks modernos de aplicações web evoluíram para dissociar rotas de URL do sistema de arquivos?

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

As pessoas queriam mudar o conteúdo da página com alguns scripts. A maneira mais fácil é incorporar uma linguagem de script na página e executá-la por meio de um intérprete. Mais uma vez, dado o caminho já existente - > roteamento de caminho de arquivo, isso era bastante simples.

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

Depois que você começar a usar linguagens compiladas mais avançadas, ficará ainda mais divorciado do local do arquivo.

Além disso, seu servidor da Web já está armazenando em cache arquivos estáticos e realizando 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 foi algo que confundiu as pessoas "normais" e interferiu com o 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 limitações técnicas. Perdemos o 'www' e praticamente tudo é um '.com'. Vários URLs apontarão 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 quaisquer limitações técnicas fiquem no meu caminho.

Você pode procurar um white paper escrito por Roy Fielding em Transferência de estado representacional (REST) para o quando e o por que . O primeiro framework que eu conhecia que fez a distinção entre um recurso e um arquivo foi Ruby on Rails - introduzindo o conceito de URL para roteamento de código.

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

• Uma 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 incluir a apatridia da web

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

• Links de recursos são constantemente interrompidos conforme os sites são reorganizados
• Recurso e representação são amarrados juntos

Acho importante fornecer também um equilíbrio justo:

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

Eu não acho que seja um artefato de frameworks de aplicativos da web modernos , é principalmente um artefato de veiculação dinâmica de páginas em geral.

Nos velhos tempos havia principalmente páginas da Web estáticas, onde um software servia arquivos individuais do sistema de arquivos pelo caminho deles. Eles fizeram isso principalmente porque o mapeamento 1: 1 dos caminhos de URL para os caminhos do sistema de arquivos (com um diretório designado como raiz da web) era a escolha óbvia, embora a reescrita de URL também fosse comum. / p>

Depois veio a idade de veicular conteúdo dinâmico. Scripts CGI (e tudo evoluiu a partir deles) criaram as páginas na hora, sendo apoiadas por um banco de dados de algum tipo. Os parâmetros GET na URL se tornaram comuns, por exemplo, en.wikipedia.org/w/index.php? title = caminho_ (computação) .

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

Talvez essa abordagem pareça mais recente, uma vez que ganhou popularidade quando a importância da usabilidade foi reconhecida mais amplamente e também se tornou parte do SEO. Esta é provavelmente a razão pela qual ele foi construído diretamente nos grandes frameworks da Web.

Um dos motivos é que o carregamento de um arquivo do disco em cada solicitação é lento, então os servidores da Web começaram a criar maneiras de armazenar arquivos em cache na memória. Então, se você tentar mantê-lo na memória, por que isso importa? estava no disco?

Uma razão é que muitos frameworks web são escritos em linguagens compiladas, então você não tem sequer uma estrutura de arquivos no disco, apenas um arquivo jar ou o que quer que seja. Línguas interpretadas pediram idéias emprestadas das compiladas.

Um dos motivos é o desejo de mais rotas dinâmicas e semânticas, como 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 arquivo /var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.php . Você costumava criar regras de regravação de URL na configuração do servidor da Web para criar rotas como essa. Agora é apenas uma alteração de código, que é muito mais simples em termos operacionais.

Uma das principais razões é que essa abordagem de mapeamento de URIs para caminhos de arquivos levou a um grande número de lançamentos acidentais de dados via Traversal de caminho de arquivo

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

Este não é um problema somente PHP. Como evidência, há 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 afastei do sistema de arquivos URL = no início dos anos 2000 em direção a 'rotas' virtuais.

Trabalhando com o PHP "old school", se você tiver 1000 páginas PHP, você terá 1000 arquivos PHP representando essas páginas. Cada um duplicando cabeçalho / rodapé inclui e possivelmente alguma outra lógica. Agora vamos dizer que você precisa mudar isso. Que bagunça você tem agora em suas mãos! Você tem que alterar todos os 1000 arquivos, ou você acaba com uma confusão de código muito feio 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 do banco de dados e outras inicializações são incluídas uma vez , ponto final. Muito melhor para trabalhar.

Outra razão é evitar a ambigüidade. Conforme os aplicativos crescem, os cabeçalhos / rodapés que são incluídos se tornam mais complexos. Eles geralmente tinham inclusões próprias que dependiam de várias coisas. No arquivo PHP para a 'página', muitas vezes você encontrou 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 último (embora haja outras razões, mas é a última que vou listar), muitas dessas 1000 páginas representam o código que seria duplicado. Então, após a refatoração em um conjunto apropriado de classes e modelos, o código é muito simplificado e você pode fazer tudo o que quiser sem ter esses arquivos 1000.

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

Considerando que os benefícios superam os custos como um dado - o que seria uma questão à parte - não é difícil ver por que foi gradualmente adotado. Eu não acho que haja um único evento que tenha causado isso, embora eu certamente esteja aberto a ser educado sobre isso.

Pelo menos na minha experiência, inicialmente isso geralmente era 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 que o servidor seja encarregado disso. Afinal, as rotas são específicas para a aplicação real, então faz sentido defini-las lá.

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

Os RFCs já criaram os conceitos de raiz, com URIs (que não anexavam nenhuma semântica à parte local) e URLs como um caso especial que introduzia uma semântica semelhante a um caminho para permitir que documentos HTML usassem links relativos para o URL base do documento.

A implementação óbvia é mapear a parte local da URL diretamente para o sistema de arquivos, de modo que é isso que as configurações simples fizeram - se você usa um banco de dados relacional dedicado para procurar um documento ou aproveita o baixo altamente otimizado O armazenamento de valor-chave que você já possui não importa para o exterior, mas certamente afeta sua estrutura de custos para veicular os documentos.

Se você tiver um aplicativo da Web com dados persistentes, essa estrutura de custo será alterada: você sempre terá a sobrecarga de executar o aplicativo e a integração da decodificação de URL a ele facilitará a implementação de muitos recursos, reduzindo o custo.

No início dos tempos, as URLs eram mapeadas diretamente para os caminhos de arquivos no servidor, porque é fácil, e não há outra maneira de fazer isso de qualquer maneira, existe? Se eu pedir /path/to/index.php , receberei /path/to/index.php 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).

Então, depois de alguns anos, começamos a aprender sobre a reescrita, que serve um recurso diferente daquele que foi aparentemente solicitado. /request/path/to/index.php pode realmente veicular /response/path/to/index.php .

Outro truque é esconder index.php . Se eu pedir /index.php?foo=bar&baz=qux , o servidor pode responder escondendo index.php da seguinte forma: /?foo=bar&baz=qux , enquanto na verdade atende index.php mesmo assim.

O próximo passo, que é o mais importante, é que nós aprendemos a redirecionar all 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 é configurado para enviar o caminho como um parâmetro, em vez de procurar nele.

Agora que temos isso, precisamos de uma maneira completamente diferente de pensar sobre como o site é organizado. Antes, era uma coleção solta de páginas diferentes. Agora, tudo é encaminhado 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 salto enorme, já que você não pode mais dizer qual código será executado simplesmente observando o URL. Agora você precisa ter uma compreensão profunda de como sua estrutura específica traduz caminhos de URL em caminhos de código e, embora haja semelhanças entre estruturas, a maioria é diferente o suficiente para que você precise de alguma 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 teve que passar pela mesma jornada de descoberta. A curva de aprendizado é bastante íngreme, a menos que você consiga entender conceitos abstratos muito rapidamente.

Como um 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, você tinha que recarregar a página para atualizar a barra de URL, a menos que você apenas atualizasse 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 grandes implicações para o SEO e levou o Google a desenvolver um "hashbang" pouco usado. esquema que exigia um mapeamento do lado do servidor de hashes dinâmicos para URLs físicos. Isso era complicado e não universal entre os robôs, liderando o (falso) axioma: "as aranhas não podem rastrear o conteúdo do ajax". Mas os benefícios do conteúdo do ajax são tangíveis: tente usar o google maps sem o 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 marcadores e atualizações sem JS), SEM recarregar a página. Quando esse recurso estava disponível, os desenvolvedores podiam "navegar" em um site simplesmente atualizando uma "seção de conteúdo principal", uma barra de URL e um breadcrumbs. Isso significa que todo o JS + CSS não precisou ser revisado + analisado, permitindo uma transferência de página para página MUITO mais rápida.