What URI is Cool?
Yang tidak berubah.
Bagaimana URI berubah?
URI tidak berubah: orang mengubahnya.
Secara teori, tidak ada alasan bagi manusia untuk mengubah URI (atau berhenti memelihara dokumen), tetapi dalam praktiknya ada jutaan.
Secara teori, pemilik nominal dari ruang nama domain sebenarnya memiliki ruang nama domain dan oleh karena itu semua URI di dalamnya. Selain kebangkrutan, tidak ada yang mencegah pemilik nama domain untuk menyimpan nama ini. Dan secara teori, ruang URI di bawah nama domain Anda sepenuhnya di bawah kendali Anda, sehingga Anda dapat membuatnya stabil sesuka Anda. Satu-satunya alasan yang bagus untuk menghilangkan dokumen dari internet adalah karena perusahaan yang memiliki nama domain telah gulung tikar atau tidak mampu lagi menjaga server tetap berjalan. Lalu mengapa ada begitu banyak mata rantai yang hilang di dunia? Ini sebagian hanya karena kurangnya pandangan ke depan. Berikut beberapa alasan Anda dapat mendengar:
Kami baru saja mengatur ulang situs agar lebih baik.
Apakah Anda benar-benar merasa URI lama tidak dapat berfungsi lagi? Jika demikian, Anda telah memilih mereka dengan sangat buruk. Pertimbangkan untuk menyimpan yang baru dari desain ulang berikutnya.
Kami memiliki begitu banyak materi sehingga kami tidak dapat melacak apa yang sudah kadaluwarsa, apa yang dirahasiakan, dan apa yang masih relevan, jadi kami pikir lebih baik mematikannya saja.
Saya hanya bisa bersimpati. W3C telah melalui periode di mana kami harus menyaring materi arsip untuk menjaga kerahasiaan dengan hati-hati sebelum dipublikasikan. Keputusan harus dipikirkan sebelumnya - pastikan Anda mencatat dengan setiap dokumen rentang pembaca yang dapat diterima, tanggal pembuatan dan, idealnya, tanggal kedaluwarsa. Simpan metadata ini.
Nah, kami menemukan bahwa kami perlu memindahkan file ...
Ini adalah salah satu alasan paling menyedihkan. Banyak orang tidak tahu bahwa server web memungkinkan Anda mengontrol hubungan antara URI objek dan lokasi sebenarnya dalam sistem file. Pikirkan ruang URI sebagai ruang abstrak, tertata dengan sempurna. Kemudian petakan ke realitas apa pun yang sebenarnya Anda gunakan untuk menerapkannya. Kemudian laporkan ke web server. Anda bahkan dapat menulis cuplikan server Anda untuk melakukannya dengan benar.
John tidak lagi mengelola file ini, sekarang Jane.
Apakah nama John ada di URI? Tidak, hanya file itu di direktorinya? Baiklah.
Kami dulu menggunakan skrip CGI untuk ini, tetapi sekarang kami menggunakan program biner.
Ada ide gila bahwa halaman dalam script harus ditempatkan di area "cgibin" atau "cgi". Ini memperlihatkan mekanisme bagaimana Anda memulai server web Anda. Ubah mekanismenya (bahkan mempertahankan konten) dan ups - semua URI Anda berubah.
Ambil National Science Foundation (NSF) sebagai contoh: NSF
Online Documents
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, oldbrowsedan pl - semua ini memberikan partikel informasi tentang bagaimana-kita-melakukannya-sekarang. Jika Anda menggunakan halaman untuk mencari dokumen, Anda mendapatkan hasil yang sama buruknya terlebih dahulu:
Laporan kelompok kerja tentang 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, heading pubs / 1998 akan memberikan layanan pengarsipan di masa mendatang sebuah petunjuk yang baik bahwa skema klasifikasi dokumen tahun 1998 yang lama sedang berlaku. Meskipun nomor dokumen mungkin terlihat berbeda pada tahun 2098, saya dapat membayangkan bahwa URI ini akan tetap valid dan tidak akan mengganggu NSF atau organisasi lain yang akan memelihara arsip.
Saya tidak berpikir URL seharusnya persisten - mereka adalah URN.
Ini mungkin salah satu efek samping terburuk dari diskusi URN. Beberapa orang berpikir bahwa karena penelitian pada namespace yang lebih persisten, mereka mungkin ceroboh tentang tautan yang menggantung karena "URN akan memperbaiki semuanya". Jika Anda salah satu dari orang-orang ini, biarkan saya kecewa.
Sebagian besar skema URN yang pernah saya lihat terlihat seperti pengenal otoritas yang diikuti oleh tanggal dan string yang Anda pilih, atau hanya string yang Anda pilih. Ini sangat mirip dengan HTTP URI. Dengan kata lain, jika menurut Anda organisasi Anda dapat membuat URN berumur panjang, buktikan sekarang dengan menggunakannya untuk URI HTTP Anda. Tidak ada apa pun di 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 benar-benar mengambil file.
Jika Anda sudah sampai pada titik ini, maka jika Anda tidak punya waktu, uang dan koneksi untuk mengembangkan beberapa jenis perangkat lunak, maka Anda dapat menyatakan alasan berikut:
Kami ingin, tetapi kami tidak memiliki alat yang tepat.
Tapi Anda bisa bersimpati dengan ini. Saya sangat setuju. Yang perlu Anda lakukan adalah memaksa server web untuk langsung memproses URI persisten dan mengembalikan file di mana pun saat ini disimpan di sistem file gila Anda saat ini. Anda ingin menyimpan semua URI dalam sebuah file sebagai pemeriksaan dan selalu memperbarui database. Anda ingin mempertahankan hubungan antara versi yang berbeda dan terjemahan dari dokumen yang sama, dan juga mempertahankan catatan checksum independen untuk melindungi dari kesalahan yang tidak disengaja dalam file. Dan server web tidak keluar dari kotak dengan fitur-fitur ini. Saat Anda ingin membuat dokumen baru, editor Anda meminta URI.
Anda memerlukan kemampuan untuk mengubah kepemilikan, akses dokumen, keamanan tingkat arsip, dan sebagainya di ruang URI tanpa mengubah URI.
Sayang sekali. 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 yang saya lakukan.
Mengapa saya harus peduli?
Saat Anda mengubah URI di server, Anda tidak akan pernah bisa mengetahui sepenuhnya siapa yang akan mereferensikan URI lama. Ini bisa berupa tautan dari halaman web biasa. Bookmark ke halaman Anda. URI mungkin telah tergores di margin surat ke teman.
Saat seseorang mengklik link dan link tersebut rusak, mereka biasanya kehilangan kepercayaan pada pemilik server. Dia juga kecewa - baik secara emosional maupun realistis karena ketidakmampuan untuk mencapai tujuannya.
Banyak orang terus-menerus mengeluh tentang tautan yang rusak, dan saya harap 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, organisasi dan komitmen.
URI berubah jika beberapa informasi berubah di dalamnya. Bagaimana Anda mendesainnya sangat penting. (Apa, desain URI? Saya perlu mendesain URI? Ya, Anda harus memikirkannya). Desain pada dasarnya berarti tidak memiliki informasi apa pun di URI.
Tanggal dokumen dibuat - tanggal URI diterbitkan - sesuatu yang tidak akan pernah berubah. Ini sangat berguna untuk memisahkan permintaan yang menggunakan sistem baru dari yang menggunakan sistem lama. Ini adalah titik awal yang baik untuk URI. Jika dokumen tersebut diberi tanggal, meskipun dokumen tersebut relevan di masa mendatang, maka ini adalah awal yang baik.
Satu-satunya pengecualian adalah halaman yang sengaja dibuat versi "terbaru", misalnya, untuk seluruh organisasi atau sebagian besar darinya.
http://www.pathfinder.com/money/moneydaily/latest/
Ini adalah kolom terakhir majalah Money Daily in Money. Alasan utama URI ini tidak memerlukan tanggal adalah karena tidak ada alasan untuk menyimpan URI yang akan bertahan dari log. Konsep Uang Harian 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. Asumsikan "uang" akan memiliki arti yang sama untuk kehidupan pathfinder.com. Ada duplikat "98" dan ".html" yang tidak perlu, tetapi sebaliknya terlihat seperti URI yang kuat.
Apa yang harus dikesampingkan
Semua! Selain tanggal pembuatan, memasukkan informasi apa pun ke dalam URI adalah salah satu cara untuk menimbulkan masalah.
- Nama penulis . Blame dapat berubah dengan versi baru. Orang meninggalkan organisasi dan menyebarkan sesuatu kepada orang lain.
- Subjek . Ini sangat sulit. Dia selalu terlihat bagus pada awalnya, tetapi berubah dengan sangat cepat. Saya akan membicarakan lebih banyak tentang ini di bawah.
- Status . Direktori seperti "lama", "draf", dan seterusnya, belum lagi "terbaru" dan "keren", muncul di semua sistem file. Dokumen mengubah status - jika tidak, tidak ada gunanya membuat draf. Versi terbaru dokumen membutuhkan pengenal tetap, apa pun statusnya. Jauhkan status dari nama.
- . W3C , . , , , , , . , , , - , ! .
- . . "cgi", ".html" . , 20 HTML , . W3C ( ).
- Mekanisme perangkat lunak . Di URI, cari "cgi", "exec" dan istilah lain yang berteriak "lihat software apa yang kami gunakan". Adakah yang ingin mengabdikan seluruh hidup mereka untuk skrip Perl CGI? Tidak? Kemudian hapus ekstensi .pl. Baca manual server tentang bagaimana melakukan ini.
- Nama disk. Ayolah! Tapi saya pernah melihat itu.
Jadi contoh terbaik dari situs kami adalah
http://www.w3.org/1998/12/01/chairs
… Laporan risalah rapat ketua W3C.
Topik dan klasifikasi berdasarkan topik
Saya akan menjelaskan lebih detail tentang bahaya ini, karena ini adalah salah satu hal yang paling sulit untuk dihindari. Biasanya, topik berakhir di URI saat Anda mengkategorikan dokumen Anda berdasarkan pekerjaan yang sedang berlangsung. Tetapi kerusakan ini akan berubah seiring waktu. Nama area akan berubah. Di W3C, kami ingin mengubah MarkUP menjadi Markup dan kemudian HTML untuk mencerminkan konten sebenarnya dari bagian tersebut. Selain itu, namespace seringkali datar. Setelah 100 tahun, apakah Anda yakin tidak ingin menggunakan kembali apa pun? Dalam kehidupan kami yang singkat, kami sudah ingin menggunakan kembali "History" dan "Style Sheets", misalnya.
Ini cara yang menggoda untuk mengatur situs web - dan cara yang sangat menggoda untuk mengatur apa pun, termasuk seluruh Web. Ini adalah solusi jangka menengah yang sangat baik, tetapi memiliki kelemahan serius dalam jangka panjang.
Sebagian alasannya terletak pada filosofi makna. Setiap istilah dalam bahasa adalah objek pengelompokan potensial, dan setiap orang mungkin memiliki gagasan yang berbeda tentang artinya. Karena hubungan antar subjek lebih seperti jaring laba-laba daripada pohon, bahkan mereka yang setuju dengan jaring laba-laba dapat memilih representasi pohon yang berbeda. Ini adalah pernyataan umum saya (yang sering diulang) tentang bahaya klasifikasi hierarkis sebagai solusi umum.
Faktanya, saat Anda menggunakan nama topik dalam URI, Anda mengikatkan diri Anda pada semacam klasifikasi. Anda dapat memilih opsi lain di masa mendatang. Kemudian URI akan disusupi.
Alasan menggunakan area subjek sebagai bagian dari URI adalah tanggung jawab untuk sub-bagian dari ruang URI biasanya didelegasikan, dalam hal ini Anda memerlukan nama badan organisasi - unit, grup, atau apa pun - yang bertanggung jawab untuk sub-ruang tersebut. Ini adalah pengikatan URI ke struktur organisasi. Biasanya hanya aman jika URI jauh di bawah (kiri) dilindungi oleh tanggal: 1998 / pics dapat berarti "apa yang kami maksud pada tahun 1998 dengan foto" ke server Anda daripada "apa yang kami lakukan dengan apa yang sekarang kita sebut foto. "
Jangan lupa nama domain Anda
Ingat bahwa ini tidak hanya berlaku untuk jalur di URI, tetapi juga untuk nama server. Jika Anda memiliki server terpisah untuk berbagai hal, ingatlah bahwa pemisahan ini tidak mungkin diubah tanpa merusak banyak, banyak tautan. Beberapa kesalahan klasik seperti "lihat perangkat lunak apa yang kita gunakan saat ini" adalah nama domain "cgi.pathfinder.com", "secure", "lists.w3.org". Mereka dirancang untuk memfasilitasi administrasi server. Terlepas dari apakah domain mewakili departemen tertentu dalam 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 banyak server web di dalam satu server web yang terlihat,menggunakan redirection dan proxying.
Ya, dan pikirkan juga tentang nama domain Anda. Anda tidak ingin disebut sebagai soap.com setelah Anda mengubah lini produk Anda dan berhenti membuat sabun (Maaf kepada siapa pun yang memiliki soap.com saat ini).
Kesimpulan
Menyimpan URI selama 2, 20, 200, atau bahkan 2000 tahun jelas tidak semudah kedengarannya. Namun, di seluruh internet, webmaster membuat keputusan yang benar-benar akan mempersulit diri mereka sendiri di masa mendatang. Hal ini sering terjadi karena mereka menggunakan alat yang tugasnya menyajikan situs terbaik hanya saat ini - dan tidak ada yang memperkirakan apa yang akan terjadi pada tautan ketika semuanya berubah. Namun, intinya di sini adalah banyak, banyak hal yang bisa berubah, dan URI Anda bisa dan harus tetap sama. Ini hanya mungkin jika Anda memikirkan tentang cara Anda membuatnya.
Lihat juga:
Suplemen
Cara menghapus ekstensi file ...
... dari URI di server web berbasis file saat ini?
Jika Anda menggunakan Apache, misalnya, Anda dapat mengkonfigurasinya untuk menegosiasikan konten. Anda menyimpan ekstensi file (misalnya, .png) dalam sebuah file (misalnya, mydog.png ), tetapi Anda dapat menautkan ke sumber daya web tanpanya. 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 Anda tidak perlu meletakkan berbagai jenis file di direktori yang berbeda, faktanya, negosiasi konten tidak akan berfungsi jika Anda melakukannya.
- Konfigurasikan server Anda untuk menegosiasikan konten
- Selalu rujuk URI tanpa ekstensi
Tautan ekstensi akan tetap berfungsi, tetapi akan mencegah server Anda memilih format terbaik yang tersedia saat ini dan di masa mendatang.
(Bahkan,
mydog, mydog.pngdan mydog.gif- kode dan sumber daya web mydog- jenis konten sumber daya universal, mydog.pngdan mydog.gif- sumber daya dari konten jenis tertentu).
Tentu saja, jika Anda membuat server web Anda sendiri, sebaiknya gunakan database untuk mengikat id persisten ke bentuknya saat ini, meskipun waspadalah terhadap pertumbuhan DB yang tidak terbatas.
Shame Board - Kisah 1: Saluran 7
Sepanjang 1999, saya melacak penutupan sekolah karena salju di seluruh halaman
http://www.whdh.com/stormforce/closings.shtml. Jangan menunggu informasi muncul di bagian bawah layar TV! Saya menautkannya dari halaman beranda saya. Badai salju besar pertama tahun 2000 datang dan saya memeriksa halamannya. Dikatakan:
- Pada.
Tidak ada yang ditutup saat ini. Harap kembali jika ada peringatan cuaca.
Ini tidak mungkin badai kuat yang sama. Lucu kalau tanggalnya hilang. Tetapi jika Anda pergi ke halaman utama situs, akan ada tombol besar "Sekolah Tertutup", yang mengarah ke halaman
http://www.whdh.com/stormforce/dengan daftar panjang sekolah tertutup.
Mungkin mereka mengubah sistem untuk mendapatkan daftar - tetapi mereka tidak perlu mengubah URI.
Shame Board - Kisah 2: Microsoft Netmeeting
Dengan ketergantungan yang semakin besar pada Internet, ide cerdas datang ke aplikasi yang Anda dapat menyematkan tautan ke situs web pabrikan. Ini telah digunakan dan banyak disalahgunakan, tetapi - Anda tidak dapat mengubah URL-nya. Beberapa hari yang lalu saya mencoba tautan dari klien Microsoft Netmeeting 2 / sesuatu di menu Bantuan / Microsoft di Web / Barang gratis dan mendapat kesalahan 404 - tidak ada tanggapan yang ditemukan dari server. Mungkin sudah diperbaiki ...
© 1998 Tim BL
Catatan sejarah: Di akhir abad ke-20, ketika ini ditulis, "keren" adalah julukan persetujuan, terutama di kalangan anak muda, yang menunjukkan mode, kualitas atau kesesuaian. Dengan tergesa-gesa, jalur URI sering dipilih karena "keren" daripada utilitas atau umur panjang. Posting ini adalah upaya untuk mengarahkan energi di balik pencarian keren.
Lihat juga: