कैसे और क्यों आधुनिक वेब एप्लिकेशन फ्रेमवर्क फाइल सिस्टम से URL मार्गों को डिकूप करने के लिए विकसित हुए?

67

लगभग 10 साल पहले की तुलना में मैंने राउटिंग की शैली का उपयोग करके चौखटों की ओर एक बदलाव का उल्लेख किया है जो फाइल सिस्टम से URL पथ को डिकॉउंड करता है। यह आमतौर पर फ्रंट-कंट्रोलर पैटर्न की मदद से पूरा होता है।

अर्थात्, जब पहले, URL पथ को सीधे फ़ाइल सिस्टम में मैप किया गया था और इसलिए डिस्क पर सटीक फ़ाइलों और फ़ोल्डरों को प्रतिबिंबित किया गया था, आजकल, वास्तविक URL पथों को कॉन्फ़िगरेशन के माध्यम से विशिष्ट कक्षाओं के लिए निर्देशित किया जाता है, और जैसे, अब फ़ाइल को प्रतिबिंबित नहीं करता है सिस्टम फ़ोल्डर और फ़ाइल संरचना।

सवाल

यह कैसे और क्यों आम हो गया? यह कैसे और क्यों तय किया गया कि यह उस बिंदु पर "बेहतर" है जहां एक बार-आम-से-सीधे फ़ाइल दृष्टिकोण को प्रभावी ढंग से छोड़ दिया गया था?

अन्य उत्तर

यहां एक समान उत्तर है जो मार्ग की अवधारणा में थोड़ा सा जाता है और कुछ लाभ और कमियां हैं: PHP के ढांचे के साथ, "मार्ग" अवधारणा का उपयोग क्यों किया जाता है?

लेकिन यह ऐतिहासिक परिवर्तन पहलुओं को संबोधित नहीं करता है, या यह परिवर्तन कैसे या क्यों धीरे-धीरे हुआ है, जहां आजकल कोई भी नई परियोजनाएं इस नए रूटिंग शैली पैटर्न का उपयोग कर रही हैं और डायरेक्ट-टू-फ़ाइल पुराना या छोड़ दिया गया है।

इसके अलावा, उन लाभों और कमियों का उल्लेख किया गया है, जो इस तरह के वैश्विक परिवर्तन को वारंट करने के लिए पर्याप्त महत्वपूर्ण नहीं हैं। एकमात्र लाभ जो मैं इस परिवर्तन को देख सकता हूं वह शायद एंड-यूज़र से फ़ाइल / फ़ोल्डर सिस्टम को छिपा रहा है, और इसकी कमी भी है ?param=value&param2=value, जो URL को एक टैड क्लीनर दिखता है। लेकिन क्या वे बदलाव का एकमात्र कारण थे? और यदि हाँ, तो इसके पीछे वे कारण क्यों थे ?

उदाहरण:

मैं PHP चौखटे से सबसे ज्यादा परिचित हूं और कई लोकप्रिय आधुनिक चौखटे इस डिकॉयड रूटिंग दृष्टिकोण का उपयोग करते हैं। यह काम करने के लिए आप अपाचे या इसी तरह के वेब सर्वर में URL पुनर्लेखन स्थापित करते हैं , जहाँ वेब एप्लिकेशन कार्यक्षमता आमतौर पर डायरेक्ट-टू-फ़ाइल URL पथ के माध्यम से ट्रिगर नहीं होती है।

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-अर्थपूर्ण / सुविधाओं / रूटर / zf2 /

Zend फ्रेमवर्क

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

web-applications history routing

— डेनिस
स्रोत

14

क्या वास्तव में ऐसा कोई बदलाव हुआ था? या शायद अधिकांश भाषाओं / चौखटों ने कभी प्रत्यक्ष फाइलसिस्टम मैपिंग का उपयोग नहीं किया है? शायद यह सिर्फ PHP कि बाकी के साथ पकड़ रहा है? आपकी टिप्पणियों में मेरी राय गलत है, इसलिए कोई अच्छा जवाब नहीं है। यह भी "शिफ्ट" आप केवल PHP दुनिया में उल्लेख किया है। लेकिन यह मेरी राय में बहुत व्यापक सवाल है ...

— rsm

2

@rsm मेरी भी ऐसी ही पहली प्रतिक्रिया थी, लेकिन आगे के विचार पर, यह वास्तव में कुछ ऐसा है जो कई भाषाओं और प्लेटफार्मों पर किया गया है, जिससे यह वास्तव में कमजोरियों का एक सामान्य स्रोत है।

— जिमीजैम

6

@rsm, यह PHP फ्रेमवर्क में अधिक स्पष्ट हो सकता है, लेकिन किसी अन्य तरीके का उपयोग करने के लिए - एक निश्चित समय पर, इससे पहले कि कोई फ्रेमवर्क वास्तव में पकड़ा जाए, यह एएसपी, .NET, पीएचपी, जेएसपी, आदि हो, वेब ज्यादातर प्रत्यक्ष रूप से उपयोग किया जाता है- फ़ाइल के लिए दृष्टिकोण। इन सभी चौखटों का विकास डिकोडिंग दृष्टिकोण के उपयोग के लिए क्यों हुआ? तकनीकी रूप से, प्रत्यक्ष-से-फ़ाइल दृष्टिकोण अभी भी संभव है, और मुझे यकीन है कि आधुनिक फ्रेमवर्क इसका उपयोग कर सकते हैं। या वे कर सकते हैं? हो सकता है कि वे नहीं कर सकते, और शायद कुछ अच्छे कारण भी हैं कि वे क्यों नहीं? वे कारण क्या होंगे ..? वे ऐसा करने का कोई तरीका या प्लगइन भी नहीं देते हैं, उन्होंने सीधे-सीधे फ़ाइल को पूरी तरह से मिटा दिया है।

— डेनिस

2

क्या यह यूआरआई (और पहचानकर्ता ) के रूप में एक URL (एक लोकेटर , कैसे एक संसाधन खोजने के लिए) को देखने के बारे में नहीं है ?

— हेगन वॉन एटिजन

2

प्राचीन इतिहास से संबंधित पठन: कूल यूआरआई न बदलें - टिम बर्नर्स-ली, 1998

— माइकल हैम्पटन

72

अपने सबसे बुनियादी रूप में, एक वेबसाइट स्टैटिक फाइल्स परोसती है। URL पथ को फ़ाइल पथ पर मैप करना सबसे स्पष्ट विकल्प है; अनिवार्य रूप से, यह केवल पढ़ने वाली एफ़टीपी साइट है।

तब लोग पृष्ठ की सामग्री को कुछ स्क्रिप्टिंग के साथ बदलना चाहते थे। सबसे आसान तरीका एक स्क्रिप्टिंग भाषा को पृष्ठ में एम्बेड करना और एक दुभाषिया के माध्यम से चलाना है। फिर से, पहले से मौजूद पथ -> फ़ाइल पथ रूटिंग को देखते हुए, यह काफी सरल था।

लेकिन वास्तव में, आप उस फ़ाइल को अब दुभाषिया के तर्क के रूप में चला रहे हैं। आपको यह पहचानना होगा कि अनुरोध स्थिर फ़ाइल के लिए कब है और जब यह ऐसी चीज़ के लिए है जिसकी आपको व्याख्या करने की आवश्यकता है।

एक बार जब आप अधिक उन्नत संकलित भाषाओं का उपयोग करना शुरू करते हैं, तो आप फ़ाइल स्थान से और भी अधिक तलाकशुदा होते हैं।

साथ ही, आपका वेब सर्वर पहले से ही स्थिर फाइलों को कैच कर रहा है और सभी प्रकार के अनुकूलन कर रहा है, जिसका अर्थ है कि फाइल सिस्टम को रोकना नियम के बजाय अपवाद है। इस बिंदु पर, पुराने लिंक फ़ाइल सिस्टम पथ मदद से अधिक बाधा है।

लेकिन मुझे लगता है कि वास्तविक समुद्र परिवर्तन तब हुआ जब उपयोगकर्ता फ़ाइल एक्सटेंशन को रास्ते से हटाना चाहते थे। MyPage.asp या myPage.php प्राप्त करना कुछ ऐसा था जो 'सामान्य' लोगों को भ्रमित करता था और SEO में हस्तक्षेप करता था।

क्योंकि उपयोगकर्ता पथ को देखता है, यह वेब के UI का हिस्सा बन गया है, और इस तरह, इसे किसी भी तकनीकी सीमाओं से पूरी तरह मुक्त होने की आवश्यकता है। हमने 'www' खो दिया है और वस्तुतः सब कुछ '.com' है। एकाधिक URL एक ही पृष्ठ पर इंगित होंगे।

अगर मैं mydomain.com/sale बनाम www.mydomain.co.uk/products/sale.aspx के साथ अधिक पैसा कमाता हूं, तो मैं नहीं चाहता कि कोई तकनीकी सीमाएं मेरे रास्ते में खड़ी हों।

— ईवान
स्रोत

7

मैंने हमेशा सोचा था कि फ़ाइल एक्सटेंशन को छिपाने की इच्छा "अस्पष्टता से सुरक्षा" के हिस्से में थी - यह बताने के लिए थोड़ा कठिन है कि किसी साइट द्वारा किस तकनीक को नियोजित किया गया था ताकि कुछ सर्वरों के विशेष संलग्न / ज्ञात कारनामों को लक्षित करना आसान हो सके। और उस समय तकनीक

— कायुस जार्ड

20

@CaiusJard इसका एक हिस्सा है, लेकिन एक और हिस्सा प्रौद्योगिकी अज्ञेयवाद है - हमारे रास्तों में file.html को प्रतिस्थापित करने के बाद, हम बाद में एक और स्विच के साथ अटकना नहीं चाहते थे (उदाहरण के लिए, file.phtml to file.php, या यहां तक कि file.asp)। लेकिन चूंकि हम URL और फाइलसिस्टम पथ (रूटिंग या जो कुछ भी) का उपयोग डेटाबेस रिकॉर्ड और / या अन्य स्रोतों से निर्मित संसाधनों तक पहुंचने के लिए कर रहे हैं, उनका URL में एक्सटेंशन क्यों है?

— होरस्कॉल

39

@HorusKol प्रौद्योगिकी अज्ञेयवाद आपके पथ की सभी फ़ाइलों को बदलने के बारे में भी नहीं है। अपने ग्राहक के वर्कफ़्लो और बुकमार्क्स को तोड़े बिना बैकएंड प्रौद्योगिकियों को बदलने में सक्षम होना और आपके एसईओ को नष्ट किए बिना बहुत बड़ा हो सकता है ।

— शेन

7

दिलचस्प बात यह है कि URI में फ़ाइल नाम एक्सटेंशन रखने की कभी भी सिफारिश नहीं की गई थी, इसलिए उन्हें फ़ाइल सिस्टम से जल्द ही हटा दिया जाना चाहिए था। इसके लिए सबसे पहला संदर्भ मैं 1998 से पा सकता हूं , जो वास्तव में इस उत्तर में वर्णित अधिकांश घटनाओं से पहले का है।

— कोनराड रुडोल्फ

8

पुराने दिनों में mydomain.com/sale ने अभी भी काम किया; इसे / बिक्री / / पर लोड किया गया और ठीक लोड किया गया (आपका पृष्ठ mydomain.com/sale/index.aspx था लेकिन किसी ने कभी भी index.aspx नहीं देखा)।

— जोशुआ

39

आप रॉय वीलिंग द्वारा एक सफेद कागज पर देख सकते हैं कि कब और क्यों के रूप में प्रतिनिधित्व राज्य हस्तांतरण (आरईएसटी) पर । पहली रूपरेखा जिसके बारे में मुझे पता था कि एक संसाधन और एक फ़ाइल के बीच का अंतर था रूबी ऑन रेल्स - URL से कोड रूटिंग की अवधारणा को पेश करता है।

परिवर्तन के पीछे REST की मुख्य अवधारणाएँ थीं:

एक URL एक संसाधन का प्रतिनिधित्व करता है
उस संसाधन में कई अभ्यावेदन हो सकते हैं
यदि एप्लिकेशन का पुनर्गठन किया जाता है तो URL को नहीं तोड़ना चाहिए
अनुप्रयोगों को वेब की निष्क्रियता को गले लगाना चाहिए

URL द्वारा सीधे फ़ाइलों की सेवा करने का मुख्य दोष यह है कि आप निम्नलिखित समस्याओं का अनुभव करते हैं:

संसाधन लिंक लगातार टूट रहे हैं क्योंकि वेब-साइटें पुनर्गठित हैं
संसाधन और प्रतिनिधित्व एक साथ बंधे हैं

मुझे लगता है कि कुछ उचित संतुलन प्रदान करना महत्वपूर्ण है:

सभी संसाधन महत्व में समान नहीं हैं। यही कारण है कि आपके पास अभी भी शैली आधारित संसाधन सीधे सेवा में हैं (CSS, जावास्क्रिप्ट / एक्मास्क्रिप्ट, चित्र)
HATEOAS जैसे REST के शोधन हैं जो एकल पृष्ठ ऐप्स का बेहतर समर्थन करते हैं।

— बेरिन लोरिट्श
स्रोत

जब आप कहते हैं कि प्रतिनिधित्व का मतलब क्या है जैसे कि JSON / HTML / TEXT / etc? मैं अस्पष्ट रूप से REST से परिचित हूं, लेकिन मुझे लगता है कि REST के साथ भी आपको प्रतिक्रिया प्रतिनिधित्व को बदलने के लिए किसी तरह का ट्रिगर होना चाहिए ...

— डेनिस

@ डेनिस, हाँ। HTTP में कई हेडर हैं जिनका उपयोग वांछित रूप में करने के लिए किया जा सकता है ( developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation ) और REST HTTP की ताकत को गले लगाने के बारे में था। हालाँकि, किसी ऐप के लिए वांछित सामग्री पर बातचीत करने का मालिकाना तरीका होना अभी भी असामान्य नहीं है।

— बेरिन लोरिट्श

5

CGI (1993), सर्वलेट्स (1997) और JSP (1999) ने अक्सर फाइल सिस्टम से URL को डिकोड किया, और REST (2000) को प्री-डेट किया। हालाँकि यह उत्तर मूल रूप से डिज़ाइन पैटर्न की लोकप्रियता के कारणों की पहचान करने में सही है: रीस्ट्स, जावा स्ट्रट्स और रूबी ऑन रेल्स का प्रतिनिधित्व से संसाधनों को अलग करने की 21 वीं सदी की लोकप्रियता पर व्यापक प्रभाव है।

— dcorking

1

फील्डिंग के पेपर के अनुसार, "REST का पहला संस्करण अक्टूबर 1994 और अगस्त 1995 के बीच विकसित किया गया था"

— कॉनर

1

@dcorking, उस समय CGI ने फ़ाइलों से URL को कम नहीं किया था, यह केवल 9 के बजाय 9 बार फ़ाइल को चलाता था। सर्वलेट निकटतम मैच हो सकता है, लेकिन यदि आप मार्गों की अवधारणा के बारे में बात कर रहे हैं और एक डिज़ाइन किया गया url स्थान है , कि रेल और ढांचे के साथ आया था।

— बेरिन लोरिट्श

20

मुझे नहीं लगता कि यह आधुनिक वेब एप्लिकेशन फ्रेमवर्क का एक गुण है , यह ज्यादातर सामान्य रूप से सेवा करने वाले डायनेमिक पेज का एक आर्टिफैक्ट है।

में पुराने दिनों ज्यादातर स्थिर वेब पृष्ठों है, जहां एक सॉफ्टवेयर उनके रास्ते से फाइल सिस्टम से अलग-अलग फ़ाइलों की सेवा की थी। उन्होंने ऐसा ज्यादातर इसलिए किया क्योंकि सिस्टम पथों को फाइल करने के लिए URL पथों का 1: 1 मैपिंग (वेब रूट के रूप में निर्दिष्ट एक निर्देशिका के साथ) स्पष्ट विकल्प था, हालांकि URL पुनर्लेखन (जैसे कि फ़ाइल को स्थानांतरित करने के बाद पुनर्निर्देशित करना) आम था।

फिर गतिशील सामग्री परोसने की उम्र आ गई। CGI लिपियों (और उनसे सब कुछ विकसित हुआ) ने मक्खी पर पृष्ठों को बनाया, किसी प्रकार के डेटाबेस द्वारा समर्थित किया गया। URL में GET पैरामीटर सामान्य हो गया, उदाहरण के लिए en.wikipedia.org/w/index.php?title=Path_(computing) ।

हालाँकि यह केवल पथ खंडों से युक्त पठनीय URL के लिए अधिक उपयोगकर्ता-प्रिय है। इसलिए डायनामिक एप्लिकेशन ने मापदंडों के लिए सरल पथ (उदाहरण के लिए en.wikipedia.org/wiki/Path_(computing) मैप किए , और इन मैपिंग को "मार्गों" के रूप में जाना जाता है।

शायद यह दृष्टिकोण अधिक हाल ही में महसूस करता है क्योंकि लोकप्रियता प्राप्त हुई जब प्रयोज्य के महत्व को अधिक व्यापक रूप से मान्यता दी गई थी, और यह भी एसईओ का हिस्सा बन गया। शायद यही कारण है कि इसे सीधे बड़े वेब फ्रेमवर्क में बनाया गया था।

— Bergi
स्रोत

12

एक कारण यह है कि हर अनुरोध पर डिस्क से एक फ़ाइल लोड करना धीमा है, इसलिए वेब सर्वर ने मेमोरी में फ़ाइलों को कैश करने के तरीके बनाना शुरू कर दिया है, अगर आप इसे किसी भी तरह से मेमोरी में रखने की कोशिश करने जा रहे हैं, तो यह क्यों मायने रखता है कि यह कहां पर था डिस्क?

एक कारण यह है कि कई वेब फ्रेमवर्क संकलित भाषाओं में लिखे गए हैं, इसलिए आपके पास डिस्क पर एक फ़ाइल संरचना, बस एक jarफ़ाइल या जो कुछ भी नहीं है। संकलित भाषाओं ने उन विचारों को उधार लिया जो उन्हें संकलित लोगों से पसंद थे।

एक कारण अधिक अर्थपूर्ण, गतिशील मार्गों की इच्छा है, जैसे https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes। जाहिर है, आप एक /var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.phpफ़ाइल नहीं चाहते हैं । आप इस तरह के मार्ग बनाने के लिए वेब सर्वर कॉन्फ़िगरेशन में url- पुनर्लेखन नियम बनाते थे। अब यह सिर्फ एक कोड परिवर्तन है, जो परिचालन में बहुत सरल है।

— कार्ल बेवफेल्ड
स्रोत

आपको उस उदाहरण के लिए url पुनर्लेखन की आवश्यकता नहीं है।

— 2229 पर Y29295

1

यह कोड द्वारा संभाला गया है जो पथ के पहले भाग को पहचानता है, और डेटाबेस में प्रश्न देखने के लिए संख्या / 363517 / का उपयोग करता है। वेब सर्वर के साथ कुछ भी नहीं करना है, लेकिन एक आवेदन ...

— विल क्रॉफर्ड

11

प्रमुख कारणों में यह संभावना है कि यूआरआई को फाइल पथों पर मैप करने के इस दृष्टिकोण से बड़ी संख्या में डेटा पाथ ट्रैवेलल के माध्यम से डेटा के आकस्मिक रिलीज की ओर बढ़ गया है।

जब आप फ़ाइल सिस्टम में पथ को मैप करते हैं, तो इसका मतलब है कि आपको यह जांचने की आवश्यकता है कि आपको प्राप्त होने वाले प्रत्येक पथ को फ़ाइलों के लिए अनुरोध मानचित्र के रूप में प्राप्त किया जाना चाहिए जो ग्राहकों के माध्यम से सुलभ होना चाहिए। गारंटी देने के लिए एक सरल तरीका यह है कि पारदर्शी मैपिंग को खत्म करना और इसे अधिक स्पष्ट रूप से करना है।

यह एक PHP- केवल समस्या नहीं है। जैसा कि यहां साक्ष्य अपाचे सख्त गाइड का एक प्रासंगिक अनुभाग है ।

— JimmyJames
स्रोत

1

क्यों होता है पतन?

— जिमीजैम

8

मैं उद्योग के लिए जवाब नहीं दे सकता, लेकिन मैं आपको बता सकता हूं कि मैं 2000 के शुरुआती दिनों में वर्चुअल 'मार्गों' की ओर URL = फाइल सिस्टम से दूर क्यों चला गया।

'पुराने स्कूल' PHP के साथ काम करना, यदि आपके पास 1000 PHP पृष्ठ हैं, तो आपके पास उन पृष्ठों का प्रतिनिधित्व करने वाली 1000 PHP फाइलें होंगी। प्रत्येक एक डुप्लिकेट हेडिंग / पाद लेख में शामिल है और संभवतः कुछ अन्य तर्क। अब हम कहते हैं कि आपको इसे बदलने की आवश्यकता है। अब आपके हाथ में क्या गड़बड़ है! आपको या तो सभी 1000 फ़ाइलों को बदलना होगा, या आप सभी मामलों को संभालने के लिए शीर्ष लेख / पाद लेख में बहुत ही बदसूरत कोड की गड़बड़ी के साथ समाप्त करेंगे। वर्चुअल रास्तों का उपयोग करके, आपके हेडर / फ़ूटर लॉजिक, डेटाबेस कनेक्शन लॉजिक और अन्य इनिशियलाइज़ेशन को एक बार , अवधि में शामिल किया जाता है । साथ काम करने के लिए बहुत बेहतर है।

दूसरा कारण अस्पष्टता से बचना है। जैसे-जैसे एप्लिकेशन बढ़ते हैं, हेडर / फूटर शामिल हो जाते हैं और अधिक जटिल हो जाते हैं। उन्होंने आमतौर पर अपने स्वयं के घोंसले को शामिल किया था जो विभिन्न चीजों पर निर्भर थे। 'पृष्ठ' के लिए PHP फ़ाइल में, अक्सर आपने अस्पष्टता का सामना किया कि क्या कोई चर () या नहीं है। आभासी मार्गों का उपयोग करना, और एक आवेदन जहां आपको हर चीज की आवश्यकता होती है, प्रत्येक पृष्ठ लोड पर लोड किया जाता है, आपको अब यह चिंता नहीं है।

अन्त में (हालांकि अन्य कारण भी हैं, लेकिन यह अंतिम सूची मैं हूँ), उन 1000 पृष्ठों में से कई कोड का प्रतिनिधित्व करते हैं जिन्हें दोहराया जाएगा। इसलिए कक्षाओं और टेम्पलेट्स के एक उचित सेट में रिफैक्ट करने के बाद, कोड को बहुत सरल बना दिया जाता है और आप उन 1000 फाइलों के बिना सब कुछ कर सकते हैं जो आप करना चाहते हैं।

— GrandmasterB
स्रोत

क्या आप अधिक कह सकते हैं कि आप बहुत बदसूरत कोड के साथ क्यों समाप्त होंगे? मैं 1000 फ़ाइलों को बदलने की आवश्यकता देख सकता हूं (यह हेडर / फ़ूटर को अपडेट करना शामिल है), लेकिन आपको बदसूरत कोड की गड़बड़ी से क्या मतलब है?

— डेनिस

मैंने जो अनुच्छेद जोड़ा है, उसे देखें। लेकिन मूल रूप से, जैसा कि आप अधिक मामलों को संभालने के लिए शीर्ष लेख / पाद लेख / इनिशियलाइज़ेशन कोड का विस्तार करते हैं, खासकर यदि आपने सशर्त रूप से अन्य फ़ाइलों को शामिल किया है (यह एक बुरी आदत थी, लेकिन बहुत सारे PHP प्रोग्रामर ने ऐसा किया), तो आप कोड का पालन करने के लिए बहुत मुश्किल से समाप्त होते हैं ।

— ग्रैंडमास्टरबी

5

मैं बहुत अधिक विस्तार में नहीं जाऊंगा कि यह अलगाव क्यों फायदेमंद है। मुख्य तर्क यह है कि यह अंतर्निहित कार्यान्वयन से शब्दार्थ (जो आप वास्तव में उपयोग करने की कोशिश कर रहे हैं) को अलग करता है।

यह देखते हुए कि लाभों को लागत के रूप में दिया गया है - जो एक अलग प्रश्न होगा - यह देखना मुश्किल नहीं है कि इसे धीरे-धीरे क्यों अपनाया गया। मुझे नहीं लगता कि इस वजह से एक भी घटना हुई है, हालांकि मैं निश्चित रूप से इस पर शिक्षित होने के लिए खुला रहूंगा।

कम से कम मेरे अनुभव में, शुरू में यह अक्सर अपाचे कॉन्फ़िगरेशन के माध्यम से किया जाता था - और संभवतः अन्य वेब सर्वरों ने भी इसका समर्थन किया। हालाँकि, वैचारिक रूप से कोई अच्छा कारण नहीं है कि सर्वर को इसके साथ काम सौंपा जाए। आखिरकार, मार्ग वास्तविक अनुप्रयोग के लिए विशिष्ट हैं, इसलिए यह उन्हें वहां परिभाषित करने के लिए समझ में आता है।

यह विश्व स्तर पर बदल गया, लेकिन जैसा कि आप बताते हैं, धीरे-धीरे। इसका कारण लगभग निश्चित रूप से बहुत सरल है: समय के साथ अच्छे विचार फैलते हैं। यह इसलिए भी है कि यह कोई आश्चर्य की बात नहीं है कि परिवर्तन विश्व स्तर पर हुआ। ऐसा नहीं है कि हर कोई एकजुट हो गया और इस तरह से करने का फैसला किया। बल्कि, प्रत्येक परियोजना ने इस दृष्टिकोण को अनुकूलित किया जब उन्हें लगा कि यह फायदेमंद होगा (और परियोजनाएं जो इसका समर्थन नहीं करती थीं वे अंततः गायब हो गईं)।

— आप दोगुना
स्रोत

1

RFC ने पहले से ही URI (जो कि किसी भी शब्दार्थ को स्थानीय भाग में संलग्न नहीं करता है) के साथ पहले से ही अवधारणाओं का निर्माण किया है, और URL एक विशेष मामले के रूप में है जो HTML दस्तावेजों को दस्तावेज़ के सापेक्ष लिंक का उपयोग करने की अनुमति देने के लिए पथ-जैसे शब्दार्थ प्रस्तुत करता है। आधार URL।

स्पष्ट कार्यान्वयन URL के स्थानीय भाग को सीधे फाइल सिस्टम में मैप करना है, इसलिए यह वही है जो सरल सेटअपों ने किया है - चाहे आप किसी दस्तावेज़ को देखने के लिए एक समर्पित रिलेशनल डेटाबेस का उपयोग करें, या अत्यधिक अनुकूलित कम-ओवरहेड कुंजी का लाभ उठाएं -वृक्ष की दुकान जो आपके पास पहले से ही बाहर की बात नहीं है, लेकिन दस्तावेजों की सेवा के लिए निश्चित रूप से आपकी लागत संरचना को प्रभावित करती है।

यदि आपके पास लगातार डेटा के साथ एक वेब एप्लिकेशन है, तो लागत संरचना में परिवर्तन होता है: आपके पास हमेशा एप्लिकेशन को चलाने का ओवरहेड होता है, और इसमें URL डिकोडिंग को एकीकृत करने से लागत को कम करने, लागू करने में बहुत सारी सुविधाएं आसान हो जाती हैं।

— साइमन रिक्टर
स्रोत

1

समय की शुरुआत में, URL ने सर्वर पर पथ दर्ज करने के लिए सीधे मैप किया क्योंकि यह आसान है, और वैसे भी इसे करने का कोई अन्य तरीका नहीं है, क्या है? अगर मैं मांगता हूं /path/to/index.php, तो मैं /path/to/index.phpवेबसाइट के रूट डायरेक्टरी से शुरू हो जाऊंगा (आमतौर पर सर्वर का नहीं, वेबसाइट को डायरेक्टरी में रखा जाना चाहिए या उपनिर्देशिका को और नीचे रखना चाहिए)।

फिर कुछ वर्षों के बाद, हमने पुनर्लेखन के बारे में सीखना शुरू किया, जो कि स्पष्ट रूप से पूछे जाने वाले की तुलना में एक अलग संसाधन की सेवा कर रहा है। /request/path/to/index.phpवास्तव में सेवा कर सकते हैं /response/path/to/index.php।

एक और तरकीब छिपी है index.php। अगर मैं /index.php?foo=bar&baz=quxसर्वर के लिए पूछ रहा हूँ तो इस index.phpतरह छिपाकर जवाब दे सकता है: /?foo=bar&baz=quxसभी जबकि वास्तव में index.phpवैसे भी सेवा कर रहे हैं।

अगला कदम, जो एक बड़ा महत्वपूर्ण है, वह यह है कि हमने सभी URL को रीडायरेक्ट करना सीख लिया है /index.php। तो अब, /path/to/some/pageचुपचाप पुनर्निर्देशित है /index.php?path/to/some/page। यह थोड़ा मुश्किल है, क्योंकि आम तौर पर प्रत्येक स्लैश एक नए उपनिर्देशिका का प्रतिनिधित्व करता है, लेकिन इस मामले में वेब सर्वर को पैरामीटर के रूप में भेजने के लिए कॉन्फ़िगर किया जाता है, बजाय इसे देखने के।

अब जब हमारे पास यह है, तो हमें यह सोचने का एक अलग तरीका चाहिए कि वेबसाइट कैसे व्यवस्थित हो। इससे पहले, यह विभिन्न पृष्ठों का एक ढीला संग्रह था। अब, सब कुछ एक प्रविष्टि पृष्ठ के माध्यम से रूट किया गया है। यह साइट को और अधिक जटिल बनाता है, लेकिन वे अवसर उपलब्ध कराता है जो पहले उपलब्ध नहीं थे, जैसे कि साइट-व्यापी उपयोगकर्ता प्रमाणीकरण, शीर्षलेखों, पाद लेखों और शैलियों का एक समान अनुप्रयोग, आदि।

यह आपकी सौ या हज़ार ऐप की वेबसाइट को प्रभावी रूप से बदल देता है (यदि आप प्रत्येक फ़ाइल को अपना ऐप मानते हैं) एक ही, बहुत अधिक जटिल लेकिन बहुत अधिक सुसंगत ऐप।

यह एक बड़ी छलांग है, क्योंकि आप अब यह नहीं बता सकते हैं कि किस कोड को केवल URL को देखकर निष्पादित किया जाएगा। अब आपको यह समझने की आवश्यकता है कि आपका विशेष ढांचा URL पथों को कोड पथों में कैसे परिवर्तित करता है, और यद्यपि चौखटों के बीच समानताएं हैं, अधिकांश अलग-अलग हैं जो आपको कोड के साथ काम करने में सक्षम होने के लिए कुछ परिचित होने की आवश्यकता है।

छोटी कहानी, यह खोज का क्रमिक विकास था, न कि अचानक छलांग, और प्रत्येक डेवलपर को खोज की एक ही यात्रा से गुजरना पड़ा। जब तक आप वास्तव में जल्दी से अमूर्त अवधारणाओं को समझ नहीं सकते, तब तक सीखने की अवस्था बहुत ही कठिन है।

— सीजे डेनिस
स्रोत

-1

एक लंबे समय के वेबदेव के रूप में, मुझे लगता है कि एचटीएमएल 5 के समय के आसपास नेविगेशन-कम इतिहास नियंत्रण ( history.pushState()) के आगमन ने इसे व्यावहारिक बना दिया। इससे पहले, आपको URL बार अपडेट करने के लिए पृष्ठ को फिर से लोड करना होगा, जब तक कि आपने केवल खंड ( /path#fragment) को अपडेट नहीं किया है । यह टुकड़ा सर्वर के लिए अदृश्य था (इसे रूट नहीं किया गया था), इसलिए डायनेमिक पेज को रिफ्रेश या बुकमार्क करने का एकमात्र तरीका जावास्क्रिप्ट के माध्यम से था।

यह एसईओ के लिए प्रमुख निहितार्थ है, और गूगल का नेतृत्व करने के लिए शायद ही कभी इस्तेमाल किया गया "हैशबैंग" स्कीमा विकसित किया है जो भौतिक यूआरएल के लिए गतिशील हैश के सर्वर-साइड मैपिंग की आवश्यकता है। यह रोबोटों के बीच अनजाना और सार्वभौमिक नहीं था, जिससे (झूठे) स्वयंसिद्ध प्रमुख थे: "मकड़ियों अजाक्स सामग्री को क्रॉल नहीं कर सकते हैं"। लेकिन अजाक्स सामग्री के लाभ मूर्त हैं: उदाहरण के लिए गूगल मैप्स w / o JS का उपयोग करने का प्रयास करें।

समाधान URL बार को एक मान के साथ अपडेट करने का एक तरीका था, जिसे सर्वर पर मिरर किया जा सकता है (बुकमार्क और जेएस-कम रिफ्रेशिंग की अनुमति), पृष्ठ को फिर से लोड किए बिना। एक बार यह क्षमता उपलब्ध होने के बाद, डेवलपर्स केवल "मुख्य सामग्री अनुभाग", URL बार और ब्रेडक्रंब को अपडेट करके एक साइट को "नेविगेट" कर सकते हैं। इसका मतलब यह था कि सभी JS + CSS को Refetched + पार्स की आवश्यकता नहीं थी, जिससे MUCH तेज़ पेज-टू-पेज ट्रांसफर हो सके।

— dandavis
स्रोत