Come e perché i moderni framework di applicazioni web si sono evoluti per disaccoppiare percorsi URL dal file system?

Nella sua forma più semplice, un sito web serve file statici. Mappare il percorso dell'URL su un percorso file è la scelta più ovvia; in sostanza, si tratta di un sito FTP di sola lettura.

Quindi le persone volevano modificare il contenuto della pagina con alcuni script. Il modo più semplice è incorporare un linguaggio di scripting nella pagina ed eseguirlo attraverso un interprete. Di nuovo, dato il percorso già esistente - > instradamento del percorso file, questo era abbastanza semplice.

Ma in realtà, stai eseguendo quel file come argomento per l'interprete ora. Devi identificare quando la richiesta è per un file statico e quando è per qualcosa che devi interpretare.

Una volta che inizi a utilizzare lingue compilate più avanzate, sei ancora più distante dal percorso del file.

Inoltre, il tuo server web sta già memorizzando nella cache i file statici e facendo tutti i tipi di ottimizzazioni, il che significa che colpire il file system è l'eccezione piuttosto che la regola. A questo punto, il vecchio percorso del file system di collegamento è più di un ostacolo che un aiuto.

Ma penso che il vero cambiamento del mare sia arrivato quando gli utenti volevano sbarazzarsi dell'estensione del file dal percorso. Ottenere myPage.asp o myPage.php era qualcosa che confondeva le persone 'normali' e interferiva con SEO.

Poiché l'utente vede il percorso, è diventato parte dell'interfaccia utente del Web e, in quanto tale, deve essere completamente privo di limitazioni tecniche. Abbiamo perso il "www" e praticamente tutto è un ".com". Più URL punteranno alla stessa pagina.

Se guadagno di più con mydomain.com/sale vs www.mydomain.co.uk/products/sale.aspx, allora non voglio che le limitazioni tecniche mi ostacolino.

Puoi consultare un white paper di Roy Fielding su Stato di vista rappresentativo (REST) come per quando e perché . Il primo framework di cui ero a conoscenza che ha fatto la distinzione tra una risorsa e un file era Ruby on Rails - introducendo il concetto di URL per il routing del codice.

I concetti principali alla base di REST che erano trasformazionali erano:

• Un URL rappresenta una risorsa
• Quella risorsa può avere più rappresentazioni
• L'URL non dovrebbe interrompersi se l'applicazione è stata ristrutturata
• Le applicazioni dovrebbero abbracciare l'apolidia del Web

Lo svantaggio principale di ricevere i file direttamente dall'URL è che si verificano i seguenti problemi:

• I collegamenti alle risorse sono costantemente interrotti quando i siti Web vengono riorganizzati
• Le risorse e le rappresentazioni sono legate insieme

Penso sia importante fornire un giusto equilibrio:

• Non tutte le risorse hanno uguale importanza. Ecco perché hai ancora risorse basate su stile direttamente (CSS, JavaScript / EcmaScript, immagini)
• Ci sono perfezionamenti di REST come HATEOAS che supportano meglio le app a singola pagina.

Non penso che sia un artefatto di quadri di applicazioni web moderni , è principalmente un artefatto della pubblicazione di pagine dinamiche in generale.

Nei vecchi tempi c'erano principalmente pagine web statiche, in cui un software serviva i singoli file dal file system per il loro percorso. Lo hanno fatto principalmente perché la mappatura 1: 1 dei percorsi URL ai percorsi del file system (con una directory designata come web root) era la scelta più ovvia, anche se la riscrittura degli URL (ad esempio per effettuare reindirizzamenti dopo lo spostamento dei file) era comune.

Poi è arrivata l'era di servire contenuti dinamici. Gli script CGI (e tutto ciò che si è evoluto da loro) creavano le pagine al volo, essendo supportate da un database di qualche tipo. I parametri GET in URL sono diventati comuni, ad esempio en.wikipedia.org/w/index.php? title = Path_ (informatica) .

Tuttavia è più user-friendly per avere un URL leggibile composto da solo segmenti di percorso. Pertanto, le applicazioni dinamiche hanno mappato percorsi semplici (ad esempio en.wikipedia.org/wiki/Path_(computing) ) ai parametri e questi mapping sono noti come "route".

Forse questo approccio sembra più recente in quanto ha guadagnato popolarità quando l'importanza dell'usabilità è stata riconosciuta in modo più ampio e anche diventata parte del SEO. Questo è probabilmente il motivo per cui è stato creato direttamente nei grandi framework web.

Una ragione è che il caricamento di un file dal disco su ogni richiesta è lento, quindi i server Web hanno iniziato a creare dei modi per memorizzare i file nella memoria, quindi se hai intenzione di provare a tenerlo comunque in memoria, perché importa dove era sul disco?

Una ragione è che molti framework web sono scritti in linguaggi compilati, quindi non hai nemmeno una struttura di file su disco, solo un file jar o qualsiasi altra cosa. Le lingue interpretate hanno preso in prestito idee che apprezzavano da quelle compilate.

Una ragione è il desiderio di più percorsi dinamici semantici, come https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes . Ovviamente, non vuoi un file /var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.php . Hai usato le regole di riscrittura delle url nella configurazione del server web per creare percorsi come questo. Ora è solo un cambio di codice, che è molto più semplice dal punto di vista operativo.

Una delle principali ragioni è probabile che questo approccio di mappare gli URI ai percorsi dei file abbia portato a un gran numero di rilasci accidentali di dati tramite Percorso percorso file

Quando si mappa il percorso del file system, significa che è quindi necessario verificare che ogni percorso che si riceve come una richiesta sia associato a file che dovrebbero essere accessibili ai client. Un semplice approccio per garantire che ciò non accada è eliminare la mappatura trasparente e farlo in modo più esplicito.

Questo non è un problema solo per PHP. Come prova qui è una sezione pertinente di una guida per l'indurimento di Apache .

Non posso rispondere per il settore, ma posso dirti perché mi sono allontanato dal file system URL = nei primi anni 2000 verso "percorsi" virtuali.

Lavorando con PHP "vecchia scuola", se hai 1000 pagine PHP, avresti 1000 file PHP che rappresentano quelle pagine. Ciascuna intestazione / piè di pagina duplicata include ed eventualmente qualche altra logica. Ora diciamo che è necessario cambiarlo. Che casino hai ora sulle tue mani! È necessario modificare tutti i 1000 file o si finisce con un miscuglio di codice molto brutto nell'intestazione / nei piè di pagina per gestire tutti i casi. Usando percorsi virtuali, la logica di intestazione / piè di pagina, la logica di connessione al database e altre inizializzazioni sono inclusi una volta , punto. Molto meglio con cui lavorare.

Un altro motivo è evitare l'ambiguità. Man mano che le applicazioni crescono, le intestazioni / i piè di pagina che vengono inclusi diventano più complessi. Di solito avevano nidificati di loro che dipendevano da varie cose. Nel file PHP per la 'pagina', spesso si incontrava ambiguità sul fatto che una variabile isset () o meno. Utilizzando percorsi virtuali e un'applicazione in cui tutto il necessario è caricato su ogni caricamento della pagina, non ti interessa più.

Infine (anche se ci sono altri motivi, ma è l'ultimo che elenco), molte di quelle 1000 pagine rappresentano il codice che verrebbe duplicato. Quindi, dopo aver effettuato il refactoring in un set adeguato di classi e modelli, il codice è notevolmente semplificato e puoi fare tutto ciò che vuoi senza avere quei 1000 file.

Non entrerò troppo nel dettaglio sul perché questa separazione sia vantaggiosa. L'argomento principale è che separa la semantica (cosa stai provando ad accedere) dall'implementazione sottostante.

Considerando che i benefici superano i costi come un dato di fatto - che sarebbe una domanda separata - non è difficile capire perché è stato adottato gradualmente. Non penso che ci sia stato un singolo evento che ha causato questo, anche se sarei certamente aperto ad essere istruito su questo.

Almeno nella mia esperienza, inizialmente questo veniva spesso fatto tramite la configurazione di Apache - e presumibilmente anche altri server web lo supportavano. Tuttavia, concettualmente, non c'è una buona ragione per cui il server dovrebbe essere incaricato di questo. Dopo tutto, i percorsi sono specifici dell'applicazione reale, quindi ha senso definirli lì.

Questo è cambiato a livello globale, ma come fai notare, gradualmente. Il motivo è quasi certamente molto semplice: le buone idee si sono diffuse nel tempo. Questo è anche il motivo per cui non è così sorprendente che il cambiamento sia avvenuto a livello globale. Non è che tutti si sono riuniti e hanno deciso di farlo in questo modo. Piuttosto, ogni progetto ha adattato questo approccio quando pensavano che sarebbe stato utile (e i progetti che non lo supportavano alla fine scomparvero).

Le RFC hanno già costruito i concetti da zero, con URI (che non hanno associato alcuna semantica alla parte locale) e URL come un caso speciale che ha introdotto una semantica simile a un percorso per consentire ai documenti HTML di utilizzare collegamenti relativi all'URL del documento.

L'ovvia implementazione è quella di mappare la parte locale dell'URL direttamente al file system, quindi questo è ciò che hanno fatto le semplici impostazioni: se si utilizza un database relazionale dedicato per cercare un documento o se si approfitta del minimo altamente ottimizzato l'archivio di valori-chiave di -overhead che hai già non ha importanza all'esterno, ma sicuramente influisce sulla struttura dei costi per la pubblicazione dei documenti.

Se hai un'applicazione web con dati persistenti, la struttura dei costi cambia: hai sempre il sovraccarico di esecuzione dell'applicazione e l'integrazione della decodifica URL in essa rende molte funzionalità più facili da implementare, riducendo i costi.

All'inizio del tempo, gli URL venivano mappati direttamente sui percorsi dei file sul server perché è facile e non c'è altro modo di farlo comunque, vero? Se chiedo /path/to/index.php , otterrò /path/to/index.php a partire dalla directory root del sito web (di solito non del server stesso, il sito web dovrebbe essere tenuto in una directory o una sottodirectory più in basso).

Poi, dopo un paio di anni, abbiamo iniziato a studiare la riscrittura, che sta servendo una risorsa diversa da quella che è stata apparentemente richiesta. /request/path/to/index.php può effettivamente servire /response/path/to/index.php .

Un altro trucco sta nascondendo index.php . Se chiedo /index.php?foo=bar&baz=qux il server può rispondere nascondendo index.php in questo modo: /?foo=bar&baz=qux , mentre al momento serve effettivamente index.php .

Il prossimo passo, che è il più importante, è che abbiamo imparato a reindirizzare gli tutti a /index.php . Così ora, /path/to/some/page viene reindirizzato silenziosamente a /index.php?path/to/some/page . Questo è un po 'complicato, perché normalmente ogni barra rappresenta una nuova sottodirectory, ma in questo caso il server web è configurato per inviare il percorso come parametro, invece di cercarlo.

Ora che abbiamo questo, abbiamo bisogno di un modo completamente diverso di pensare a come è organizzato il sito web. Prima era una raccolta libera di pagine diverse. Ora, tutto viene instradato attraverso una singola pagina di entrata. Ciò rende il sito molto più complicato, ma offre opportunità che prima non erano disponibili, come l'autenticazione dell'utente a livello di sito, l'applicazione uniforme di intestazioni, piè di pagina e stili, ecc.

Trasforma efficacemente il tuo sito Web di centinaia di migliaia (se consideri ciascun file come propria app) in un'unica, molto più complicata ma molto più coerente app.

Questo è un grande salto, poiché non puoi più dire quale codice verrà eseguito semplicemente osservando l'URL. Ora devi avere una profonda comprensione di come il tuo particolare framework traduce i percorsi URL in percorsi di codice, e anche se ci sono delle somiglianze tra i framework, la maggior parte sono abbastanza diversi da avere bisogno di familiarità per poter lavorare con il codice.

Per farla breve, è stata una graduale evoluzione della scoperta, non un salto improvviso, e ogni sviluppatore ha dovuto attraversare lo stesso viaggio di scoperta. La curva di apprendimento è piuttosto ripida, a meno che non sia possibile cogliere concetti astratti molto rapidamente.

Come webdev di lunga data, penso all'avvento del controllo della cronologia senza navigazione ( history.pushState() ) attorno al tempo di HTML5 ha reso questo pratico. Prima di ciò, è necessario ricaricare la pagina per aggiornare la barra degli URL, a meno che non si sia aggiornato solo il frammento ( /path#fragment ). Questo frammento era invisibile al server (non è indirizzato), quindi l'unico modo per aggiornare o aggiungere un segnalibro a una pagina dinamica era tramite JavaScript.

Ciò ha importanti implicazioni per il SEO e ha portato Google a sviluppare un "hashbang" usato di rado. schema che richiedeva una mappatura lato server degli hash dinamici agli URL fisici. Questo era ingombrante e non universale tra i robot, che portava l'(falso) assioma: "i ragni non possono strisciare il contenuto di ajax". Ma i vantaggi del contenuto di ajax sono tangibili: prova ad usare google maps senza JS per esempio.

La soluzione era un modo per aggiornare la barra degli URL con un valore che può essere specchiato sul server (consentendo i segnalibri e l'aggiornamento JS-less), SENZA ricaricare la pagina. Una volta disponibile questa funzionalità, gli sviluppatori potevano "navigare" all'interno di un sito semplicemente aggiornando una "sezione del contenuto principale", una barra dell'URL e dei breadcrumb. Ciò significava che tutti i CSS di JS + non necessitavano di refetched + parsed, consentendo un trasferimento da pagina a pagina più rapido.