Modern web uygulama çerçeveleri URL rotalarını dosya sisteminden ayırmak için nasıl ve neden gelişti?

Yaklaşık 10 yıl öncesine kıyasla, URL yolunu dosya sisteminden ayıran yönlendirme stilini kullanarak çerçevelere doğru bir kayma olduğunu gördüm. Bu, genellikle bir ön denetleyici deseni yardımıyla gerçekleştirilir.

Yani, daha önce ne zaman, URL yolu doğrudan dosya sistemine eşleştirildi ve bu nedenle diskte tam dosya ve klasörleri yansıtıyordu; günümüzde, gerçek URL yolları yapılandırma yoluyla belirli sınıflara yönlendirilmek üzere programlanmış ve artık dosyayı yansıtmayacak şekilde programlanmıştır. sistem klasörü ve dosya yapısı.

Soru

Bu nasıl ve neden olağan hale geldi? Bir zamanlar sıradan dosyaya doğrudan yaklaşımın etkili bir şekilde bırakıldığı noktaya nasıl ve neden "daha iyi" olduğuna karar verildi?

Diğer cevaplar

Burada, rota kavramına ve bazı yararlara ve dezavantajlara biraz giren benzer bir cevap var: PHP çerçevelerinde neden "rota" kavramı kullanılıyor?

Ancak, tarihsel değişimin yönlerini veya bu değişimin neden veya neden yavaş yavaş gerçekleştiğini, bugünlerde herhangi bir yeni projenin hemen hemen bu yeni yönlendirme stili modelini kullandığı ve doğrudan dosyaya eskimiş veya terk edilmiş olduğu durumları ele almamaktadır.

Ayrıca, bahsi geçen bu fayda ve dezavantajların çoğu, böyle bir küresel değişimi garanti altına alacak kadar önemli görünmemektedir. Belki de bu değişikliği sürdüğünü görebildiğim tek yarar, dosya / klasör sistemini son kullanıcılardan gizlemek ve ?param=value&param2=valueURL'lerin biraz daha temiz görünmesini sağlayan eksiklik . Fakat bunlar değişimin tek nedeni miydi? Ve eğer evet, neden bu sebepler arkasındaki?

Örnekler:

PHP çerçevelerine en aşinayım ve birçok popüler modern çerçevede bu ayrıştırılmış yönlendirme yaklaşımı kullanılıyor. Çalışmasını sağlamak için , Apache'de veya benzer bir web sunucusunda URL yeniden yazımı kurarsınız ; burada web uygulaması işlevselliği artık dosyaya doğrudan bir URL yolu üzerinden tetiklenmez.

Etkileyici Zend

https://docs.zendframework.com/zend-expressive/features/router/aura/
https://docs.zendframework.com/zend-expressive/features/router/fast-route/
https: //docs.zendframework. com / zend-dışavurumcu / özellikler / yönlendirici / ZF2 /

Zend Framework

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

laravel

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

CakePHP'nin

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

En basit haliyle, bir web sitesi statik dosyalar sunar. URL yolunu bir dosya yoluyla eşlemek en belirgin seçimdir; temelde, salt okunur bir FTP sitesidir.

Sonra insanlar sayfanın içeriğini bir miktar kod yazarak değiştirmek istediler. En kolay yol, bir betik dilini sayfaya katıştırmak ve tercüman aracılığıyla çalıştırmaktır. Yine, zaten var olan yol -> dosya yolu yönlendirme verildiğinde, bu yeterince basitti.

Fakat gerçekten, bu dosyayı şu an yorumlayıcıya argüman olarak çalıştırıyorsunuz. İsteğin ne zaman statik bir dosya için olduğunu ve ne zaman yorumlamanız gereken bir şey olduğunu tanımlamanız gerekir.

Daha gelişmiş derlenmiş dilleri kullanmaya başladığınızda, dosya konumundan daha da boşandınız.

Ayrıca, web sunucunuz zaten statik dosyaları önbelleğe alıyor ve her türlü en iyileştirmeyi yapıyor, yani dosya sistemine vurmak kuraldan ziyade istisnadır. Bu noktada, eski bağlantı dosyası sistemi yolu bir yardımdan çok bir engeldir.

Ancak asıl deniz değişikliğinin kullanıcılar dosya uzantısından yoldan kurtulmak istediklerinde ortaya çıktığını düşünüyorum. MyPage.asp veya myPage.php 'lerini almak,' normal 'insanları şaşırtan ve SEO ile etkileşime giren bir şeydi.

Kullanıcı yolu gördüğü için web kullanıcı arayüzünün bir parçası haline geldi ve bu nedenle teknik sınırlamalardan tamamen arındırılması gerekiyor. 'Www' yi kaybettik ve hemen hemen her şey bir '.com'tur. Birden fazla URL aynı sayfaya işaret edecektir.

Www.domain.com/sale vs www.mydomain.co.uk/products/sale.aspx adresinde daha fazla para kazanırsam, yolumda teknik sınırlamalar olmasını istemiyorum.

Üzerinde Roy Fielding tarafından beyaz kağıda bakabilirsiniz rest (DİNLENME) olarak ne zaman ve niçin . Farkında olduğum ilk çerçeve, bir kaynakla bir dosya arasında ayrım yaptı, URL yönlendirme kodunu tanıtmak için Ruby on Rails idi.

REST'in ardındaki dönüşümsel temel kavramlar şunlardı:

• Bir URL bir kaynağı temsil eder
• Bu kaynağın birden fazla gösterimi olabilir
• Uygulama yeniden yapılandırılmışsa, URL kesilmemelidir
• Uygulamalar web'in vatansızlığını benimsemelidir

Dosyaların doğrudan URL tarafından sunulmasının ana dezavantajı, aşağıdaki sorunları yaşamanızdır:

• Web siteleri yeniden düzenlendiği için kaynak bağlantıları sürekli bozuluyor
• Kaynak ve temsil birbirine bağlıdır

Adil bir denge sağlamanın da önemli olduğunu düşünüyorum:

• Tüm kaynaklar önem açısından eşit değildir. Bu yüzden doğrudan stil tabanlı kaynaklara doğrudan hizmet veriyorsunuz (CSS, JavaScript / EcmaScript, resimler)
• Tek sayfa uygulamalarını daha iyi destekleyen HATEOAS gibi REST'in iyileştirmeleri var .

Modern web uygulama çerçevelerinin bir eseri olduğunu sanmıyorum , genel olarak dinamik sayfanın sunumu eseridir.

Gelen eski günlerdeki bir yazılım onların yol ile dosya sisteminden dosyaları tek tek servis çoğunlukla statik web sayfaları vardı. Bunu çoğunlukla yaptılar, çünkü URL yollarının 1: 1 dosya sistemi yollarına eşlenmesi (bir web kökü olarak belirlenmiş bir dizinle) bariz bir seçimdi, ancak URL yeniden yazma da (örneğin dosyaları taşıdıktan sonra yönlendirmeler yapmak için) yaygındı.

Sonra dinamik içerik sunma yaşı geldi. CGI betikleri (ve onlardan gelişen her şey) anında bir tür veri tabanı tarafından desteklenen sayfaları yarattı. URL’deki GET parametreleri yaygınlaştı, örneğin en.wikipedia.org/w/index.php?title=Path_(computing) .

Bununla birlikte , yalnızca yol bölümlerinden oluşan okunabilir bir URL’ye sahip olmak daha kullanıcı dostudur . Bu yüzden dinamik uygulamalar parametrelere basit yolları eşleştirdi (örneğin en.wikipedia.org/wiki/Path_(computing) ve bu eşlemeler "yollar" olarak bilinir.

Belki de bu yaklaşım, kullanılabilirliğin önemi daha yaygın olarak tanındığında ve ayrıca SEO'nun bir parçası haline geldiğinde popülerlik kazandığı için daha yenidir. Muhtemelen doğrudan büyük web çerçevelerine inşa edilmesinin nedeni budur.

Bunun bir nedeni, her istekte diskten bir dosya yüklemenin yavaş olmasıdır, bu nedenle web sunucuları bellekteki dosyaları önbelleğe almanın yollarını oluşturmaya başladı, o halde yine de bellekte tutmaya çalışacaksanız, neden nerede olduğu önemli disk?

Bunun bir nedeni, birçok web çerçevesinin derlenmiş dillerde yazılmasıdır, bu nedenle diskte bir jardosya yapınız yoktur, sadece bir dosya veya her neyse. Yorumlanan diller, derlenenlerden beğendikleri fikirleri ödünç aldı.

Bunun bir nedeni, daha anlamsal, dinamik yollar gibi bir istek https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes. Açıkçası, bir /var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.phpdosya istemiyorsun . Bunun gibi yollar oluşturmak için URL yeniden yazma kurallarını web sunucusu yapılandırmasında kullanıyordunuz. Şimdi sadece bir kod değişikliği, işlemsel olarak daha basit.

Başlıca nedenlerden dolayı, URI'lerin dosya yollarıyla eşleştirilmesinin bu yaklaşımının, Dosya Yolu Geçişi yoluyla çok sayıda yanlışlıkla veri yayınlamasına yol açması olasıdır.

Yolu dosya sistemine eşlediğinizde, istek olarak aldığınız her yolun istemciler tarafından erişilebilir olması gereken dosyalarla eşleştiğini kontrol etmeniz gerektiği anlamına gelir. Olmamasını garanti etmek için basit bir yaklaşım, şeffaf haritayı ortadan kaldırmak ve daha açık bir şekilde yapmaktır.

Bu sadece PHP ile ilgili bir sorun değil. Burada kanıt olarak Apache sertleştirme kılavuzunun ilgili bir bölümüdür .

Endüstri için cevap veremem, ancak neden 2000'den başlarda sanal 'rotalara' doğru URL = dosya sisteminden uzaklaştığımı söyleyebilirim.

'Eski okul' PHP ile çalışmak, eğer bir 1000 PHP sayfanız varsa, bu sayfaları temsil eden 1000 PHP dosyanız olacaktır. Her biri yinelenen üstbilgi / altbilgi içerir ve muhtemelen başka bir mantık içerir. Şimdi bunu değiştirmeniz gerektiğini söyleyelim. Şimdi ellerinde ne dağınıklık var! 1000 dosyayı da değiştirmeniz gerekecek veya tüm vakaları ele almak için üstbilgi / altbilgilerde çok çirkin kod kargaşası oluşacak. Sanal yollar kullanarak, üstbilgi / altbilgi mantığınız, veritabanı bağlantı mantığınız ve diğer başlatma işlemleriniz bir kez dahil edilir . Çalışmak çok daha iyi.

Başka bir neden belirsizlikten kaçınmaktır. Uygulamalar büyüdükçe, dahil edilen üstbilgiler / altbilgiler daha karmaşık hale gelir. Genellikle çeşitli şeylere bağlı olan kendi içlerinden oluşan iç içe geçmişlerdi. 'Sayfa' için olan PHP dosyasında, bir değişkenin isset () olup olmadığına dair bir belirsizlikle karşılaştınız. Sanal rotaları ve ihtiyaç duyduğunuz her şeyin her sayfaya yüklendiği bir uygulamayı kullanarak, artık bu endişeniz yok.

Son olarak (başka nedenler olsa da, listenin son listesi), bu 1000 sayfanın çoğu kopyalanacak kodu temsil ediyor. Dolayısıyla, uygun bir sınıf ve şablon kümesine yeniden girdikten sonra, kod büyük ölçüde basitleştirilmiştir ve bu 1000 dosyaya sahip olmadan yapmak istediğiniz her şeyi yapabilirsiniz.

Bu ayrılmanın neden faydalı olduğu konusunda fazla ayrıntıya girmeyeceğim. Ana argüman, semantiği (aslında neye erişmeye çalışıyorsunuz) temeldeki uygulamadan ayırmasıdır.

Avantajların verilen maliyetlerden daha ağır basılması - ayrı bir soru olacaktır - neden kademeli olarak benimsendiğini görmek zor değildir. Bu konuda eğitime açık olmasına rağmen, buna neden olan tek bir olay olduğunu sanmıyorum.

En azından deneyimlerime göre, başlangıçta bu genellikle Apache yapılandırmasıyla yapıldı - ve muhtemelen diğer web sunucuları da bunu destekledi. Bununla birlikte, kavramsal olarak sunucunun bu konuda görevlendirilmesi için iyi bir neden yoktur. Sonuçta, yollar gerçek uygulamaya özgüdür, bu yüzden onları orada tanımlamak mantıklıdır.

Bu küresel olarak değişti, ancak sizin de belirttiğiniz gibi, yavaş yavaş. Bunun nedeni neredeyse kesinlikle çok basit bir şey: zaman içinde yayılan iyi fikirler. Bu aynı zamanda, değişimin küresel olarak gerçekleşmesinin sürpriz olmamasının da nedeni budur. Bu herkesin bir araya gelip böyle yapmaya karar vermesi değil. Aksine, her proje yararlı olacağını düşündüklerinde (ve onu desteklemeyen projeler sonunda kayboldu) bu yaklaşımı uyarladı.

RFC'ler halihazırda temelden, URI'lerle (yerel kısma hiçbir anlam ifade etmeyen) kavramları ve URL'leri, HTML belgelerinin belgeye göre bağlar kullanmasına izin vermek için yola benzeyen anlambilim getiren özel bir durum olarak oluşturdular. temel URL

Belirgin uygulama, URL’nin yerel bölümünü doğrudan dosya sistemine eşlemektir, bu nedenle basit kurulumların yaptığı şeydir - bir belgeye bakmak için özel bir ilişkisel veritabanı kullanıyor veya yüksek derecede optimize edilmiş düşük gider anahtarından faydalanıyor musunuz? Zaten sahip olduğunuz değerli mağaza dışarısı için önemli değil, ancak belgelere hizmet için maliyet yapınızı kesinlikle etkiler.

Kalıcı verilere sahip bir web uygulamanız varsa, bu maliyet yapısı değişir: her zaman uygulamayı çalıştırma yükünü üstlenir ve URL kod çözme işlemini entegre etmek, bir çok özelliği uygulamayı kolaylaştırarak maliyeti düşürür.

Başlangıçta, URL'ler doğrudan sunucudaki dosya yollarıyla eşlenir, çünkü kolaydır ve bunu yapmanın başka bir yolu yoktur, öyle değil mi? Ben sorarsanız /path/to/index.php, ben alırsınız /path/to/index.phpweb sitesinin kök dizininde başlayarak (genellikle sunucunun kendisinin, Web dizininde tutulur veya bir alt dizin daha da aşağı olmalıdır).

Sonra birkaç yıl sonra, görünüşe göre talep edilenden farklı bir kaynağa hizmet eden yeniden yazmayı öğrenmeye başladık. /request/path/to/index.phpaslında hizmet edebilir /response/path/to/index.php.

Başka bir numara da saklanıyor index.php. /index.php?foo=bar&baz=quxSunucuyu sorarsam şu şekilde saklanarak cevap verebilirim index.php: /?foo=bar&baz=quxher zaman aslında index.phpzaten hizmet ederken .

En önemli adım olan sonraki adım, tüm URL'leri yönlendirmeyi öğrenmemiz /index.php. Şimdi, /path/to/some/pagesessizce yönlendirilir /index.php?path/to/some/page. Bu biraz zor, çünkü normalde her eğik çizgi yeni bir alt dizini temsil eder, ancak bu durumda web sunucusu yolu aramak yerine yolu parametre olarak göndermek üzere yapılandırılmıştır.

Şimdi buna sahibiz, web sitesinin nasıl organize edildiği hakkında tamamen farklı bir düşünme yöntemine ihtiyacımız var. Öncesinde, farklı sayfalardan oluşan gevşek bir koleksiyondu. Şimdi, her şey tek bir giriş sayfasından geçiriliyor. Bu, siteyi çok daha karmaşık hale getirir, ancak site genelinde kullanıcı kimlik doğrulaması, üstbilgi, altbilgi ve stillerin düzgün bir şekilde uygulanması gibi daha önce kullanılamayan fırsatlar sağlar.

Yüz veya bin uygulama web sitenizi etkili bir şekilde (her dosyayı kendi uygulaması olarak görürseniz) tek, çok daha karmaşık ama çok daha tutarlı bir uygulamaya dönüştürür.

Bu, artık URL’ye bakarak hangi kodun yürütüleceğini söyleyemediğiniz için çok büyük bir adımdır. Artık, kendi özel çerçevenizin URL yollarını kod yollarına nasıl dönüştürdüğü konusunda derinlemesine bir anlayışa sahip olmalısınız ve çerçeveler arasında benzerlikler olsa da, çoğu, kodla çalışabilmeniz için biraz aşina olmanız gerekenden yeterince farklıdır.

Uzun lafın kısası, ani bir sıçrama değil, yavaş yavaş keşif evrimi oldu ve her geliştirici aynı keşif yolculuğuna katlanmak zorunda kaldı. Öğrenme eğrisi, soyut kavramları gerçekten hızlı bir şekilde anlayamadığınız sürece oldukça diktir.

Uzun süredir bir webdev olarak, HTML5 zamanı boyunca gezinme gerektirmeyen tarih kontrolü ( history.pushState()) ' nin ortaya çıkışı bunu pratikleştirdi. Ondan önce, yalnızca ( /path#fragment) parçasını güncellemediğiniz sürece, URL çubuğunu güncellemek için sayfayı yeniden yüklemelisiniz . Bu parça sunucuya görünmüyordu (yönlendirilmemiş), bu nedenle dinamik bir sayfayı yenilemenin ya da favorilere eklemenin tek yolu JavaScript'di.

Bunun SEO için büyük etkileri vardır ve google’ın, nadiren kullanılan bir "hashbang" şeması geliştirmesine , sunucu tarafındaki dinamik karmaları fiziksel URL’lere eşleştirmesini gerektirdi. Bu, hantal bir durumdu ve robotlar arasında evrensel değildi, (sahte) aksiyomun öncülüğünü yaptı: "örümcekler ajax içeriğini tarayamıyor". Ancak, ajax içeriğinin yararları somuttur: örneğin JS olmayan google maps kullanmayı deneyin.

Çözüm, URL çubuğunu, sayfayı yeniden yüklemeden, sunucuda yansıtılabilecek bir değerle (yer imlerinin ve JS'sinin daha az yenilenmesine izin veren) güncellemenin bir yoluydu. Bu özellik kullanılabilir duruma geldiğinde, geliştiriciler bir "ana içerik bölümü", URL çubuğu ve ekmek kırıntılarını güncelleyerek bir sitede "gezinebilir". Bu, tüm JS + CSS’nin tekrar tekrar + ayrıştırılmasına ihtiyaç duymayacağı ve çok daha hızlı bir sayfadan sayfa aktarımına izin verdiği anlamına geliyordu.