Cool URIs बदसूरत हो सकते हैं (2023)

मूल लेख ↗ Hacker News चर्चा ↗

Cloudflare Pages के `.html` फ़ाइलों से extension-less URLs पर अपने-आप और स्थायी redirects ने इस बहस को फिर से जगा दिया है कि web addresses को “cool” और स्थिर क्या बनाता है। टिप्पणीकार साफ़, तकनीक-तटस्थ URLs के लाभों की तुलना `.html` दिखाने की व्यावहारिक सरलता से करते हैं, hosting providers द्वारा opt-out के बिना URL schemes बदलने की चिंता जताते हैं, और W3C के उस आदर्श पर लौटते हैं कि links दशकों तक वैध रहनी चाहिए। चर्चा link rot, redirects, REST-style paths बनाम query parameters, और यह कि file extensions जैसे implementation details को उजागर करना long-term maintainability को कितना प्रभावित करता है, इन प्रश्नों तक फैल जाती है।

Cloudflare / GitHub का व्यवहार और रीडायरेक्ट्स

  • Cloudflare Pages स्वतः .html को एक्सटेंशन‑रहित URLs पर रीडायरेक्ट करता है और उन्हें स्थायी मानता है; कुछ लोग इसे एक महत्वपूर्ण, दखल देने वाली “फ़ीचर” मानते हैं जिसे opt-in होना चाहिए।
  • दूसरे तर्क देते हैं कि यह कई static hosts और web servers में लंबे समय से चला आ रहा व्यवहार है, जो filesystem extensions और URL content types के बीच असंगति से प्रेरित है।
  • आलोचना का केंद्र इसकी permanence (301s) और configuration विकल्पों की कमी है; समर्थक इसे bug नहीं, बल्कि product decision मानते हैं।
  • GitHub Pages में भी इसी तरह के mapping rules हैं (/foo → foo.html, folder → folder/ → folder/index.html), लेकिन आम तौर पर permanent redirects के बिना।

Cool URIs, Extensions, और Future‑Proofing

  • .html के विरुद्ध W3C का “Cool URIs don’t change” दृष्टिकोण फिर से देखा जाता है।
  • कुछ लोग मानते हैं कि extensions backend details उजागर करते हैं और भविष्य में टूटने का जोखिम बढ़ाते हैं; अन्य कहते हैं कि .html पर्याप्त स्थिर है और सामान्य साइटों के लिए बदलने की संभावना कम है।
  • एक आम व्यावहारिक दृष्टिकोण: यदि आप .html चुनते हैं और उसे स्थिर रखते हैं, तो वही “cool” URL बन जाता है; backends को मौजूदा URLs के अनुसार ढलना चाहिए, उल्टा नहीं।
  • कुछ frameworks extensions को सीधे MIME types (.json, .xml, आदि) से जोड़ते हैं, debugging aid के रूप में।

किसे “Ugly” URL माना जाता है

  • कई प्रतिभागी “ugly” शब्द को लंबे, parameters‑भरे या hash‑encoded URLs के लिए सुरक्षित रखते हैं, न कि साधारण /year/slug.html के लिए।
  • ऐतिहासिक उदाहरणों में comma‑infested CMS URLs, fragments में JSON blobs, tracking query strings, और जटिल enterprise app URLs शामिल हैं।
  • IDs और slugs वाले static paths (/category/123/post-name) को एक अच्छा संतुलन माना जाता है: स्थिर identifier के साथ human readability।

Redirects, Link Rot, और ज़िम्मेदारी

  • एक पक्ष: site operators पर URLs को हमेशा बनाए रखने की बाध्यता नहीं है; “cool URIs” वाली भाषा नैतिक उपदेश जैसी लग सकती है।
  • दूसरा पक्ष: redirects बनाए रखना कम मेहनत वाला और शिष्ट व्यवहार है; link rot मुख्यतः targets के बदलने से होती है, link authors से नहीं।
  • कुछ लोग सुझाव देते हैं कि static-site workflows भी सरल redirect pages या meta-refreshes स्वतः उत्पन्न कर सकते हैं।

Implementation Details और Monitoring संबंधी चिंताएँ

  • लोकप्रिय पैटर्न: /blog/slug/ directory के साथ index.html, कभी-कभी प्रति post संबंधित assets रखने के लिए भी।
  • Content negotiation और alternative formats (Markdown, multilingual variants) अक्सर static generators की धारणाओं से टकराते हैं।
  • Observability practitioners path segments में user data डालना पसंद नहीं करते, क्योंकि इससे metrics और logging जटिल हो जाते हैं; वे query parameters को प्राथमिकता देते हैं।

URIs बनाम URLs

  • URIs, URLs, URNs, और उनके RFC lineage का एक छोटा ऐतिहासिक recap दिया गया है।
  • कई लोग सहमत हैं कि रोज़मर्रा के web work में “URL” ही एकमात्र व्यावहारिक रूप से उपयोगी शब्द है, भले ही “URI” तकनीकी रूप से अधिक सामान्य हो।