Menyediakan URL yang ramah untuk situs web vs. realitas ID basis data

24

Kami memiliki database sumber daya, baik itu produk, posting blog atau sesuatu. Kita perlu merancang skema URL untuk mengatasinya, untuk situs web publik.

Berikut adalah dua contoh yang terikat ID basis data:

Berikut ini contoh yang ramah:

http://en.wikipedia.org/wiki/LED_circuit

(Sedikit melihat kehidupan browsing saya di sana)

Saya suka URL ramah karena Anda memiliki gagasan tentang apa yang ada di akhir URL ketika Anda mengarahkan atau melihatnya di email atau dokumen. Ini lebih baik untuk SEO, atau dulu.

Apa yang terjadi ketika dokumen atau produk diganti namanya? Entah karena itu berubah (Wiki mungkin tidak berubah tetapi sumber daya kami bisa) atau karena kesalahan ketik, kan? Sumber daya kami sangat teknis, kata-kata panjang dan rawan kesalahan.

Kami juga memiliki ID basis data yang merupakan angka. Mari kita lihat ide untuk alamat video menggunakan toko rental yang berpura-pura:

http://vidsyeah.com/video/sliding-doors/287171

ID jelas dan digunakan dalam pencarian DB. Baik.

Bit pintu geser tidak unik dan hanya dihasilkan dari judul video, dapat diverifikasi di GET, jadi jika pintu geser dimasukkan dan tidak cocok dengan apa yang sebenarnya dalam dokumen 287171, responsnya mencapai 404.

Atau mungkin itu bisa diabaikan, membiarkan manusia untuk menempel apa pun yang mereka suka di sana, jika seseorang pernah peduli. Jadi URL ini juga berfungsi:

http://vidsyeah.com/video/anything-at_all/287171

Masalah dengan memverifikasi bagian ramah, seperti yang disebutkan, masalah penggantian nama atau koreksi salah ketik. Jika nama berubah, dan di domain kami yang terjadi, kami tidak ingin memecah URL yang ada di luar, jadi sebaiknya kami:

Hanya tidak memverifikasi bagian yang ramah.
Verifikasi, tetapi tambahkan 'riwayat' bagian yang ramah ke catatan basis data sehingga ID ramah sebelumnya masih berfungsi!

Pikiran dan ide Anda dipersilakan.

Luke

— Luke Puplett
sumber

11

bahkan situs ini pun menggunakan kombinasi http://programmers.stackexchange.com/questions/255684/providing-friendly-urls-for-a-website-vs-realities-of-database-ids(menggunakan versi yang tidak diverifikasi sehubungan dengan perubahan judul, juga tautan "bagikan" yang lebih pendek hanyalah id: http://programmers.stackexchange.com/q/255684/25768(dan id pengguna untuk pelacakan lencana)

— ratchet freak

11

Jika Anda memiliki id unik di URL Anda, saya tidak melihat mengapa Anda ingin memverifikasi bagian slug sama sekali. Gunakan untuk penampilan dan abaikan untuk pencarian.

— thorsten müller

Jika salah satu dari Anda ingin memberikan jawaban yang tepat, saya akan memilih sehingga Anda mendapatkan poin. Saya akan membiarkan suara masuk dan memberikan jawaban kepada yang paling banyak dipilih dalam beberapa hari.

— Luke Puplett

1

programmers.stackexchange.com/questions/231483/…

— agas

3

Tidak pernah tahu istilah siput sebelumnya. Saya pasti berada di bawah batu. Geddit?

— Luke Puplett

6

Menyimpan ID di URL adalah metode bukti paling masa depan dan saat Anda menunjukkan, URL masih bisa terlihat relatif baik.

Opsi lain yang digunakan oleh banyak proyek adalah untuk menjaga sejarah siput yang sebelumnya digunakan. Ketika judul berubah, Anda memperbarui siput dan jika seseorang mencoba mencari siput usang, cari di daftar siput tua. Dengan cara itu siput tua dapat digunakan kembali untuk konten baru (atau tidak tergantung pada implementasi Anda).

Wordpress melakukannya dan begitu pula permata friendly_id yang mungkin merupakan permata yang paling banyak digunakan untuk mengelola id ramah untuk Rails.

Selain itu, walaupun saya suka URL yang terlihat bagus, saya pikir penting untuk diingat bahwa ini kemungkinan besar merupakan fitur yang digunakan oleh lebih banyak pengguna yang mengerti teknologi. Beberapa browser bahkan mulai menyembunyikan URL (atau bagian dari itu).

— mbillard
sumber

2

Sejarah siput inilah yang saya pertimbangkan. Sejak memposting pertanyaan, saya perhatikan banyak situs besar bernama yang memiliki siput yang tidak diperiksa, Anda dapat mengubahnya untuk mengatakan apa pun. amazon.co.uk/Blah-Blah-Blah/dp/B004R276L8 berfungsi. StackExchange pintar karena 'mengoreksi' dan mengarahkan ulang browser untuk memastikan tautan yang tepat ditampilkan dan dibagikan.

— Luke Puplett

"Siput" kurang bermanfaat bagi orang-orang, dan lebih berguna untuk Optimasi Mesin Pencari, karena "siput" atau "URL yang bersahabat" harus memiliki kata kunci yang berkaitan dengan konten halaman. Pengguna mahir bukan alasan untuk memasukkan URL ramah di situs Anda. Peringkat mesin pencari cenderung menjadi alasan utama.

— Greg Burghardt

Saya tidak setuju. URL dengan ID saja sulit untuk dikerjakan; sulit untuk mengingat dari daftar mereka yang mana Anda mungkin ingin kembali. Atau apakah akan ada sesuatu yang tidak pantas di ujung tautan yang lain. Bilah alamat Chrome menyarankan bagian URL mana pun, yang berguna.

— Luke Puplett

1

@ LukePuplett ya saya percaya cara SE menangani URL adalah yang termudah dalam hal siput.

— mbillard

@GregBurghardt satu-satunya perbedaan adalah dalam rasio klik-tayang, pengguna cenderung mengklik sedikit lebih banyak pada URL yang ramah: stackoverflow.com/questions/505793/…

— mbillard

3

Saya telah menggunakan dua skenario berbeda di masa lalu.

/id/some-slugmana yang iddigunakan untuk pencarian , siput tidak. Dengan demikian siput bisa berupa apa saja . Tetapi, ketika siput tidak cocok dengan siput yang sebenarnya, pengguna diarahkan ke versi saat ini.
/permalinkuntuk kasus-kasus di mana kami tidak menginginkan id di url atau di mana url tidak boleh berubah, meskipun ada id yang tersedia (lihat [1] dan [2] ). Tentu saja, dalam hal ini yang permalinkdigunakan untuk lookup . Kedua siput saat ini dan permalink (siput pertama) disimpan dalam database.

Dalam kedua cara ini Anda tidak perlu menyimpan sejarah siput dalam database Anda, yang akan menjadi masalah segera.

ps: Dalam kasus kedua Anda akan memerlukan beberapa rute yang sangat spesifik untuk menjaga kredit sosial:

jika Anda mau, arahkan pengguna ke url saat ini (non permalink)
minta permalink digunakan sebagai url di tombol sosial
selalu mengarahkan perayap facebook ke permalink

Lihat [1] dan [2] lagi.

— Lapisan
sumber

Kenapa itu akan bermasalah? Jika saya menyimpan dan ID dan siput adalah apa saja, pengunjung akan pergi ke halaman yang sebenarnya. Apakah akan berbahaya untuk SEO?

— Jnanaranjan

Maksudmu menyimpan sejarah siput? Apa yang Anda lakukan ketika seseorang ingin menggunakan kembali siput seperti itu? Untuk id yang sama atau yang lain? Bagaimana Anda mendesain basis data dan / atau kode untuk mencegah beberapa arahan ulang? Apakah Anda ingin menyembunyikan keberadaan setelah penghapusan dan apakah pengalihan mengekspos keberadaan sebelumnya? Semua ini bukan tidak mungkin, tetapi menimbulkan semua jenis pertanyaan yang agak saya cegah dengan desain.

— Lode

Yang ingin saya katakan adalah jika ID ada di URL maka tidak peduli apa siput itu akan diarahkan ke halaman yang diminta. Maka sejarah siput tidak masalah. Saya setuju bahwa itu bermasalah untuk Android.

— Jnanaranjan

1

Ah baiklah. Itulah yang saya tambahkan skenario 1 kan? Atau maksud Anda sesuatu yang lain?

— Lode

Iya nih. Itu betul.

— Jnanaranjan

2

Apa yang terjadi ketika dokumen atau produk diganti namanya?

Respons HTTP 301 (Pindah) dirancang untuk tujuan ini. Jika ada klien yang masuk ke URI lama, Anda cukup mengirimi mereka URI baru dan mereka dapat mengarahkannya kembali.

Bit pintu geser tidak unik dan hanya dihasilkan dari judul video, dapat diverifikasi di GET, jadi jika pintu geser dimasukkan dan tidak cocok dengan apa yang sebenarnya dalam dokumen 287171, responsnya mencapai 404.

Jika saya mengikuti dengan benar ini adalah pekerjaan duplikat, Anda memiliki pengenal nama untuk sumber daya dan id di URI yang sama. Itu tidak melayani tujuan apa pun.

Jika Anda khawatir tentang beberapa film dengan nama yang sama, Anda dapat menambahkan informasi tambahan tentang film ke dalam URL

http://vidsyeah.com/video/2000/sliding_doors
http://vidsyeah.com/video/1932/sliding_doors

atau

http://vidsyeah.com/video/studios/paramount/sliding_doors
http://vidsyeah.com/video/studios/warnerbros/sliding_doors

Setelah mengatakan bahwa tidak ada yang salah dengan menggunakan ID jika itu masuk akal untuk model data Anda, terutama jika satu-satunya hal yang Anda kelompokkan adalah bahwa itu adalah video.

http://vidsyeah.com/video/210232
http://vidsyeah.com/video/2342

Klien, baik komputer atau pengguna manusia seharusnya tidak terlalu bergantung pada struktur URI di tempat pertama, mereka harus melihat konten yang telah Anda kembalikan untuk mencari tahu sumber daya mana yang harus ditemukan.

Tidak ada yang salah dengan memiliki sistem URI yang masuk akal yang memudahkan seseorang untuk hanya menebak lokasi sumber daya atau menavigasi ke atas dan ke bawah struktur berdasarkan properti bersama (yaitu semua film pada tahun 2004), tetapi sistem Anda tidak boleh mengandalkan pada itu dan tidak ada klien yang akan rusak jika Anda mengubah URI Anda

Atau dengan kata lain, Anda harus dapat berubah dari malam

http://vidsyeah.com/video/studios/paramount/sliding_doors

untuk

http://vidsyeah.com/video/12323

dan tidak boleh ada klien yang putus karena klien harus melihat konten, bukan URL.

— Cormac Mulhall
sumber

Seperti jawaban Jon, saya pikir Anda tidak mengenakan topi UX saat memikirkan hal ini. Saya ingin meningkatkan daya guna alamat. Lihat komentar saya di pertanyaan: "Saya suka URL ramah karena Anda memiliki gagasan tentang apa yang ada di akhir URL ketika Anda mengarahkan atau melihatnya di email atau dokumen. Lebih baik untuk SEO, atau dulu."

— Luke Puplett

2

Untuk melempar 301, saya harus bisa mencari sumber yang benar, jadi saya perlu sejarah.

— Luke Puplett

1

Anda akan memerlukan riwayat, tetapi jika Anda memiliki situs dengan sumber daya yang berubah itu adalah ide yang bagus.

— Cormac Mulhall

Tidak ada masalah dengan URI ramah. Saya tidak akan melakukan skema bahwa URI dapat berupa apa saja tetapi masih berfungsi jika memiliki ID pada akhirnya. Itu tidak benar-benar menyelesaikan masalah apa pun (pengguna masih harus mengingat ID) dan memperkenalkan skema URI yang membingungkan (pengguna mungkin secara sah bertanya mengapa dua URI berbeda, satu dengan kesalahan ejaan, pergi ke sumber daya yang sama)

— Cormac Mulhall

1

Jika Anda khawatir tentang kesalahan pengejaan dalam URI, cara umum untuk menangani hal ini adalah URI yang disarankan di halaman kesalahan 404 untuk URL yang dieja salah. Anda dapat melakukan pencarian pola kata dan memberikan kembali apa yang menurut Anda mungkin dicari pengguna.

— Cormac Mulhall

1

BBC menggunakan siput yang:

alpha-numeric (untuk kekompakan)
unik (untuk pencarian)
tidak berurutan (sehingga urutan hal-hal yang ditambahkan ke db tidak terbuka)

mis. http://www.bbc.co.uk/programmes/b006mk7h

Setiap program publik memiliki ID dan siput. ID kemudian dapat berupa bilangan bulat yang bertambah secara otomatis seperti biasa, dan celah tidak terbuka.

— Nicholas Shanks
sumber

0

Dari sudut pandang tenang, URI harus mengikuti struktur hierarkis yang dapat diprediksi dan mungkin untuk meningkatkan kegunaan.

Ini akan membuat mereka lebih mudah digunakan oleh konsumen. Jika data Anda memiliki hubungan, maka semacam hierarki akan diperlukan.

Sepertinya skemanya adalah: \video\[name]\[id]

Jika nama tidak digunakan untuk klasifikasi lebih lanjut, nama itu dapat dibatalkan \video\[id].

Namun, jika Anda ingin mengklasifikasikan video maka mungkin namanya berguna.

Contoh:

\ video \ SwingingDoors \ 123
\ video \ SwingingDoors \ 124
\ video \ SlidingDoors \ 125
\ video \ SlidingDoors \ 126

Ini benar-benar keputusan desain tentang bagaimana akses dimodelkan.

— Jon Raynor
sumber

Saya pikir Anda sedang memikirkan ini dari API / arsitektur informasi situs PoV. Saya ingin memperkenalkan bagian URL ramah yang dibuat untuk membantu manusia dan SEO. Rupanya ini adalah hal yang umum dan berjalan dengan nama 'siput'. Nama tidak digunakan untuk klasifikasi dan ditambahkan (tidak dijatuhkan) untuk membuat UX yang lebih baik dengan URL dan situs / merek kami.

— Luke Puplett