Yazar: Sir Tim Berners-Lee, URI'lerin, URL'lerin, HTTP'nin, HTML'nin ve World Wide Web'in mucidi ve W3C'nin şu anki başkanı. 1998'de yazılan makale

Hangi URI "harika" olarak kabul edilir?
Değişmeyen biri.
URI'ler nasıl değiştirilir?
URI'ler değişmez: insanlar onları değiştirir.

Teorik olarak, insanların URI'leri değiştirmeleri (veya belgeleri desteklemeyi bırakmaları) için hiçbir neden yoktur, ancak pratikte bunlardan milyonlarca tane vardır.

Teorik olarak, bir alan ad alanının nominal sahibi aslında alan ad alanının ve dolayısıyla içindeki tüm URI'lerin sahibidir. İflas dışında hiçbir şey alan adı sahibinin adı elinde tutmasını engellemez. Ve teorik olarak alan adınızın altındaki URI alanı tamamen sizin kontrolünüz altındadır, dolayısıyla onu istediğiniz kadar kararlı hale getirebilirsiniz. Bir belgenin internetten kaybolmasının hemen hemen tek iyi nedeni, alan adının sahibi olan şirketin iflas etmesi veya artık sunucuyu çalışır durumda tutamayacak durumda olmasıdır. O halde neden dünyada bu kadar çok kayıp halka var? Bunlardan bazıları sadece öngörü eksikliğidir. İşte duyabileceğiniz bazı nedenler:

Siteyi daha iyi hale getirmek için yeniden düzenledik.

Gerçekten eski URI'lerin artık çalışamayacağını mı düşünüyorsunuz? Eğer öyleyse, o zaman onları çok kötü seçtiniz. Bir sonraki yeniden tasarım için yenilerini saklamayı düşünün.

Elimizde o kadar çok şey var ki, neyin güncelliğini yitirdiğini, neyin gizli olduğunu ve neyin hala güncel olduğunu takip edemiyoruz, bu yüzden hepsini kapatmanın en iyisi olduğunu düşündük.

Sadece sempati duyabiliyorum. W3C, arşiv materyallerini halka açık hale getirmeden önce gizlilik açısından dikkatli bir şekilde incelememiz gereken bir dönemden geçti. Karar önceden düşünülmelidir - her belgeye kabul edilebilir okuyucu sayısını, oluşturulma tarihini ve ideal olarak son kullanma tarihini kaydettiğinizden emin olun. Bu meta verileri kaydedin.

Dosyaları taşımamız gerektiğini keşfettik...

Bu en acıklı bahanelerden biridir. Pek çok kişi web sunucularının bir nesnenin URI'si ile dosya sistemindeki gerçek konumu arasındaki ilişkiyi kontrol etmenize izin verdiğini bilmiyor. URI alanını mükemmel şekilde organize edilmiş soyut bir alan olarak düşünün. Daha sonra onu gerçekleştirmek için gerçekte kullandığınız gerçekliğin haritasını çıkarın. Daha sonra bunu web sunucusuna bildirin. Doğru yapmak için kendi sunucu snippet'inizi bile yazabilirsiniz.

John artık bu dosyayı tutmuyor, Jane artık tutuyor.

URI'de John'un adı var mıydı? Hayır, dosya az önce onun dizininde miydi? İyi tamam.

Daha önce bunun için CGI betiği kullanıyorduk ama şimdi ikili bir program kullanıyoruz.

Komut dosyalarıyla oluşturulan sayfaların "cgibin" veya "cgi" alanında bulunması gerektiğine dair çılgın bir fikir var. Bu, web sunucunuzu nasıl çalıştırdığınızın mekaniğini ortaya çıkarır. Mekanizmayı değiştirirsiniz (içerik kaydederken bile) ve ah, tüm URI'leriniz değişir.

Örneğin Ulusal Bilim Vakfı'nı (NSF) ele alalım:

NSF Çevrimiçi Belgeleri

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

Belgeleri görüntülemeye başladığınız ilk sayfanın birkaç yıl içinde aynı kalmayacağı açıktır. cgi-bin, oldbrowse и pl - tüm bunlar bunu şimdi nasıl yapacağımıza dair bazı bilgiler veriyor. Sayfayı bir belge aramak için kullanırsanız alacağınız ilk sonuç aynı derecede kötüdür:

Kriptoloji ve Kodlama Teorisi Çalışma Grubu Raporu

http://www.nsf.gov/cgi-bin/getpub?nsf9814

belge dizin sayfası için, html belgesinin kendisi çok daha iyi görünse de:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Burada pubs/1998 başlığı gelecekteki herhangi bir arşiv hizmetine eski 1998 belge sınıflandırma şemasının yürürlükte olduğuna dair iyi bir ipucu verecektir. Her ne kadar belge numaraları 2098'de farklı görünse de, bu URI'nin hala geçerli olacağını ve NSF'ye veya arşivi muhafaza edecek başka herhangi bir kuruluşa müdahale etmeyeceğini hayal ediyorum.

URL'lerin kalıcı olması gerektiğini düşünmüyordum; URN'ler vardı.

Bu muhtemelen URN tartışmasının en kötü yan etkilerinden biridir. Bazı kişiler, daha kalıcı bir ad alanına yönelik araştırma nedeniyle, "URN'lerin tüm bunları düzelteceği" gerekçesiyle bağlantıların sarkması konusunda dikkatsiz olabileceklerini düşünüyor. Eğer siz de bu insanlardan biriyseniz, bırakın sizi hayal kırıklığına uğratayım.

Gördüğüm çoğu URN şeması, bir tarih ve seçtiğiniz bir dizenin veya yalnızca seçtiğiniz bir dizenin takip ettiği bir otorite tanımlayıcısına benziyor. Bu bir HTTP URI'sine çok benzer. Başka bir deyişle, kuruluşunuzun uzun ömürlü URN'ler oluşturabileceğini düşünüyorsanız, bunları HTTP URI'leriniz için kullanarak bunu şimdi kanıtlayın. HTTP'nin kendisinde URI'nizi kararsız hale getiren hiçbir şey yoktur. Yalnızca kuruluşunuz. Belge URN'sini geçerli dosya adıyla eşleştiren bir veritabanı oluşturun ve web sunucusunun, dosyaları gerçekten almak için bunu kullanmasına izin verin.

Eğer bu noktaya geldiyseniz, bir yazılım geliştirecek zamanınız, paranız ve bağlantınız yoksa o zaman şu mazeretinizi belirtebilirsiniz:

İstedik ama doğru araçlara sahip değiliz.

Ama buna sempati duyabilirsiniz. Tamamen katılıyorum. Yapmanız gereken, web sunucusunu kalıcı URI'yi anında ayrıştırmaya ve dosyayı mevcut çılgın dosya sisteminizde depolandığı yere geri döndürmeye zorlamaktır. Tüm URI'leri bir dosyada kontrol olarak saklamak ve veritabanını her zaman güncel tutmak istiyorsunuz. Aynı belgenin farklı sürümleri ve çevirileri arasındaki ilişkiyi korumak ve ayrıca dosyanın kazara oluşan bir hata nedeniyle bozulmamasını sağlamak için bağımsız bir sağlama toplamı kaydı tutmak istiyorsunuz. Ve web sunucuları kutudan bu özelliklerle çıkmıyor. Yeni bir belge oluşturmak istediğinizde editörünüz sizden bir URI belirtmenizi ister.

URI'yi değiştirmeden URI alanındaki sahipliği, belge erişimini, arşiv düzeyi güvenliğini vb. değiştirebilmeniz gerekir.

Her şey çok kötü. Ama durumu düzelteceğiz. W3C'de sürümleri izleyen Jigedit (Jigsaw düzenleme sunucusu) işlevini kullanıyoruz ve belge oluşturma komut dosyalarıyla denemeler yapıyoruz. Araçlar, sunucular ve istemciler geliştiriyorsanız bu soruna dikkat edin!

Bu mazeret aynı zamanda bu sayfa da dahil olmak üzere birçok W3C sayfası için de geçerlidir: dediğimi yapın, yaptığımı değil.

Neden umursayayım?

Sunucunuzdaki URI'yi değiştirdiğinizde, kimin eski URI'ye bağlantılara sahip olacağını asla tam olarak bilemezsiniz. Bunlar normal web sayfalarından bağlantılar olabilir. Sayfanıza yer işareti koyun. URI bir arkadaşa yazılan mektubun kenar boşluklarına karalanmış olabilir.

Birisi bir bağlantıyı takip ettiğinde ve bağlantı bozulduğunda genellikle sunucu sahibine olan güvenini kaybeder. Ayrıca amacına ulaşamamasından dolayı hem duygusal hem de fiziksel olarak hüsrana uğrar.

Pek çok insan her zaman bozuk bağlantılardan şikayet ediyor ve umarım hasar açıktır. Umarım belgenin kaybolduğu sunucunun bakım sağlayıcısının itibarına verdiği zarar da açıktır.

Peki ne yapmalıyım? URI tasarımı

2 yılda, 20 yılda, 200 yılda kullanılabilecek URI'leri tahsis etmek web yöneticisinin sorumluluğundadır. Bu, düşünceli olmayı, organize olmayı ve kararlılığı gerektirir.

URI'ler, içlerindeki herhangi bir bilginin değişmesi durumunda değişir. Bunları nasıl tasarladığınız çok önemlidir. (Ne, URI tasarımı mı? URI'yi tasarlamam gerekiyor mu? Evet, bunu düşünmelisiniz). Tasarım temel olarak URI'de herhangi bir bilginin dışarıda bırakılması anlamına gelir.

Belgenin oluşturulduğu tarih (URI'nin düzenlendiği tarih) hiçbir zaman değişmeyecek bir şeydir. Yeni sistemi kullanan sorguları eski sistemi kullanan sorgulardan ayırmak açısından oldukça kullanışlıdır. Burası bir URI ile başlamak için iyi bir yerdir. Bir belgenin tarihi varsa, belge gelecekte geçerli olacak olsa bile bu iyi bir başlangıçtır.

Bunun tek istisnası, örneğin kuruluşun tamamı veya büyük bir kısmı için kasıtlı olarak "en son" sürümü kullanan sayfalardır.

http://www.pathfinder.com/money/moneydaily/latest/

Bu Money dergisindeki en son Money Daily köşe yazısıdır. Bu URI'de tarihe gerek olmamasının ana nedeni, günlüğün geçerliliğini yitirecek URI'yi saklamanın bir nedeni olmamasıdır. Money ortadan kalkınca Money Daily kavramı da ortadan kalkacak. İçeriğe bağlantı vermek istiyorsanız, arşivlerde ayrı olarak bağlantı vermelisiniz:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(İyi görünüyor. Pathfinder.com'un ömrü boyunca "para"nın aynı anlama geleceğini varsayar. Yinelenen bir "98" ve gereksiz bir ".html" vardır, ancak bunun dışında güçlü bir URI gibi görünür.

Neyi bir kenara bırakalım

Tüm! Oluşturulma tarihi dışında, URI'ye herhangi bir bilgi koymak öyle ya da böyle sorun çıkarmaktır.

• Yazarın ismi. Yeni sürümler kullanıma sunuldukça yazarlık değişebilir. İnsanlar kuruluşlardan ayrılır ve işleri başkalarına aktarır.
• Konu. Bu çok zor. İlk başta her zaman iyi görünür, ancak şaşırtıcı derecede hızlı bir şekilde değişir. Aşağıda bunun hakkında daha fazla konuşacağım.
• Durum. "Eski", "taslak" vb. dizinlerin yanı sıra "en yeni" ve "harika" dizinler tüm dosya sistemlerinde görünür. Belgelerin durumu değişir - aksi takdirde taslak oluşturmanın bir anlamı olmaz. Bir belgenin en son sürümü, durumundan bağımsız olarak kalıcı bir tanımlayıcıya ihtiyaç duyar. Durumu adın dışında tutun.
• Giriş. W3C olarak siteyi çalışanlar, üyeler ve halk için bölümlere ayırdık. Kulağa hoş geliyor ama tabii ki belgeler personelin takım fikirleriyle başlar, üyelerle tartışılır ve daha sonra kamuoyunun bilgisine sunulur. Bir belge daha geniş bir tartışma için her açıldığında, ona olan tüm eski bağlantıların kopması gerçekten çok yazık olur! Şimdi basit bir tarih koduna geçiyoruz.
• Dosya uzantısı. Çok yaygın bir olay. Gelecekte "cgi", hatta ".html" bile değişecek. Bu sayfa için HTML'yi 20 yıldır kullanmıyor olabilirsiniz, ancak bugün bu sayfaya verilen bağlantılar hala çalışıyor olmalıdır. W3C sitesindeki kanonik bağlantılar uzantıyı kullanmaz (nasıl yapıldığını).
• Yazılım mekanizmaları. URI'de "cgi", "exec" ve "hangi yazılımı kullandığımıza bakın" diye bağıran diğer terimleri arayın. Tüm hayatını Perl CGI senaryoları yazarak geçirmek isteyen var mı? HAYIR? Ardından .pl uzantısını kaldırın. Bunun nasıl yapılacağı hakkında sunucu kılavuzunu okuyun.
• Disk adı. Hadi! Ama şunu gördüm.

Yani sitemizden en iyi örnek basitçe

http://www.w3.org/1998/12/01/chairs

...W3C Başkanları toplantısının tutanaklarını rapor edin.

Konular ve konuya göre sınıflandırma

Kaçınılması en zor şeylerden biri olduğu için bu tehlikeyi daha ayrıntılı olarak ele alacağım. Genellikle, belgelerinizi yaptıkları işe göre kategorilere ayırdığınızda konular URI'lerde sona erer. Ancak bu dağılım zamanla değişecektir. Bölgelerin isimleri değişecek. W3C'de, bölümün gerçek içeriğini yansıtacak şekilde MarkUP'ı İşaretleme ve ardından HTML olarak değiştirmek istedik. Ayrıca genellikle düz bir ad alanı vardır. 100 yıl sonra hiçbir şeyi yeniden kullanmak istemeyeceğinizden emin misiniz? Kısa hayatımızda zaten örneğin "Geçmiş" ve "Stil Sayfalarını" yeniden kullanmak istedik.

Bu, bir web sitesini organize etmenin cazip bir yoludur ve Web'in tamamı da dahil olmak üzere her şeyi organize etmenin gerçekten cazip bir yoludur. Bu orta vadede harika bir çözüm ama uzun vadede ciddi eksiklikleri var.

Bunun bir kısmı anlam felsefesinde yatmaktadır. Bir dildeki her terim, kümelenme için potansiyel bir hedeftir ve her kişi bunun ne anlama geldiğine dair farklı bir fikre sahip olabilir. Varlıklar arasındaki ilişkiler bir ağaçtan çok bir ağa benzediğinden, ağ ile aynı fikirde olanlar bile ağacın farklı bir temsilini seçebilirler. Bunlar, genel bir çözüm olarak hiyerarşik sınıflandırmanın tehlikeleri hakkındaki (sıklıkla tekrarlanan) genel gözlemlerimdir.

Aslında bir URI'de konu adı kullandığınızda kendinizi bir tür sınıflandırmaya adamış olursunuz. Belki gelecekte farklı bir seçeneği tercih edeceksiniz. URI daha sonra ihlale açık olacaktır.

Bir konu alanını bir URI'nin parçası olarak kullanmanın nedeni, URI alanının alt bölümlerine ilişkin sorumluluğun genellikle devredilmesi ve daha sonra bu alt alandan sorumlu olan kuruluş organının (bölüm, grup veya her neyse) adına ihtiyaç duymanızdır. Bu, bir organizasyon yapısına bağlanan bir URI'dir. Genellikle yalnızca diğer (soldaki) URI'nin bir tarihle korunması durumunda güvenlidir: 1998/pics, sunucunuz için "1998'de şimdi pics dediğimiz şeyle yaptığımız şey" yerine "1998'de resimlerle ne demek istediğimiz" anlamına gelebilir.

Alan adını unutmayın

Bunun yalnızca URI'deki yol için değil aynı zamanda sunucu adı için de geçerli olduğunu unutmayın. Farklı şeyler için ayrı sunucularınız varsa, çok sayıda bağlantıyı yok etmeden bu bölümü değiştirmenin imkansız olacağını unutmayın. Bazı klasik "bugün kullandığımız yazılımlara bakın" hataları "cgi.pathfinder.com", "secure", "lists.w3.org" alan adlarıdır. Sunucu yönetimini kolaylaştırmak için tasarlanmıştır. Bir alan adının şirketinizdeki bir bölümü, bir belge durumunu, bir erişim düzeyini veya bir güvenlik düzeyini temsil edip etmediğine bakılmaksızın, birden fazla belge türü için birden fazla alan adı kullanmadan önce çok ama çok dikkatli olun. Yeniden yönlendirme ve proxy kullanarak birden fazla web sunucusunu tek bir görünür web sunucusu içinde gizleyebilirsiniz.

Ayrıca alan adınızı da düşünün. Ürün gruplarını değiştirip sabun yapmayı bıraktıktan sonra sabun.com olarak anılmak istemezsiniz (şu anda sabun.com'un sahibi kim olursa olsun özür dilerim).

Sonuç

Bir URI'yi 2, 20, 200, hatta 2000 yıl boyunca korumak elbette göründüğü kadar kolay değildir. Ancak internetin her yerinde web yöneticileri bu görevi gelecekte kendileri için gerçekten zorlaştıracak kararlar alıyorlar. Çoğu zaman bunun nedeni, işi yalnızca o anda en iyi siteyi sunmak olan araçları kullanmalarıdır - ve her şey değiştiğinde bağlantılara ne olacağını hiç kimse değerlendirmemiştir. Ancak burada önemli olan pek çok şeyin değişebileceği ve URI'lerinizin aynı kalabileceği ve kalması gerektiğidir. Bu ancak onları nasıl yarattığınızı düşündüğünüzde mümkündür.

. Peki bakınız:

• Jakob Nielsen'in aynı konuyla ilgili tiradı

İlaveler

Dosya uzantıları nasıl kaldırılır...

...mevcut dosya tabanlı web sunucusundaki bir URI'den mi?

Örneğin Apache kullanıyorsanız, onu içerik üzerinde anlaşmaya varacak şekilde yapılandırabilirsiniz. Dosya uzantısını (ör. .png) bir dosyaya (ör. köpeğim.png), ancak bir web kaynağına bu olmadan da bağlanabilirsiniz. Apache daha sonra dizini bu addaki ve herhangi bir uzantıdaki tüm dosyalar için kontrol eder ve kümeden en iyisini seçebilir (örneğin, GIF ve PNG). Ayrıca farklı türdeki dosyaları farklı dizinlere koymanıza gerek yoktur; aslında bunu yaparsanız içerik eşleştirme işe yaramaz.

• İçerik üzerinde anlaşmak için sunucunuzu ayarlayın
• Her zaman uzantısız URI'lere bağlantı verin

Uzantıları olan bağlantılar çalışmaya devam edecek ancak sunucunuzun şu anda ve gelecekte mevcut olan en iyi formatı seçmesini engelleyecektir.

(Aslında, mydog, mydog.png и mydog.gif — geçerli web kaynakları, mydog evrensel bir içerik türü kaynağıdır ve mydog.png и mydog.gif — belirli bir içerik türünün kaynakları).

Elbette, kendi web sunucunuzu yazıyorsanız, kalıcı tanımlayıcıları mevcut biçimlerine bağlamak için bir veritabanı kullanmak iyi bir fikirdir, ancak sınırsız veritabanı büyümesine dikkat edin.

Utanç Kurulu - Hikaye 1: Kanal 7

1999 yılında kar nedeniyle okulların kapandığını sayfadan takip ettim http://www.whdh.com/stormforce/closings.shtml. Bilgilerin TV ekranının alt kısmında görünmesini beklemeyin! Ana sayfamdan ona bağlantı verdim. 2000 yılının ilk büyük kar fırtınası geliyor ve sayfayı kontrol ediyorum. Orada yazıyor:,

- itibariyle.
Şu anda hiçbir şey kapalı değil. Hava durumu uyarıları durumunda lütfen geri dönün.

Bu kadar güçlü bir fırtına olamaz. Tarihin eksik olması komik. Ancak sitenin ana sayfasına giderseniz, sayfaya yönlendiren büyük bir “Kapalı Okullar” düğmesi olacaktır. http://www.whdh.com/stormforce/ Kapatılan okulların uzun bir listesiyle birlikte.

Belki listeyi almak için sistemi değiştirdiler - ancak URI'yi değiştirmelerine gerek yoktu.

Utanç Kurulu - Hikaye 2: Microsoft Netmeeting

İnternete bağımlılığın artmasıyla birlikte, üreticinin web sitesine bağlantıların uygulamalara yerleştirilebileceği akıllıca bir fikir ortaya çıktı. Bu çok kullanıldı ve suistimal edildi, ancak URL'yi değiştiremezsiniz. Daha geçen gün Web/Ücretsiz şeyler menüsündeki Yardım/Microsoft'ta Microsoft Netmeeting 2/something istemcisinden bir bağlantı denedim ve bir 404 hatası aldım - sunucudan yanıt bulunamadı. Belki de çoktan çözmüşlerdir...

© 1998 Tim BL

Tarihsel not: Bu yazının yazıldığı 20. yüzyılın sonlarında "havalı", özellikle gençler arasında modaya uygunluğu, kaliteyi veya uygunluğu belirten bir onay sıfatıydı. Aceleyle, URI yolu genellikle kullanışlılık veya dayanıklılıktan ziyade "soğukkanlılık" nedeniyle seçildi. Bu gönderi, havalılık arayışının ardındaki enerjiyi yeniden yönlendirme girişimidir.

Kaynak: habr.com