Penulis: Sir Tim Berners-Lee, penemu URI, URL, HTTP, HTML, dan World Wide Web, dan kepala W3C saat ini. Artikel ditulis pada tahun 1998

URI apa yang dianggap "keren"?
Yang tidak berubah.
Bagaimana URI diubah?
URI tidak berubah: orang mengubahnya.

Secara teori, tidak ada alasan bagi orang untuk mengubah URI (atau menghentikan dokumen pendukung), namun dalam praktiknya ada jutaan alasan.

Secara teori, pemilik nominal namespace domain sebenarnya memiliki namespace domain dan semua URI di dalamnya. Selain kebangkrutan, tidak ada yang menghalangi pemilik nama domain untuk mempertahankan nama tersebut. Dan secara teori, ruang URI di bawah nama domain Anda sepenuhnya berada di bawah kendali Anda, sehingga Anda dapat membuatnya stabil sesuai keinginan Anda. Satu-satunya alasan bagus mengapa sebuah dokumen menghilang dari internet adalah karena perusahaan yang memiliki nama domain tersebut telah gulung tikar atau tidak mampu lagi menjaga servernya tetap berjalan. Lalu kenapa banyak sekali mata rantai yang hilang di dunia? Beberapa di antaranya hanyalah kurangnya pemikiran ke depan. Berikut beberapa alasan yang mungkin Anda dengar:

Kami baru saja mengatur ulang situs untuk menjadikannya lebih baik.

Apakah menurut Anda URI lama tidak dapat berfungsi lagi? Jika demikian, berarti Anda memilihnya dengan sangat buruk. Pertimbangkan untuk menyimpan yang baru untuk desain ulang berikutnya.

Kita punya begitu banyak hal sehingga kita tidak bisa melacak apa yang sudah kadaluarsa, apa yang rahasia, dan apa yang masih relevan, jadi kami pikir yang terbaik adalah mematikannya saja.

Saya hanya bisa bersimpati. W3C melewati masa di mana kami harus hati-hati menyaring materi arsip untuk menjaga kerahasiaan sebelum mempublikasikannya. Keputusan harus dipikirkan terlebih dahulu - pastikan bahwa pada setiap dokumen Anda mencatat jumlah pembaca yang dapat diterima, tanggal pembuatan dan, idealnya, tanggal kedaluwarsa. Simpan metadata ini.

Ya, kami menemukan bahwa kami perlu memindahkan file...

Ini adalah salah satu alasan yang paling menyedihkan. Banyak orang tidak mengetahui bahwa server web memungkinkan Anda mengontrol hubungan antara URI objek dan lokasi sebenarnya di sistem file. Bayangkan ruang URI sebagai ruang abstrak, yang tertata sempurna. Kemudian buatlah pemetaan terhadap realitas apa pun yang sebenarnya Anda gunakan untuk mewujudkannya. Kemudian laporkan ini ke server web. Anda bahkan dapat menulis cuplikan server Anda sendiri untuk melakukannya dengan benar.

John tidak lagi menyimpan file ini, Jane sekarang yang menyimpannya.

Apakah nama John ada di URI? Tidak, apakah file itu ada di direktorinya? Baiklah.

Sebelumnya kami menggunakan skrip CGI untuk ini, tapi sekarang kami menggunakan program biner.

Ada ide gila bahwa halaman yang dibuat dengan skrip harus ditempatkan di area "cgibin" atau "cgi". Ini memperlihatkan mekanisme cara Anda menjalankan server web Anda. Anda mengubah mekanismenya (bahkan saat menyimpan konten), dan ups - semua URI Anda berubah.

Ambil contoh National Science Foundation (NSF):

Dokumen Daring NSF

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

Halaman pertama untuk mulai melihat dokumen jelas tidak akan tetap sama dalam beberapa tahun. cgi-bin, oldbrowse и pl - semua ini memberikan sedikit informasi tentang bagaimana kita melakukannya sekarang. Jika Anda menggunakan halaman tersebut untuk mencari dokumen, hasil pertama yang Anda dapatkan sama buruknya:

Laporan Kelompok Kerja Kriptologi dan Teori Pengkodean

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

untuk halaman indeks dokumen, meskipun dokumen html itu sendiri terlihat jauh lebih baik:

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

Di sini header pubs/1998 akan memberikan petunjuk yang baik kepada layanan kearsipan di masa depan bahwa skema klasifikasi dokumen tahun 1998 yang lama masih berlaku. Meskipun nomor dokumen mungkin terlihat berbeda pada tahun 2098, saya membayangkan URI ini akan tetap valid dan tidak akan mengganggu NSF atau organisasi lain yang memelihara arsip.

Saya tidak berpikir URL harus tetap ada - yang ada adalah URN.

Ini mungkin salah satu efek samping terburuk dari perdebatan URN. Beberapa orang berpikir bahwa karena penelitian terhadap namespace yang lebih permanen, mereka mungkin ceroboh terhadap tautan yang menjuntai karena "URN akan memperbaiki semua itu." Jika Anda salah satu dari orang-orang ini, izinkan saya mengecewakan Anda.

Kebanyakan skema URN yang saya lihat terlihat seperti pengidentifikasi otoritas yang diikuti dengan tanggal dan string yang Anda pilih, atau hanya string yang Anda pilih. Ini sangat mirip dengan URI HTTP. Dengan kata lain, jika Anda berpikir organisasi Anda akan mampu membuat URN yang berumur panjang, buktikan sekarang dengan menggunakannya untuk URI HTTP Anda. Tidak ada apa pun dalam HTTP itu sendiri yang membuat URI Anda tidak stabil. Hanya organisasi Anda. Buat database yang memetakan URN dokumen ke nama file saat ini, dan biarkan server web menggunakannya untuk mengambil file.

Jika Anda sudah sampai pada titik ini, jika Anda tidak mempunyai waktu, uang dan koneksi untuk mengembangkan beberapa perangkat lunak, maka Anda dapat menyatakan alasan berikut:

Kami ingin melakukannya, tapi kami tidak punya alat yang tepat.

Tapi Anda bisa bersimpati dengan ini. Saya sangat setuju. Yang perlu Anda lakukan adalah memaksa server web untuk segera mengurai URI persisten dan mengembalikan file di mana pun file tersebut disimpan di sistem file gila Anda saat ini. Anda ingin menyimpan semua URI dalam file sebagai cek dan selalu memperbarui database. Anda ingin menjaga hubungan antara versi berbeda dan terjemahan dokumen yang sama, dan juga memelihara catatan checksum independen untuk memastikan bahwa file tidak rusak karena kesalahan yang tidak disengaja. Dan server web tidak siap pakai dengan fitur-fitur ini. Saat Anda ingin membuat dokumen baru, editor Anda meminta Anda menentukan URI.

Anda harus dapat mengubah kepemilikan, akses dokumen, keamanan tingkat arsip, dll. di ruang URI tanpa mengubah URI.

Semuanya terlalu buruk. Tapi kami akan memperbaiki situasinya. Di W3C, kami menggunakan fungsionalitas Jigedit (server pengeditan Jigsaw) yang melacak versi, dan kami bereksperimen dengan skrip pembuatan dokumen. Jika Anda mengembangkan alat, server, dan klien, perhatikan masalah ini!

Alasan ini juga berlaku untuk banyak halaman W3C, termasuk yang ini: jadi lakukan apa yang saya katakan, bukan seperti yang saya lakukan.

Mengapa saya harus peduli?

Saat Anda mengubah URI di server Anda, Anda tidak akan pernah bisa mengetahui sepenuhnya siapa yang memiliki tautan ke URI lama. Ini bisa berupa tautan dari halaman web biasa. Tandai halaman Anda. URI mungkin tertulis di pinggir surat kepada teman.

Ketika seseorang mengikuti tautan dan tautan itu rusak, mereka biasanya kehilangan kepercayaan pada pemilik server. Ia juga frustrasi, baik secara emosional maupun fisik, karena tidak mampu mencapai tujuannya.

Banyak orang selalu mengeluh tentang tautan yang rusak, dan saya berharap kerusakannya terlihat jelas. Saya berharap kerusakan reputasi pada pengelola server tempat hilangnya dokumen juga terlihat jelas.

Jadi apa yang harus aku lakukan? desain URI

Merupakan tanggung jawab webmaster untuk mengalokasikan URI yang dapat digunakan dalam 2 tahun, dalam 20 tahun, dalam 200 tahun. Ini membutuhkan perhatian, pengorganisasian, dan tekad.

URI berubah jika ada informasi di dalamnya yang berubah. Cara Anda mendesainnya sangatlah penting. (Apa, desain URI? Apakah saya perlu mendesain URI? Ya, Anda harus memikirkannya). Desain pada dasarnya berarti menghilangkan informasi apa pun di URI.

Tanggal pembuatan dokumen – tanggal penerbitan URI – adalah sesuatu yang tidak akan pernah berubah. Sangat berguna untuk memisahkan query yang menggunakan sistem baru dengan query yang menggunakan sistem lama. Ini adalah tempat yang baik untuk memulai dengan URI. Jika suatu dokumen diberi tanggal, meskipun dokumen tersebut akan relevan di masa mendatang, ini adalah awal yang baik.

Satu-satunya pengecualian adalah halaman yang sengaja dibuat versi "terbaru", misalnya untuk seluruh organisasi atau sebagian besarnya.

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

Ini adalah kolom Money Daily terbaru di majalah Money. Alasan utama mengapa tidak diperlukannya tanggal dalam URI ini adalah karena tidak ada alasan untuk menyimpan URI yang akan bertahan lebih lama dari log. Konsep Money Daily akan hilang ketika Uang menghilang. Jika Anda ingin menautkan ke konten, Anda harus menautkannya secara terpisah di arsip:

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

(Kelihatannya bagus. Mengasumsikan bahwa "uang" akan memiliki arti yang sama sepanjang masa pakai pathfinder.com. Ada duplikat "98" dan ".html" yang tidak perlu, tetapi sebaliknya tampak seperti URI yang kuat.

Apa yang harus dikesampingkan

Semua! Selain tanggal pembuatan, memasukkan informasi apa pun ke dalam URI akan menimbulkan masalah.

Nama penulis. Kepengarangan dapat berubah seiring tersedianya versi baru. Orang-orang meninggalkan organisasi dan meneruskan sesuatu kepada orang lain.
Subjek. Ini sangat sulit. Awalnya selalu terlihat bagus, tetapi ternyata berubah dengan sangat cepat. Saya akan berbicara lebih banyak tentang ini di bawah.
Status. Direktori seperti "lama", "draf" dan seterusnya, belum lagi "terbaru" dan "keren", muncul di semua sistem file. Dokumen berubah status - jika tidak, tidak ada gunanya membuat draf. Versi terbaru dokumen memerlukan pengidentifikasi tetap, apa pun statusnya. Jauhkan status dari namanya.
Mengakses. Di W3C, kami telah membagi situs menjadi beberapa bagian untuk karyawan, anggota, dan publik. Kedengarannya bagus, tapi tentu saja, dokumen dimulai dari ide tim dari staf, didiskusikan dengan anggota, dan kemudian menjadi pengetahuan publik. Akan sangat disayangkan jika setiap kali sebuah dokumen dibuka untuk diskusi lebih luas, semua tautan lama ke dokumen tersebut rusak! Sekarang kita beralih ke kode tanggal sederhana.
Ekstensi file. Kejadian yang sangat umum. "cgi", bahkan ".html" akan berubah di masa mendatang. Anda mungkin tidak akan menggunakan HTML untuk laman ini dalam 20 tahun, namun tautan saat ini ke laman tersebut masih dapat digunakan. Tautan kanonik di situs W3C tidak menggunakan ekstensi (bagaimana hal itu dilakukan).
Mekanisme perangkat lunak. Di URI, cari "cgi", "exec" dan istilah lain yang meneriakkan "lihat perangkat lunak apa yang kami gunakan". Adakah yang ingin menghabiskan seluruh hidupnya menulis skrip Perl CGI? TIDAK? Kemudian hapus ekstensi .pl. Baca manual server tentang cara melakukan ini.
Nama disk. Ayo! Tapi saya sudah melihat ini.

Jadi contoh terbaik dari situs kami adalah sederhana

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

... laporan risalah rapat Ketua W3C.

Topik dan klasifikasi berdasarkan topik

Saya akan membahas lebih detail tentang bahaya ini, karena ini adalah salah satu hal yang paling sulit untuk dihindari. Biasanya, topik berakhir di URI saat Anda mengategorikan dokumen berdasarkan pekerjaan yang dilakukannya. Namun rincian ini akan berubah seiring berjalannya waktu. Nama-nama daerah akan berubah. Di W3C kami ingin mengubah MarkUP menjadi Markup dan kemudian menjadi HTML untuk mencerminkan konten sebenarnya dari bagian tersebut. Selain itu, sering kali terdapat namespace datar. Dalam 100 tahun, apakah Anda yakin tidak ingin menggunakan kembali apa pun? Dalam hidup kita yang singkat, kita sudah ingin menggunakan kembali "History" dan "Style Sheets" misalnya.

Ini adalah cara yang menggoda untuk mengatur situs web—dan cara yang sangat menggoda untuk mengatur apa pun, termasuk keseluruhan Web. Ini adalah solusi jangka menengah yang bagus namun memiliki kelemahan serius dalam jangka panjang.

Sebagian alasannya terletak pada filosofi makna. Setiap istilah dalam suatu bahasa merupakan target potensial untuk pengelompokan, dan setiap orang mungkin memiliki gagasan berbeda tentang artinya. Karena hubungan antar entitas lebih mirip jaring daripada pohon, bahkan mereka yang setuju dengan jaring pun dapat memilih representasi pohon yang berbeda. Ini adalah pengamatan umum saya (yang sering diulang) tentang bahaya klasifikasi hierarki sebagai solusi umum.

Faktanya, saat Anda menggunakan nama topik di URI, Anda berkomitmen pada semacam klasifikasi. Mungkin di masa depan Anda akan memilih opsi lain. URI kemudian akan rentan terhadap pelanggaran.

Alasan penggunaan area subjek sebagai bagian dari URI adalah tanggung jawab untuk subbagian ruang URI biasanya didelegasikan, dan kemudian Anda memerlukan nama badan organisasi - departemen, grup, atau apa pun - yang bertanggung jawab atas subruang tersebut. Ini adalah URI yang mengikat struktur organisasi. Biasanya hanya aman jika URI selanjutnya (kiri) dilindungi oleh tanggal: 1998/pics mungkin berarti bagi server Anda "apa yang kami maksud pada tahun 1998 dengan foto" daripada "apa yang kami lakukan pada tahun 1998 dengan apa yang sekarang kami sebut foto.”

Jangan lupa nama domainnya

Ingatlah bahwa ini tidak hanya berlaku untuk jalur di URI, tetapi juga untuk nama server. Jika Anda memiliki server terpisah untuk berbagai hal, ingatlah bahwa pembagian ini tidak mungkin diubah tanpa merusak banyak sekali tautan. Beberapa kesalahan klasik "lihat perangkat lunak yang kita gunakan saat ini" adalah nama domain "cgi.pathfinder.com", "aman", "lists.w3.org". Mereka dirancang untuk membuat administrasi server lebih mudah. Terlepas dari apakah domain mewakili divisi di perusahaan Anda, status dokumen, tingkat akses, atau tingkat keamanan, berhati-hatilah sebelum menggunakan lebih dari satu nama domain untuk beberapa jenis dokumen. Ingatlah bahwa Anda dapat menyembunyikan beberapa server web di dalam satu server web yang terlihat dengan menggunakan pengalihan dan proksi.

Oh, dan pikirkan juga nama domain Anda. Anda tidak ingin disebut sebagai sabun.com setelah Anda mengubah lini produk dan berhenti membuat sabun (Maaf kepada siapa pun yang memiliki sabun.com saat ini).

Kesimpulan

Mempertahankan URI selama 2, 20, 200, atau bahkan 2000 tahun jelas tidak semudah kelihatannya. Namun, di seluruh Internet, webmaster membuat keputusan yang membuat tugas ini sangat sulit di masa depan. Seringkali hal ini terjadi karena mereka menggunakan alat yang tugasnya hanya menyajikan situs terbaik saat ini - dan belum ada yang menilai apa yang akan terjadi pada tautan tersebut ketika semuanya berubah. Namun, intinya di sini adalah banyak hal yang bisa berubah, dan URI Anda bisa dan harus tetap sama. Ini hanya mungkin jika Anda memikirkan cara Anda membuatnya.

Lihat juga:

Omelan Jakob Nielsen dengan topik yang sama

Penambahan

Cara menghapus ekstensi file...

...dari URI di server web berbasis file saat ini?

Jika Anda menggunakan Apache, misalnya, Anda dapat mengonfigurasinya untuk menegosiasikan konten. Simpan ekstensi file (mis. .png) ke file (mis. anjingku.png), namun Anda dapat menautkan ke sumber daya web tanpa sumber daya tersebut. Apache kemudian memeriksa direktori untuk semua file dengan nama itu dan ekstensi apa pun, dan dapat memilih yang terbaik dari kumpulan (misalnya, GIF dan PNG). Dan tidak perlu meletakkan jenis file yang berbeda di direktori yang berbeda, bahkan pencocokan konten tidak akan berfungsi jika Anda melakukan itu.

Siapkan server Anda untuk menegosiasikan konten
Selalu tautkan ke URI tanpa ekstensi

Tautan dengan ekstensi akan tetap berfungsi, namun akan mencegah server Anda memilih format terbaik yang tersedia saat ini dan di masa mendatang.

(Nyatanya, mydog, mydog.png и mydog.gif — sumber daya web yang valid, mydog adalah sumber daya tipe konten universal, dan mydog.png и mydog.gif — sumber daya dari tipe konten tertentu).

Tentu saja, jika Anda membuat server web Anda sendiri, sebaiknya gunakan database untuk mengikat pengidentifikasi persisten ke bentuknya saat ini, namun berhati-hatilah terhadap pertumbuhan database yang tidak terbatas.

Dewan Malu - Cerita 1: Saluran 7

Selama tahun 1999, saya melacak penutupan sekolah karena salju di halaman http://www.whdh.com/stormforce/closings.shtml. Jangan tunggu informasinya muncul di bagian bawah layar TV! Saya menautkannya dari halaman beranda saya. Badai salju besar pertama tahun 2000 tiba dan saya memeriksa halamannya. Di sana tertulis :,

- Pada.
Saat ini tidak ada yang ditutup. Silakan kembali jika ada peringatan cuaca.

Badainya tidak mungkin sekuat itu. Lucu sekali tanggalnya hilang. Namun jika Anda masuk ke halaman utama situs tersebut, akan ada tombol besar “Sekolah Tertutup” yang mengarah ke halaman tersebut. http://www.whdh.com/stormforce/ dengan daftar panjang sekolah yang tutup.

Mungkin mereka mengubah sistem untuk mendapatkan daftarnya - tetapi mereka tidak perlu mengubah URI.

Dewan Malu - Cerita 2: Microsoft Netmeeting

Dengan meningkatnya ketergantungan pada Internet, muncul ide cerdas bahwa tautan ke situs web produsen dapat disematkan dalam aplikasi. Ini telah banyak digunakan dan disalahgunakan, tetapi Anda tidak dapat mengubah URL-nya. Beberapa hari yang lalu saya mencoba tautan dari klien Microsoft Netmeeting 2/something di menu Bantuan/Microsoft di Web/Barang Gratis dan menerima kesalahan 404 - tidak ada respons dari server yang ditemukan. Mungkin sudah diperbaiki...

Catatan sejarah: Pada akhir abad ke-20, ketika kata ini ditulis, "keren" adalah sebuah julukan yang menyatakan persetujuan, terutama di kalangan anak muda, yang menunjukkan kelayakan, kualitas, atau kesesuaian. Terburu-buru, jalur URI sering kali dipilih karena "kesejukan" daripada kegunaan atau daya tahannya. Postingan ini merupakan upaya untuk mengalihkan energi di balik pencarian keren.

Sumber: www.habr.com

URI keren tidak berubah