Pengarang: Sir Tim Berners-Lee, pencipta URI, URL, HTTP, HTML dan World Wide Web, dan ketua semasa W3C. Artikel yang ditulis pada tahun 1998

Apakah URI yang dianggap "sejuk"?
Satu yang tidak berubah.
Bagaimanakah URI diubah?
URI tidak berubah: orang mengubahnya.

Secara teorinya, tidak ada sebab untuk orang menukar URI (atau menghentikan dokumen sokongan), tetapi dalam praktiknya terdapat berjuta-juta daripadanya.

Secara teorinya, pemilik nominal ruang nama domain sebenarnya memiliki ruang nama domain dan oleh itu semua URI di dalamnya. Selain insolvensi, tiada apa yang menghalang pemilik nama domain daripada mengekalkan nama tersebut. Dan secara teorinya, ruang URI di bawah nama domain anda berada di bawah kawalan anda sepenuhnya, jadi anda boleh menjadikannya stabil seperti yang anda suka. Hampir satu-satunya sebab yang baik untuk dokumen hilang dari internet ialah syarikat yang memiliki nama domain itu telah gulung tikar atau tidak mampu lagi untuk memastikan pelayan berjalan. Kemudian mengapa terdapat begitu banyak pautan yang hilang di dunia? Sebahagian daripada ini hanyalah kekurangan pemikiran awal. Berikut ialah beberapa sebab yang mungkin anda dengar:

Kami baru sahaja menyusun semula tapak untuk menjadikannya lebih baik.

Adakah anda benar-benar fikir URI lama tidak boleh berfungsi lagi? Jika ya, maka anda memilihnya dengan sangat buruk. Pertimbangkan untuk menyimpan yang baharu untuk reka bentuk semula seterusnya.

Kami mempunyai begitu banyak barangan sehingga kami tidak dapat menjejaki perkara yang lapuk, perkara yang sulit dan perkara yang masih berkaitan, jadi kami fikir lebih baik untuk mematikannya sahaja.

Saya hanya mampu bersimpati. W3C melalui tempoh di mana kami perlu menyaring bahan arkib dengan teliti untuk kerahsiaan sebelum mendedahkannya kepada umum. Keputusan harus difikirkan lebih awal - pastikan bahawa dengan setiap dokumen anda merekodkan pembaca yang boleh diterima, tarikh penciptaan dan, idealnya, tarikh tamat tempoh. Simpan metadata ini.

Nah, kami mendapati bahawa kami perlu mengalihkan fail...

Ini adalah salah satu alasan yang paling menyedihkan. Ramai orang tidak tahu bahawa pelayan web membenarkan anda mengawal hubungan antara URI objek dan lokasi sebenar dalam sistem fail. Fikirkan ruang URI sebagai ruang abstrak, tersusun dengan sempurna. Kemudian buat pemetaan kepada apa sahaja realiti yang sebenarnya anda gunakan untuk merealisasikannya. Kemudian laporkan perkara ini kepada pelayan web. Anda juga boleh menulis coretan pelayan anda sendiri untuk membetulkannya.

John tidak lagi mengekalkan fail ini, Jane kini melakukannya.

Adakah nama John dalam URI? Tidak, adakah fail itu hanya dalam direktorinya? Baiklah.

Sebelum ini kami menggunakan skrip CGI untuk ini, tetapi kini kami menggunakan program binari.

Terdapat idea gila bahawa halaman yang dibuat oleh skrip harus terletak di kawasan "cgibin" atau "cgi". Ini mendedahkan mekanik cara anda menjalankan pelayan web anda. Anda menukar mekanisme (walaupun semasa menyimpan kandungan), dan oops - semua URI anda berubah.

Ambil Yayasan Sains Kebangsaan (NSF) sebagai contoh:

Dokumen Dalam Talian NSF

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

Halaman pertama untuk mula melihat dokumen jelas tidak akan kekal sama dalam beberapa tahun. cgi-bin, oldbrowse и pl - semua ini memberikan sedikit maklumat tentang bagaimana-kita-lakukan-sekarang. Jika anda menggunakan halaman untuk mencari dokumen, hasil pertama yang anda dapat adalah sama buruk:

Laporan Kumpulan Kerja mengenai Kriptologi dan Teori Pengekodan

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

untuk halaman indeks dokumen, walaupun dokumen html itu sendiri kelihatan lebih baik:

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

Di sini pengepala pub/1998 akan memberikan mana-mana perkhidmatan arkib masa hadapan petunjuk yang baik bahawa skim pengelasan dokumen 1998 lama berkuat kuasa. Walaupun nombor dokumen mungkin kelihatan berbeza pada tahun 2098, saya akan membayangkan bahawa URI ini masih sah dan tidak akan mengganggu NSF atau mana-mana organisasi lain yang akan mengekalkan arkib.

Saya tidak fikir URL mesti berterusan - terdapat URN.

Ini mungkin salah satu kesan sampingan terburuk perbahasan URN. Sesetengah orang berpendapat bahawa disebabkan penyelidikan ke dalam ruang nama yang lebih kekal, mereka mungkin cuai tentang pautan berjuntai kerana "URN akan membetulkan semua itu." Jika anda adalah salah seorang daripada orang ini, maka biarkan saya mengecewakan anda.

Kebanyakan skim URN yang saya lihat kelihatan seperti pengecam kuasa diikuti sama ada tarikh dan rentetan yang anda pilih, atau hanya rentetan yang anda pilih. Ini sangat serupa dengan URI HTTP. Dalam erti kata lain, jika anda fikir organisasi anda akan mampu mencipta URN yang tahan lama, maka buktikan sekarang dengan menggunakannya untuk URI HTTP anda. Tiada apa-apa dalam HTTP itu sendiri yang menjadikan URI anda tidak stabil. Hanya organisasi anda. Cipta pangkalan data yang memetakan URN dokumen kepada nama fail semasa dan biarkan pelayan web menggunakannya untuk benar-benar mendapatkan semula fail.

Jika anda telah mencapai tahap ini, jika anda tidak mempunyai masa, wang dan sambungan untuk membangunkan beberapa perisian, maka anda boleh menyatakan alasan berikut:

Kami mahu, tetapi kami tidak mempunyai alat yang betul.

Tetapi anda boleh bersimpati dengan ini. Saya bersetuju sepenuhnya. Apa yang anda perlu lakukan ialah memaksa pelayan web untuk menghuraikan URI berterusan dengan serta-merta dan mengembalikan fail di mana sahaja ia disimpan pada sistem fail gila semasa anda. Anda ingin menyimpan semua URI dalam fail sebagai semakan dan memastikan pangkalan data dikemas kini pada setiap masa. Anda ingin mengekalkan hubungan antara versi berbeza dan terjemahan dokumen yang sama, dan juga mengekalkan rekod jumlah semak bebas untuk memastikan fail itu tidak rosak oleh ralat yang tidak disengajakan. Dan pelayan web hanya tidak keluar dari kotak dengan ciri-ciri ini. Apabila anda ingin mencipta dokumen baharu, editor anda meminta anda untuk menentukan URI.

Anda perlu boleh menukar pemilikan, akses dokumen, keselamatan peringkat arkib, dll. dalam ruang URI tanpa mengubah URI.

Semuanya terlalu teruk. Tetapi kami akan membetulkan keadaan. Di W3C, kami menggunakan fungsi Jigedit (pelayan pengeditan Jigsaw) yang menjejaki versi dan kami bereksperimen dengan skrip penjanaan dokumen. Jika anda membangunkan alatan, pelayan dan pelanggan, beri perhatian kepada isu ini!

Alasan ini juga terpakai pada banyak halaman W3C, termasuk halaman ini: jadi lakukan seperti yang saya katakan, bukan seperti yang saya lakukan.

Mengapa saya perlu mengambil berat?

Apabila anda menukar URI pada pelayan anda, anda tidak boleh memberitahu sepenuhnya siapa yang akan mempunyai pautan ke URI lama. Ini boleh menjadi pautan dari halaman web biasa. Tandai halaman anda. URI mungkin telah dicoretkan di pinggir surat kepada rakan.

Apabila seseorang mengikuti pautan dan ia rosak, mereka biasanya kehilangan kepercayaan kepada pemilik pelayan. Dia juga kecewa, baik dari segi emosi dan fizikal, kerana tidak dapat mencapai matlamatnya.

Ramai orang mengadu tentang pautan yang rosak sepanjang masa, dan saya harap kerosakannya jelas. Saya berharap bahawa kerosakan reputasi kepada penyelenggara pelayan di mana dokumen itu hilang juga jelas.

Jadi apa yang perlu saya lakukan? reka bentuk URI

Adalah menjadi tanggungjawab juruweb untuk memperuntukkan URI yang boleh digunakan dalam 2 tahun, dalam 20 tahun, dalam 200 tahun. Ini memerlukan pemikiran, organisasi dan keazaman.

URI berubah jika sebarang maklumat di dalamnya berubah. Cara anda mereka bentuk adalah sangat penting. (Apakah, reka bentuk URI? Adakah saya perlu mereka bentuk URI? Ya, anda harus memikirkannya). Reka bentuk pada asasnya bermaksud meninggalkan sebarang maklumat dalam URI.

Tarikh dokumen dibuat - tarikh URI dikeluarkan - adalah sesuatu yang tidak akan berubah. Ia amat berguna untuk mengasingkan pertanyaan yang menggunakan sistem baharu daripada pertanyaan yang menggunakan sistem lama. Ini adalah tempat yang baik untuk bermula dengan URI. Jika dokumen bertarikh, walaupun dokumen itu akan relevan pada masa hadapan, maka ini adalah permulaan yang baik.

Satu-satunya pengecualian ialah halaman yang sengaja merupakan versi "terkini", contohnya untuk keseluruhan organisasi atau sebahagian besar daripadanya.

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

Ini adalah ruangan Money Daily terbaru dalam majalah Money. Sebab utama tidak perlu tarikh dalam URI ini ialah tiada sebab untuk menyimpan URI yang akan hidup lebih lama daripada log. Konsep Money Daily akan hilang apabila Wang hilang. Jika anda ingin memaut ke kandungan, anda harus memautkannya secara berasingan dalam arkib:

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

(Nampak bagus. Andaikan bahawa "wang" akan bermakna perkara yang sama sepanjang hayat pathfinder.com. Terdapat pendua "98" dan ".html" yang tidak perlu, tetapi sebaliknya kelihatan seperti URI yang kuat.

Apa yang perlu diketepikan

Semua! Selain daripada tarikh penciptaan, meletakkan sebarang maklumat dalam URI akan menimbulkan masalah dalam satu atau lain cara.

nama pengarang. Kepengarangan boleh berubah apabila versi baharu tersedia. Orang ramai meninggalkan organisasi dan menyampaikan sesuatu kepada orang lain.
Subjek. Ianya sangat susah. Ia sentiasa kelihatan baik pada mulanya, tetapi berubah dengan cepat. Saya akan bercakap lebih lanjut mengenai perkara ini di bawah.
Status. Direktori seperti "lama", "draf" dan sebagainya, apatah lagi "terkini" dan "sejuk", muncul dalam semua sistem fail. Dokumen menukar status - jika tidak, tiada gunanya membuat draf. Versi terkini dokumen memerlukan pengecam yang berterusan, tanpa mengira statusnya. Jauhkan status daripada nama.
Akses. Di W3C, kami telah membahagikan tapak kepada bahagian untuk pekerja, ahli dan orang ramai. Bunyi ini bagus, tetapi sudah tentu, dokumen bermula sebagai idea pasukan daripada kakitangan, dibincangkan dengan ahli, dan kemudian menjadi pengetahuan umum. Sungguh memalukan jika setiap kali dokumen dibuka untuk perbincangan yang lebih luas, semua pautan lama kepadanya terputus! Sekarang kita beralih kepada kod tarikh mudah.
Sambungan fail. Fenomena yang sangat biasa. "cgi", malah ".html" akan berubah pada masa hadapan. Anda mungkin tidak menggunakan HTML untuk halaman ini dalam tempoh 20 tahun, tetapi pautan hari ini ke halaman ini masih boleh digunakan. Pautan kanonik pada tapak W3C tidak menggunakan sambungan (bagaimana ia dilakukan).
Mekanisme perisian. Dalam URI, cari "cgi", "exec" dan istilah lain yang menjerit "lihat perisian yang kami gunakan." Adakah sesiapa mahu menghabiskan seluruh hidup mereka menulis skrip Perl CGI? Tidak? Kemudian alih keluar sambungan .pl. Baca manual pelayan tentang cara melakukan ini.
Nama cakera. Ayuh! Tetapi saya telah melihat ini.

Jadi contoh terbaik dari laman web kami adalah ringkas

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

... melaporkan minit mesyuarat Pengerusi W3C.

Topik dan klasifikasi mengikut topik

Saya akan pergi ke lebih terperinci tentang bahaya ini, kerana ia adalah salah satu perkara yang paling sukar untuk dielakkan. Biasanya, topik berakhir dalam URI apabila anda mengkategorikan dokumen anda mengikut kerja yang mereka lakukan. Tetapi pecahan ini akan berubah dari semasa ke semasa. Nama kawasan akan bertukar. Di W3C kami ingin menukar MarkUP kepada Markup dan kemudian kepada HTML untuk menggambarkan kandungan sebenar bahagian tersebut. Di samping itu, selalunya terdapat ruang nama rata. Dalam 100 tahun, adakah anda pasti anda tidak mahu menggunakan semula apa-apa? Dalam kehidupan singkat kita, kita sudah mahu menggunakan semula "Sejarah" dan "Helaian Gaya" sebagai contoh.

Ia merupakan cara yang menarik untuk mengatur tapak web—dan cara yang benar-benar menggoda untuk mengatur apa sahaja, termasuk keseluruhan Web. Ini adalah penyelesaian jangka sederhana yang hebat tetapi mempunyai kelemahan yang serius dalam jangka panjang.

Sebahagian daripada sebabnya terletak pada falsafah makna. Setiap istilah dalam bahasa adalah sasaran yang berpotensi untuk pengelompokan, dan setiap orang mungkin mempunyai idea yang berbeza tentang maksudnya. Memandangkan perhubungan antara entiti lebih seperti web daripada pokok, malah mereka yang bersetuju dengan web boleh memilih perwakilan pokok yang berbeza. Ini adalah pemerhatian umum saya (sering diulang) tentang bahaya klasifikasi hierarki sebagai penyelesaian umum.

Malah, apabila anda menggunakan nama topik dalam URI, anda sedang komited kepada beberapa jenis klasifikasi. Mungkin pada masa hadapan anda akan memilih pilihan yang berbeza. URI kemudiannya akan terdedah kepada pelanggaran.

Sebab untuk menggunakan kawasan subjek sebagai sebahagian daripada URI ialah tanggungjawab untuk subseksyen ruang URI biasanya diwakilkan, dan kemudian anda memerlukan nama badan organisasi - jabatan, kumpulan atau apa sahaja - yang bertanggungjawab untuk subruang itu. Ini ialah URI yang mengikat kepada struktur organisasi. Ia biasanya hanya selamat jika URI yang lebih jauh (kiri) dilindungi oleh tarikh: 1998/pics mungkin bermakna kepada pelayan anda "apa yang kami maksudkan pada tahun 1998 dengan gambar" dan bukannya "apa yang kami lakukan pada tahun 1998 dengan apa yang kini kami panggil pics."

Jangan lupa nama domain

Ingat bahawa ini digunakan bukan sahaja pada laluan dalam URI, tetapi juga pada nama pelayan. Jika anda mempunyai pelayan yang berasingan untuk perkara yang berbeza, ingat bahawa bahagian ini mustahil untuk diubah tanpa memusnahkan banyak, banyak pautan. Beberapa kesilapan klasik "lihat perisian yang kami gunakan hari ini" ialah nama domain "cgi.pathfinder.com", "secure", "lists.w3.org". Mereka direka untuk memudahkan pentadbiran pelayan. Tidak kira sama ada domain mewakili bahagian dalam syarikat anda, status dokumen, tahap akses atau tahap keselamatan, berhati-hati sebelum menggunakan lebih daripada satu nama domain untuk berbilang jenis dokumen. Ingat bahawa anda boleh menyembunyikan berbilang pelayan web di dalam satu pelayan web yang boleh dilihat menggunakan pengalihan dan proksi.

Oh, dan juga fikirkan tentang nama domain anda. Anda tidak mahu dirujuk sebagai soap.com selepas anda menukar barisan produk dan berhenti membuat sabun (Maaf kepada sesiapa yang memiliki soap.com pada masa ini).

Kesimpulan

Memelihara URI selama 2, 20, 200, atau bahkan 2000 tahun jelas tidak semudah yang disangka. Walau bagaimanapun, di seluruh Internet, juruweb membuat keputusan yang menjadikan tugas ini sangat sukar untuk diri mereka sendiri pada masa hadapan. Selalunya ini adalah kerana mereka menggunakan alat yang tugasnya untuk membentangkan tapak terbaik hanya pada masa ini - dan tiada siapa yang menilai apa yang akan berlaku pada pautan apabila semuanya berubah. Walau bagaimanapun, perkara di sini ialah banyak, banyak perkara boleh berubah dan URI anda boleh dan harus kekal sama. Ini hanya boleh dilakukan apabila anda memikirkan cara anda menciptanya.

Lihat juga:

Omelan Jakob Nielsen mengenai topik yang sama

Tambahan

Bagaimana untuk mengalih keluar sambungan fail...

... daripada URI dalam pelayan web berasaskan fail semasa?

Jika anda menggunakan Apache, sebagai contoh, anda boleh mengkonfigurasinya untuk merundingkan kandungan. Simpan sambungan fail (cth. .png) ke fail (cth. mydog.png), tetapi anda boleh memaut ke sumber web tanpanya. Apache kemudian menyemak direktori untuk semua fail dengan nama itu dan sebarang sambungan, dan boleh memilih yang terbaik daripada set (contohnya, GIF dan PNG). Dan tidak perlu meletakkan jenis fail yang berbeza dalam direktori yang berbeza, sebenarnya pemadanan kandungan tidak akan berfungsi jika anda berbuat demikian.

Sediakan pelayan anda untuk merundingkan kandungan
Sentiasa paut ke URI tanpa sambungan

Pautan dengan sambungan masih akan berfungsi, tetapi akan menghalang pelayan anda daripada memilih format terbaik yang tersedia pada masa ini dan pada masa hadapan.

(Malah, mydog, mydog.png и mydog.gif — sumber web yang sah, mydog ialah sumber jenis kandungan universal, dan mydog.png и mydog.gif — sumber jenis kandungan tertentu).

Sudah tentu, jika anda menulis pelayan web anda sendiri, adalah idea yang baik untuk menggunakan pangkalan data untuk mengikat pengecam berterusan kepada bentuk semasa mereka, walaupun berhati-hati dengan pertumbuhan pangkalan data tanpa had.

Lembaga Aib - Cerita 1: Saluran 7

Pada tahun 1999, saya menjejaki penutupan sekolah kerana salji di halaman http://www.whdh.com/stormforce/closings.shtml. Jangan tunggu maklumat itu muncul di bahagian bawah skrin TV! Saya memautkannya dari halaman utama saya. Ribut salji besar pertama pada tahun 2000 tiba dan saya menyemak halaman. Di situ tertulis:,

- Sejak.
Tiada apa-apa yang ditutup pada masa ini. Sila kembali sekiranya terdapat amaran cuaca.

Ia tidak boleh menjadi ribut yang begitu kuat. Kelakarnya tarikh itu tiada. Tetapi jika anda pergi ke halaman utama tapak, akan terdapat butang besar "Sekolah Tertutup", yang menuju ke halaman http://www.whdh.com/stormforce/ dengan senarai panjang sekolah yang ditutup.

Mungkin mereka menukar sistem untuk mendapatkan senarai - tetapi mereka tidak perlu menukar URI.

Lembaga Malu - Kisah 2: Microsoft Netmeeting

Dengan pergantungan yang semakin meningkat pada Internet, idea bijak datang bahawa pautan ke tapak web pengeluar boleh dibenamkan dalam aplikasi. Ini telah banyak digunakan dan disalahgunakan, tetapi anda tidak boleh menukar URL. Pada hari lain saya mencuba pautan daripada klien Microsoft Netmeeting 2/something dalam Help/Microsoft on the Web/Free stuff menu dan menerima ralat 404 - tiada respons daripada pelayan ditemui. Mungkin ia sudah diperbaiki...

Nota sejarah: Pada penghujung abad ke-20, apabila ini ditulis, "cool" ialah julukan kelulusan, terutamanya dalam kalangan orang muda, yang menunjukkan kebolehfesyen, kualiti atau kesesuaian. Dalam keadaan tergesa-gesa, laluan URI sering dipilih untuk "kesejukan" berbanding kegunaan atau ketahanan. Siaran ini adalah percubaan untuk mengubah hala tenaga di sebalik pencarian untuk cool.

Sumber: www.habr.com

URI yang keren tidak berubah