Tanda hubung, garis bawah, atau camelCase sebagai pembatas kata di URI?

477

Saya merancang API berbasis HTTP untuk aplikasi intranet. Saya menyadari ini adalah masalah yang cukup kecil dalam skema besar hal, tetapi: haruskah saya menggunakan tanda hubung, garis bawah, atau unta untuk membatasi kata dalam URI?

Inilah pemikiran awal saya:

camelCase

kemungkinan masalah jika server tidak peka huruf besar-kecil
tampaknya memiliki cukup banyak digunakan dalam kunci string kueri ( http://api.example.com ? searchQuery = ...), tetapi tidak di bagian URI lainnya

Tanda penghubung

lebih estetis daripada alternatif lainnya
tampaknya banyak digunakan di bagian jalur URI
tidak pernah melihat kunci string permintaan ditulis dgn tanda penghubung di alam liar
mungkin lebih baik untuk SEO (ini mungkin mitos)

Menggarisbawahi

berpotensi lebih mudah untuk menangani bahasa pemrograman
beberapa API populer (Facebook, Netflix, StackExchange, dll.) menggunakan garis bawah di semua bagian URI.

Saya condong ke bawah untuk semuanya. Fakta bahwa sebagian besar pemain besar menggunakannya sangat menarik (lihat https://stackoverflow.com/a/608458/360570 ).

— Josh Johnson
sumber

Dari semua yang saya baca, Anda harus menggunakan tanda hubung , tetapi garis bawah tampaknya lebih mudah dikelola.

— ServAce85

1

Saya percaya bahwa tanda hubung , pada suatu waktu, lebih baik untuk keperluan SEO. Ini mungkin tidak benar sekarang, tetapi begitu banyak orang telah mengadopsinya sehingga lebih diterima secara luas sebagai praktik terbaik. Garis bawah di sisi lain mungkin lebih mudah untuk menangani dalam pemrograman backend. Saya menggunakan PHP, jadi lebih mudah menggunakan garis bawah untuk nama fungsi daripada tanda hubung. camelCase mungkin yang paling mudah diterapkan, tetapi membacanya seringkali sulit. Akhirnya, saya pikir Anda benar ketika Anda mengatakan bahwa Anda tidak pernah melihat hyphenated query string in the wild. Itu biasanya waktu untuk camelCase.

— ServAce85

Menurut pertanyaan ini, garis bawah bukanlah opsi yang valid: stackoverflow.com/questions/3641722/…

— wytten

2

Kemungkinan duplikat dari Adakah panduan konvensi penamaan untuk REST APIs?

— Aurora0001

Anda menyebutkan API populer, saya ingin menambahkannya: Google. Sejauh yang saya lihat, Google tidak menggunakan apa pun di antara kata-kata (lihat API Google Maps Distance Matrix misalnya).

— nbeuchat

473

Anda harus menggunakan tanda hubung dalam URL aplikasi web yang dapat dijelajahi. Mengapa? Karena tanda hubung memisahkan kata-kata (sehingga mesin pencari dapat mengindeks kata-kata individual), dan bukan karakter kata . Garis bawah adalah karakter kata, artinya harus dianggap bagian dari kata.

Klik
dua kali ini di Chrome: camelCase Klik
dua kali ini di Chrome: under_score Klik dua kali ini di Chrome: hyphen-ated

Lihat bagaimana Chrome (saya mendengar Google membuat mesin pencari juga) hanya berpikir bahwa salah satunya adalah dua kata?

camelCasedan underscorejuga mengharuskan pengguna untuk menggunakan shiftkunci, sedangkan hyphenatedtidak.

Jadi jika Anda harus menggunakan tanda hubung dalam aplikasi web yang dapat dijelajahi, mengapa Anda repot-repot melakukan sesuatu yang berbeda dalam aplikasi intranet? Satu hal yang perlu diingat.

— Neil McGuigan
sumber

20

Firefox 24 saya di Windows 7 menganggap 'tanda hubung' adalah dua kata.

— Marcel Stör

9

dan itu berlaku sama untuk 'under_score'.

— Marcel Stör

18

konvensi apa pun untuk kueriString, misalnya ?event_id=1atau ?eventId=1???

— user2727195

8

@ user2727195 Meskipun URL peka huruf besar-kecil, praktik terbaik adalah menggunakan huruf kecil sedapat mungkin, karena menghilangkan kemungkinan kesalahan ketik.

— Nicholas Shanks

7

Jawaban interaktif :)

— wild_nothing

210

Praktik terbaik standar untuk REST API adalah memiliki tanda hubung , bukan unta atau garis bawah.

Ini berasal dari "REST API Design Rulebook" Mark Masse dari Oreilly.

Selain itu, perhatikan bahwa Stack Overflow sendiri menggunakan tanda hubung di URL: .../hyphen-underscore-or-camelcase-as-word-delimiter-in-uris

Seperti halnya WordPress: http://inventwithpython.com/blog/2012/03/18/how-much-math-do-i-need-to-know-to-program-not-that-much-actually

— Al Sweigart
sumber

3

Jika Anda melihat bab tentang pedoman string kueri di Rulebook Desain REST API, Anda akan melihat pedoman bervariasi sesuai dengan bagian aturan. Tidak ada aturan eksplisit tentang casing dalam string kueri, tetapi Anda akan menemukan bahwa semua contoh di bagian string kueri bahwa semua kunci ada dalam case unta.

— Michael Lang

1

Just FYI - "REST API Design Rulebook" diterbitkan pada Oktober 2011. Kemungkinan hal-hal telah berubah dalam 8 tahun terakhir.

— ChrisN

25

Sementara saya merekomendasikan tanda hubung, saya juga akan mendalilkan jawaban yang tidak ada dalam daftar Anda:

Tidak ada sama sekali

API perusahaan saya memiliki URI seperti /quotationrequests/,/purchaseorders/ dan sebagainya.
Meskipun Anda mengatakan itu adalah aplikasi intranet, Anda mencantumkan SEO sebagai manfaat. Google tidak cocok dengan pola / foobar / di URL untuk kueri?q=foo+bar
Saya benar-benar berharap Anda tidak mempertimbangkan mengeksekusi panggilan PHP ke string sembarang yang dilewati pengguna ke bilah alamat, seperti yang disarankan oleh @ ServAce85!

— Nicholas Shanks
sumber

+1 untuk menunjukkan pilihan yang jelas. Itu juga disambiguates / quotationrequests / dari / kutipan / permintaan /.

— Josh Petitt

34

Apa yang buruk tentang respons ini adalah bahwa, dari perspektif SEO, tidak ada cara bagi mesin untuk memahami di mana satu kata berakhir dan yang lain dimulai, sehingga informasi ini hilang. Ini juga sulit bagi pembaca manusia. Lebih baik memiliki beberapa pemisah tingkat kata daripada tidak sama sekali.

— Al Sweigart

3

@AlSweigart SEO tidak relevan karena ini adalah aplikasi intranet di balik dinding masuk.

— Nicholas Shanks

2

Saya setuju dengan @ niel-mcguigan bahwa meskipun ini adalah aplikasi intranet, jika Anda menggunakan tanda hubung di mana-mana itu adalah satu hal yang kurang untuk diingat.

— Drew Goodwin

2

@DrewGoodwin Cukup adil. Meskipun perlu dicatat bahwa saya mengatakan "postulat" tidak "merekomendasikan" :-) Dan domain biasanya tidak memiliki tanda hubung di dalamnya, jadi menggunakannya di jalur sudah satu hal lagi yang perlu diingat.

— Nicholas Shanks

18

Secara umum, itu tidak akan memiliki dampak yang cukup untuk dikhawatirkan, terutama karena ini adalah aplikasi intranet dan bukan aplikasi Internet yang umum digunakan. Khususnya, karena itu intranet , SEO bukan masalah, karena intranet Anda tidak dapat diakses oleh mesin pencari. (dan jika ya, itu bukan aplikasi intranet).

Dan kerangka kerja apa pun yang layak untuknya sudah memiliki cara standar untuk melakukan ini, atau cukup mudah untuk mengubah cara menangani komponen URL multi-kata, jadi saya tidak akan terlalu khawatir tentang hal itu.

Yang mengatakan, inilah cara saya melihat berbagai opsi:

Tanda penghubung

Bahaya terbesar untuk tanda hubung adalah bahwa karakter yang sama (biasanya) juga digunakan untuk pengurangan dan negasi numerik (mis. Minus atau negatif ).
Tanda hubung terasa canggung dalam komponen URL. Tampaknya hanya masuk akal di akhir URL untuk memisahkan kata dalam judul artikel. Atau, misalnya, judul pertanyaan Stack Overflow yang ditambahkan ke akhir URL untuk keperluan SEO dan kejelasan pengguna.

Menggarisbawahi

Sekali lagi, mereka merasa salah dalam komponen URL. Mereka memecah aliran (dan keindahan / kesederhanaan) dari sebuah URL, karena mereka pada dasarnya menambahkan ruang besar yang tampak jelas di tengah-tengah URL yang bersih dan mengalir.
Mereka cenderung berbaur dengan garis bawah. Jika Anda berharap pengguna Anda untuk copy-paste URL Anda ke MS Word atau program text-editing serupa lainnya, atau di mana pun yang mungkin menangkap URL dan gaya dengan garis bawah (seperti link tradisional yang), maka Anda mungkin ingin hindari garis bawah sebagai pemisah kata. Khususnya ketika dicetak, URL yang digarisbawahi dengan garis bawah cenderung terlihat seperti memiliki spasi di dalamnya, bukan garis bawah.

CamelCase

Sejauh ini favorit saya, karena membuat URL tampak mengalir lebih baik dan tidak memiliki kesalahan seperti yang dilakukan dua opsi sebelumnya.
Dapat sedikit sulit untuk dibaca bagi orang-orang yang memiliki waktu sulit membedakan huruf besar dari huruf kecil, tapi ini tidak boleh banyak masalah di URL, karena kebanyakan "kata" harus komponen URL dan dipisahkan oleh /lagian . Jika Anda menemukan bahwa Anda memiliki komponen URL yang panjangnya lebih dari 2 "kata", Anda mungkin harus mencoba menemukan nama yang lebih baik untuk konsep itu.
Itu memang memiliki masalah yang mungkin dengan sensitivitas kasus, tetapi sebagian besar platform dapat disesuaikan menjadi case-sensitive atau case-sensitive. Apa pun itu hanya benar - benar masalah untuk 2 kasus: a.) Manusia mengetik URL, dan b.) Programer (karena kita bukan manusia) mengetik URL. Typo selalu menjadi masalah, terlepas dari sensitivitas kasus, jadi ini adalah tidak berbeda dengan semua satu case.

— cdeszaq
sumber

13

Tidak setuju. Lihatlah SO, lihat semua situs wordpress, lihat sebagian besar situs berita, semuanya menggunakan tanda hubung. Juga unta kasus campuran, web harus semua huruf kecil menurut pendapat saya.

— Fabien Warniez

4

Menurut pendapat saya, sebenarnya web seharusnya tidak peka huruf besar-kecil. Mengenai konvensi, jika Anda mengikuti pendekatan rute RoR (ruby on rails), Anda akan menggunakan garis bawah. Biasanya, saya melakukannya untuk tetap konsisten melintasi rel yang dihasilkan rute dan rute bernama saya. Namun demikian, saya rasa bagi saya untuk membaca lebih baik daripada menggarisbawahi.

— rpbaltazar

1

Mungkin mereka memiliki mesin pencari internal di intranet mereka?

— Juha Untinen

3

Tidak setuju. Kedua argumen Anda terhadap tanda hubung cacat. Tidak ada bahaya tentang negasi atau pengurangan karena kita berbicara tentang porsi nama tuple di sini, Anda seharusnya tidak pernah berfungsi atau mengevaluasi bagian nama tupel untuk matematika atau negasi. Juga tidak ada canggung tentang menggunakan tanda hubung dalam URI karena ini adalah praktik terbaik yang telah lama digunakan oleh kelangkaan situs yang sudah mapan. Mereka juga tidak perlu menekan tombol Shift dan diperlakukan sebagai batas kata oleh hampir semua orang.

— tpartee

2

Sejauh yang saya ingat, tanda hubung telah menjadi norma yang sering digunakan dalam URL, dan jelas dianggap praktik terbaik dalam standar saat ini. Tidak menggunakan mereka karena merasa canggung tampaknya aneh bagi saya.

— pistol-pete

2

Jawaban singkat:

kata-kata berhuruf rendah dengan tanda hubung sebagai pemisah

Jawaban panjang:

Apa tujuan dari URL?

Jika menunjuk ke alamat adalah jawabannya, maka URL yang disingkat juga melakukan pekerjaan dengan baik. Jika kami tidak membuatnya mudah dibaca dan dikelola, itu tidak akan membantu pengembang dan pengelola. Mereka mewakili suatu entitas di server, sehingga mereka harus diberi nama secara logis.

Google merekomendasikan penggunaan tanda hubung

Pertimbangkan menggunakan tanda baca di URL Anda. URL http://www.example.com/green-dress.html jauh lebih bermanfaat bagi kami daripada http://www.example.com/greendress.html . Kami menyarankan Anda menggunakan tanda hubung (-) alih-alih menggarisbawahi (_) di URL Anda.

Berasal dari latar belakang pemrograman, camelCase adalah pilihan populer untuk menamai kata-kata bersama.

Tetapi RFC 3986 mendefinisikan URL sebagai case-sensitive untuk berbagai bagian URL. Karena URL peka huruf besar-kecil, menjaganya agar tetap rendah (selalu lebih rendah) selalu aman dan dianggap sebagai standar yang baik. Sekarang membawa keluar unta keluar dari jendela.

Sumber: https://metamug.com/article/rest-api-naming-best-practices.html#word-delimiters

— Tukang sortir
sumber

-1

inilah yang terbaik dari kedua dunia.

Saya juga "suka" menggarisbawahi, di samping semua poin positif Anda tentang mereka, ada juga gaya sekolah lama bagi mereka.

Jadi yang saya lakukan adalah menggunakan garis bawah dan cukup tambahkan aturan penulisan ulang kecil ke file .htaccess Apache Anda untuk menulis ulang semua garis bawah menjadi tanda hubung.

https://yoast.com/apache-rewrite-dash-underscore/

— pengguna2597538
sumber