URI vs URL vs URN Açıklandı: Gerçekten Önemli Olan Farklar

URI, URL ve URN Neden Birbirinin Yerine Kullanılıyor Gibi Görünüyor

Muhtemelen bu etiket değişiminin gerçek zamanlı olarak gerçekleştiğini gördünüz. Tarayıcınız URL hakkında konuşur. Bir API belgesi URI hakkında konuşur. Sonra bir standart örneği URN’yi ortaya atıp web’in aynı şey için üçüncü bir ad icat ettiğini ima eder.

Bu karışıklık normaldir. Terimler gerçekten web yığınının farklı bölümlerinde ortaya çıkar ve internet her zaman durup neden olduğunu açıklamak için yeterince nazik değildir. Bu bir okuyucu başarısızlığı değildir ve standartlar avukatları için önemsiz bir konu değildir. Bunu yaklaşmanın yararlı yolu pratik olarak başlamaktır: URI şemsiye, URL adres, URN ise kararlı addır. Bu model bir kez anlaşıldığında, tarayıcı belgeleri, HTTP özellikleri, API referansları ve barındırma materyali birbirini çeliştirir gibi görünmeyi bırakır.

Hızlı Referans: İlk Olarak İhtiyacınız Olan Tek Terimler

Ana açıklamaya başlamadan önce yalnızca az miktarda ortak kelime dağarcığına ihtiyacınız vardır ve bu sözlük kasıtlı olarak kapsamlı yerine pratiktir.

URI vs URL vs URN Bir Dakikada

Yalnızca kısa versiyonu istiyorsanız, şu şekildedir: bir şeyi tanımlarsa, URI’dir. Nereye veya nasıl ulaşacağınızı söylerse, URL gibi davranıyor. Bir şeyi kararlı bir şekilde adlandırmak için tasarlanmışsa, URN gibi davranıyor. Çoğu günlük tarama, web siteleri ve barındırma konuşmaları URL alanında yaşar çünkü bunlar insanların ve yazılımın gerçekten kullanabileceği adresler hakkındadır.

Bunları açmadan önce yan yana üç temiz örnek:

https://example.com/docs
mailto:hello@example.com
urn:isbn:9780141036144

Birincisi, çoğu okuyucunun zaten bildiği günlük durumdur. İkincisi hala bir tanımlayıcıdır, ancak bir web sayfası değildir. Üçüncüsü, yönetilen bir ad alanı içinde kararlı bir addır. İşte tüm harita küçük ölçekte.

URI Aslında Nedir

Yük taşıyan fikir RFC 3986’dan gelir, ancak sade İngilizce versiyonu basittir: bir URI bir kaynağı tanımlar. resource sözcüğü soyut görünür, ta ki bunu insan örneklerine geri çevirene kadar. Bu makalede, bir web sayfası, bir API uç noktası, bir dosya, bir posta kutusu, bir belge veya hatta bir kayıt defterindeki adlandırılmış bir şey anlamına gelebilir.

Önemli ayrım tanımlama ve erişim arasındadır. Bir URI, bir şeyin ne olduğunu söyleyebilir, ancak bunu açabileceğiniz, getirebileceğiniz veya hatta bir tarayıcıda etkileşime girebileceğiniz konusunda söz vermez. Bu nedenle “URI” “web adresi”nden daha geniştir. Öncelikle adlandırma veya tanımlama hakkındadır.

İlişkiyi şöyle düşünün:

URI
├── URL  → identifies by location or access path
└── URN  → identifies by stable name inside a namespace

Bu şemsiye analojisi tutulması gereken olandır. URL ve URN, URI’nin yanında oturan rakip terimler değildir. Onun içinde oturuyorlar.

Bir URI’nin kapsayabileceği aralığın hızlı bir hatırlatması:

https://example.com/docs        → a webpage
mailto:hello@example.com        → a mailbox target
urn:ietf:rfc:3986               → a named standards document

📝 Not: Her URI, bir tarayıcıda açabileceğiniz bir şey değildir.

Bazı URI’ler tarayıcı dostu, bazıları değildir. Bu, çoğu okuyucunun en çok ihtiyaç duyduğu düzeltmedir, çünkü URI’yi URL’nin resmi sounding eşanlamlısından başka bir şey olarak ele alma alışkanlığını kırar.

Bir URL’yi URL Yapan Nedir

URL’nin en kolay sade dil anlamı hala web adresidir. Çoğu insanın terimi bu şekilde karşılaştığı ve bu yanlış değildir. Biraz daha kesin bir versiyon, URL’nin bir kaynağa ulaşmak için yeterli konum veya erişim bilgisi veren URI türü olmasıdır, bu nedenle normal web kullanımında hakim olur.

Şöyle bir barındırılan adres alın. Okuyucuların zaten her gün gördüğü parçaları gösterir, hatta bunları resmi olarak adlandırmasalar da:

https://shop.alexhost.com/products?id=42#reviews
│       │                 │           │  │
│       │                 │           │  └─ fragment
│       │                 │           └──── query
│       │                 └──────────────── path
│       └────────────────────────────────── host/domain
└────────────────────────────────────────── scheme

scheme yazılıma ne tür bir erişim deseniyle uğraştığını söyler. host veya domain hangi hizmete bağlanacağını söyler. path o hizmetin içindeki bir konuma işaret eder. query ek talimatlar veya filtreler ekler. fragment geri kalanından farklıdır: genellikle istemcinin #reviews gibi bir bölüme atlamasına yardımcı olur ve isteğin bir parçası olarak sunucuya gönderilmez.

Bu aynı zamanda okuyucuların mutlak ve göreceli referanslar hakkında duyabileceği yerdir. Mutlak bir URL https://example.com/docs/install gibi tam adresi içerir. Göreceli bir referans bunu /docs/install gibi bir şeye kırpar, bu da yalnızca mevcut bir temel adres bağlamında anlamlıdır. Burada tam bir yönlendirme öğreticisine ihtiyacınız yok; yalnızca her iki formun neden geliştirici belgelerinde göründüğünü tanımanız gerekir.

Gerçek barındırılan web çalışmasında, bu genellikle insanların en çok önemsediği katmandır. Temiz URL’ler kullanıcıların tıkladıklarına güvenmesine yardımcı olur, takımların belgeleri okunabilir tutmasına yardımcı olur ve işletmelerin uygulama veya pazarlama yollarını zaman içinde tutarlı tutmasına yardımcı olur. Bir site, belge portalı veya mağaza dağıtıyorsanız, okunabilir URL yapısı URN teorisinden çok daha önemlidir.

URN’yi Farklı Yapan Nedir

URN, urn: şeması altında bir URI’dir ve işi normal bir adresinkinden farklıdır. Bir şeyin nerede yaşadığını söylemek yerine, daha sonra depolama konumu veya alma yöntemi değişse bile onu kalıcı olarak adlandırmak için tasarlanmıştır. Bu nedenle buradaki en iyi analoji bir sokak adresi değil, bir kayıt defteri veya katalog adıdır.

Temel desen şöyle görünür:

urn:<NID>:<NSS>

urn:isbn:9780141036144
urn:ietf:rfc:3986

NID ad alanı tanımlayıcısı anlamına gelir: isbn veya ietf gibi hangi adlandırma sisteminde olduğunuzu söyler. NSS ad alanına özgü dize anlamına gelir: bu, o sistem içindeki gerçek addır. DOI tarzı kalıcı adlandırmanın da aynı geniş sorun ailesinde tartışıldığını göreceksiniz, çünkü yayıncılık ve kataloglama sistemleri zaman içinde kararlı kimlik hakkında derin bir şekilde önemsiyorlar.

Çoğu insanın URN’leri bir tarayıcıya yazmasının nadir olmasının nedeni basittir: tarama genellikle kayıt adlandırması değil, erişim hakkındadır. URN’ler yine de önemlidir. Standartlar, kataloglama, yayıncılık, kimlik sistemleri ve bir adın bir şey taşınsa bile anlamlı kalması gereken diğer yerlerde görünürler. IANA URN ad alanı kayıt defteri hala aktif olarak korunmaktadır, bu da URN’lerin ölü jargon değil, gerçek altyapı olduğunun iyi bir işaretidir.

⚠️ Uyarı: URN’leri yaygın tarama araçları olarak aşırı öğretmeyin. Önemlidirler, ancak URL’lerin olduğu gibi sıradan web navigasyonunun merkezi değillerdir.

İnsanların Genellikle Yanlış Anladığı İlişki

İşte temiz hiyerarşi ifadesi: tüm URL’ler URI’dir ve URN’ler URI’dir, ancak her URI bir URL değildir. Bu tek cümle çoğu karışıklığı çözer. Sorun, insanlar her tanımlayıcıyı katı bir URL-veya-URN kutusuna zorlamaya ve tüm kaynakların bölünmeyi aynı şekilde kullanması gerektiğini varsaymaya çalıştığında başlar.

📝 Not: Eski açıklamalar genellikle URL ve URN’yi URI altında düzgün alt türler olarak çizerken, daha yeni web tarafından karşılanan kaynaklar URL‘yi daha gayri resmi ve URI‘yi daha genel olarak kullanır. Bu nedenle iki güvenilir kaynak gerçekten savaşta olmadan farklı seslenebilir.

W3C açıklama materyali burada yardımcıdır çünkü klasik görünümü çağdaş görünümden ayırır. Klasik açıklama URI’yi geniş sınıf olarak ele alır ve URL ve URN’yi bir tanımlayıcının farklı davranış şekilleri olarak sunar. Çağdaş alışkanlık, özellikle tarayıcı tarafından karşılanan materyalde daha gevşektir: URL pratik web konuşmasında yaygın kalır, URI ise özelliklerde daha güvenli genel terim olarak kalır.

Bu aynı zamanda mailto: gibi kontrollü kenar durumlarının tartışmalar yarattığı nedenidir. Kesinlikle bir URI’dir. Bazı insanlar bunu bir URL olarak adlandırmaktan rahat çünkü bir şema kullanır ve yazılıma hedef üzerinde hareket etmek için bir yol verir. Diğerleri bunu kaçınır ve URL‘yi daha açıkça konuma benzer durumlar için tutar. En güvenli başlangıç çıkışı argümanı kazanmak değildir. Argümanın neden var olduğunu anlamaktır.

Tabloyu bu şekilde gördüğünüzde, zihinsel düğüm gevşer. URI geniş okuma terimidir. URL günlük adres terimidir. URN kalıcı adlandırma terimidir. Kaynaklar arasındaki anlaşmazlık genellikle tüm model bozuk olması değil, vurgu hakkındadır.

Fark Neden Gerçek Çalışmada Önemlidir

Bu ayrımın pratik değeri, partilerde daha kesin seslenmenizi sağlamak değildir. Önemlidir çünkü farklı teknik materyaller kimlik ve erişimin farklı katmanları hakkında konuşmaktadır. Bir belgenin hangi katmanı önemsediğini öğrendiğinizde, sözcük seçimi keyfi görünmeyi bırakır.

Tarayıcı ve platform belgeleri

Modern tarayıcı ve web platformu materyali genellikle URL‘ye standardize eder çünkü bu dünya çoğunlukla ayrıştırma, gezinme, köken işleme ve tarayıcıdaki adres benzeri davranış hakkındadır. Bu, insanların sayfaları açtığı, komut dosyalarını yüklediği, göreceli bağlantıları çözdüğü ve web tarafından karşılanan konumlar arasında hareket ettiği ortamdır.

📝 Not: Modern tarayıcı ve platform standartları genellikle URL terimini tercih eder, başka yerlerde eski standartlar dili URI‘yi daha geniş olarak kullansa bile.

HTTP, API ve özellikleri dili

HTTP ve protokol belgeleri genellikle URI‘yi tercih eder çünkü hedef kaynaktan daha genel olarak konuşmaktadırlar. Her zaman tam tarayıcı tarzı adres çubuğu dizesini açıklamıyorlar. Bazen bir istek hedefi, göreceli bir referans veya daha geniş bir kaynak kimlik konsepti açıklıyorlar.

Bunu daha kolay görmek için bu tür istek örneği:

GET /docs/install?lang=en HTTP/1.1
Host: example.com

Bu istek tam https://example.com/docs/install?lang=en formunu tekrarlamaz, ancak protokol açıkça bir kaynağı hedefliyordur. Bu, HTTP semantikleri ve API materyalinin genellikle kaynak URI’leri hakkında konuşmasının bir nedenidir. Dil “tarayıcıya yazılan tam adres”ten daha fazlası için yer gerektirir.

Barındırma ve işletme tarafından karşılanan web çalışması

Barındırma, pazarlama, uygulama dağıtımı ve işletme tarafından karşılanan web konuşmalarında, endişe genellikle çok daha dar ve pratiktir: temiz URL’ler, kararlı yollar, mantıklı yönlendirmeler, okunabilir etki alanları ve öngörülebilir yapı. Bir uygulamayı veya belge sitesini AlexHost VPS’de veya benzer herhangi bir barındırma platformunda dağıtırsanız, günlük operasyonel sorunuz genellikle URL tasarımının açık ve kararlı olup olmadığıdır — URN’nin kaynağı daha felsefi olarak tanımlayıp tanımlamayacağı değil.

Bu, makalenin geri dönen gerçek tezisidir. Fark, bir okuma aracı olarak en çok önemlidir. Tarayıcı belgelerinin bir şey söylediğini, API özellikleri başka bir şey söylediğini ve barındırma kılavuzlarının çoğunlukla URL’lere odaklandığını anlamanıza yardımcı olur. Her cümlede mükemmel terminoloji gerekli değildir. Bağlam değiştiğinde doğru zihinsel modele ihtiyacınız vardır.

URL, URI veya URN Ne Zaman Söyleyin

###PPT_NOTR_15