Haruskah saya menggunakan case title di URL?


9

Kami saat ini memutuskan pada konvensi penamaan yang konsisten di seluruh situs dengan beberapa aplikasi web. Secara historis, saya telah menjadi pendukung 'huruf kecil semua huruf!' saat membuat URL:

http://example.com/mysystem/account/view/1551

Namun, dalam satu atau dua tahun terakhir, khususnya sejak saya mulai menggunakan ASP.NET MVC & memiliki lebih banyak berurusan dengan URL berbasis REST, saya telah menjadi penggemar memanfaatkan huruf pertama dari setiap bagian / kata dalam URL saat membuatnya. lebih mudah dibaca (imho).

http://example.com/MySystem/Account/View/1551

Kami tidak berada dalam situasi di mana orang perlu membaca atau memahami URL, jadi itu bukan driver. Hal utama yang kami kejar adalah pendekatan konsisten yang rasional dan masuk akal.

Apakah ada standar yang menyatakan itu baik untuk melakukan satu atau lain cara, atau masalah yang mungkin kita hadapi pada (setidaknya modern realistis) pengaturan yang akan memilih preferensi daripada yang lain? Apa konsensus umum untuk debat ini saat ini?

Jawaban:


10

Karena pilihannya terutama kosmetik (yaitu, sebagian besar sistem tidak membedakan antara huruf besar dan kecil, dan pengguna tentu tidak), maka saya sarankan hanya pergi dengan mana saja yang membuat Anda bahagia. Konsistensi dalam aplikasi adalah kuncinya , bukan cara yang Anda pilih.

Saat Anda menggunakan ASP.Net, saya akan merekomendasikan pergi dengan pendekatan PascalCase - karena itulah yang cenderung ada dalam kerangka kerja Microsoft (pustaka sistem, dll.) Tapi tidak ada "praktik terbaik" selain konsisten.

Sebagian besar browser melakukan pekerjaan yang cukup baik untuk menyembunyikan URL dari pengguna, sedemikian rupa sehingga banyak orang yang memiliki google sebagai halaman rumah mereka, kemudian akan mencari facebook dan mengkliknya - daripada memasukkan url facebook di mereka browser.


7
Tetapi sistem ini memang membedakan ...
ghoppe

1
Anda setidaknya harus menyebutkan bahwa sensitivitas case tergantung pada konfigurasi server sehingga patut dipertimbangkan, daripada menyatakan secara salah bahwa sistem tidak membedakan antara huruf besar dan kecil.
jleach

@ jdl134679 selesai.
TZHX

4

Untuk situs web internal, itu tidak masalah selama Anda konsisten dengannya.

Untuk situs eksternal, yang menghadap publik, Anda mungkin ingin tetap menggunakan huruf kecil yang kurang lebih merupakan standar dalam hosting web Linux / Apache. Seingat saya, beberapa versi Firefox juga tampaknya menangani casing URL berbeda dari IE. Ini juga berlaku untuk Chrome.

Memiliki casing yang konsisten juga penting untuk optimasi mesin pencari. Anda tidak ingin Google melihat huruf kecil.aspx dan huruf kecil.aspx sebagai halaman berbeda dengan konten duplikat. Meskipun algoritme mereka mencoba untuk mencegah identitas yang salah ini, itu terjadi dari waktu ke waktu dan dapat menyebabkan halaman dihukum.


2

Selama pengguna dapat mengetiknya sesuka mereka, itu benar-benar tidak masalah. Secara pribadi, saya lebih suka TitleCase, tetapi ada banyak yang tidak setuju. Jika Anda konsisten, tidak ada yang keberatan.

Jika server web Anda tidak dapat, karena alasan tertentu, menunjukkan kepada saya http://foo.com/HelloWorldketika saya mencoba untuk pergi http://foo.com/helloworld, Anda harus memilih untuk huruf kecil semua. Sementara orang jarang mengetik URL lengkap hari ini, alamat yang menghadap ke depan harus dapat diakses tanpa harus bermain-main dengan huruf besar.


2

Bahwa Anda mulai menggunakan MVC seharusnya tidak "bocor" ke abstraksi REST Anda. Ada alasan bagus untuk menggunakan semua URL huruf kecil dengan tanda hubung di antara kata-kata. URI (bukan nama domain) ADALAH case-sensitive. Jika Anda mengecilkan semuanya dan menggunakan tanda hubung untuk memisahkan kata-kata, Anda telah menghilangkan banyak tebakan dan satu kali saja, dan jika Anda menggunakan server proxy (nginx, nodejs, apache ...), Anda tidak akan memiliki segalanya mulai rusak karena tiba-tiba peka huruf besar-kecil.

"MiXeD-CaSe NaMeS. Jangan membingungkan pengguna Anda dengan-Campur-huruf-besar-dan-huruf-kecil-Karakter-dalam-URL. Tetaplah menggunakan huruf kecil, dan jangan membuat mereka menebak. Jika pengguna Anda sebenarnya mengetikkan URL dalam case campuran, menormalkannya di server dan melayani case yang sesuai ".


1

Meskipun TLD tidak peka huruf besar kecil dan jalur Windows menggunakan kombinasi huruf besar dan kecil, aplikasi kami peka terhadap jalur permintaan masuk, di mana jalur, atau komponen di dalamnya, biasanya dinormalisasi ke kasus standar, karena /format/JSON/dan /format/json/permintaan untuk dua format yang berbeda dan referensi dua sumber daya yang berbeda.

Setiap kali saya melihat http://www.somewebsite.com/Having/URLs/That-Look-Something-Like-This/ , saya merasa seperti niat pengembang terutama untuk tampil sedikit berbeda dari yang lain, tapi bukan apa-apa berinovasi dan tidak membantu meningkatkan keterbacaan, terutama sekarang karena Anda memiliki I dan l , O dan 0 , huruf-huruf lain yang bersaing untuk analisis Anda.

Saya tidak mengetahui adanya konsensus, saya juga tidak percaya bahwa harus ada satu, karena sesuatu yang sederhana seperti memanfaatkan hanya bagian-bagian tertentu dari URL dapat memiliki dampak positif pada keterbacaan dan saya yakin seseorang, di suatu tempat sudah datang dengan ide-ide menarik ketika menerapkan kasus huruf ke URL.

Tapi, dilihat dari fakta bahwa sebagian besar server Web berjalan di Linux dan bahwa kami pengembang selalu berakhir dengan standarisasi data teks yang masuk karena inputnya peka huruf besar-kecil, saya berpegang teguh pada bagaimana hal itu dilakukan selama ini.


0

JANGAN PERNAH menggunakan case title untuk alasan kegunaan! Bayangkan berapa banyak waktu yang harus Anda habiskan dan klik untuk melakukan URL kasus yang berbeda di ponsel MOBILE Anda !


Meskipun di iPhone saya, case title membutuhkan lebih sedikit penekanan tombol daripada '-' atau '_'.
BradS

Smartphone modern, setidaknya ponsel Windows memungkinkan gesek dari tombol caps untuk mencapai ini dalam sekali gesekan
0fnt
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.