Дефіс, підкреслення або camelCase як розділювач слів у URI?

475

Я розробляю API на основі HTTP для програми інтранет. Я усвідомлюю, що це велика проблема в грандіозній схемі речей, але: чи слід використовувати дефіси, підкреслення або camelCase для розмежування слів у URI?

Ось мої початкові думки:

camelCase

можливі проблеми, якщо сервер нечутливий до регістру
Схоже, має досить широке використання в рядкових клавішах запиту ( http://api.example.com ? searchQuery = ...), але не в інших частинах URI

Дефіс

естетичніше, ніж інші альтернативи
Схоже, широко використовується в частині шляху URI
ніколи не бачив дефісних ключів рядка запиту в дикій природі
можливо краще для SEO (це може бути міфом)

Підкреслення

потенційно простіше в роботі з мовами програмування
кілька популярних API (Facebook, Netflix, StackExchange тощо) використовують підкреслення у всіх частинах URI.

Я схиляюся до підкреслень для всього. Те, що більшість великих гравців використовує їх, є переконливим (див. Https://stackoverflow.com/a/608458/360570 ).

— Джош Джонсон
джерело

З усього, що я прочитав, ви повинні використовувати дефіси , але підкреслення здається більш простим в управлінні.

— ServAce85

1

Я вважаю, що дефіси були свого часу кращими для цілей SEO. Зараз це може бути неправдою, але так багато людей прийняли це, що його більш широко прийнято вважати найкращою практикою. З іншого боку, підкреслення може бути простішим для вирішення в програмі бекенда. Я використовую PHP, тому набагато простіше використовувати підкреслення для назви функції, ніж дефіс. camelCase може бути найпростішим у виконанні, але читати його часто буває складно. Нарешті, я думаю, ви мали рацію, коли сказали, що ніколи не бачите hyphenated query string in the wild. Це, як правило, час для camelCase.

— ServAce85

З цього питання, підкреслення не є допустимим варіантом: stackoverflow.com/questions/3641722 / ...

— wytten

2

Можливий дублікат Чи існують якісь рекомендації щодо встановлення імен для API REST?

— Aurora0001

Ви згадуєте популярні API, я хотів би додати: Google. Наскільки я бачив, Google взагалі нічого не використовує між словами (ознайомтеся, наприклад, з API Матриці відстані мапи Google).

— nbeuchat

472

Ви повинні використовувати дефіси в URL-адресі веб-програми, яку можна сканувати. Чому? Тому що дефіс розділяє слова (так що пошукова система може індексувати окремі слова), а не є символом слова . Підкреслення є символом слова, тобто його слід вважати частиною слова.

Двічі клацніть на цьому в Chrome: camelCase
Двічі клацніть на цьому в Chrome: under_score
Двічі клацніть на цьому в Chrome: дефіс

Подивіться, як Chrome (я чую, Google теж робить пошукову систему) думає, що одне з них - це два слова?

camelCaseа underscoreтакож вимагають від користувача використання shiftключа, тоді як hyphenatedцього немає.

Отже, якщо вам слід використовувати дефіси у веб-програмі, яку можна сканувати, чому б ви не турбувались робити щось інше в інтранетній програмі? Одна менша річ, яку потрібно пам’ятати.

— Ніл МакГуйган
джерело

20

Мій Firefox 24 у Windows 7 вважає, що "дефіс" - це два слова.

— Marcel Stör

9

і він поводиться так само для "under_score".

— Marcel Stör

18

будь-яка умова для queryString, наприклад, ?event_id=1або ?eventId=1???

— користувач2727195

8

@ user2727195 Хоча URL-адреси залежать від регістру, найкращою практикою є використання малих регістрів, де це можливо, оскільки це виключає можливість внесення помилок.

— Ніколас Шенкс

7

Інтерактивна відповідь :)

— wild_nothing

210

Стандартна найкраща практика для API REST - мати дефіс , а не верблюд чи підкреслення.

Це відбувається з "Правила дизайну API REST API" від Oreilly.

Окрім того, зауважте, що Stack Overflow сам використовує дефіси в URL: .../hyphen-underscore-or-camelcase-as-word-delimiter-in-uris

Як це робить WordPress: http://inventwithpython.com/blog/2012/03/18/how-much-math-do-i-need-to-know-to-program-not-that-much-actically

— Al Sweigart
джерело

3

Якщо ви подивитесь на розділ щодо настановних рядків запитів у Правилі проектування REST API, ви помітите, що вказівки змінюються залежно від частини правила. Немає явного правила щодо корпусу в рядках запитів, але ви знайдете, що всі приклади в розділі про рядки запитів про те, що всі клавіші знаходяться в корпусі верблюда.

— Майкл Ланг

1

Тільки FYI - "Правило дизайну API проекту REST" було опубліковано в жовтні 2011 року. Можливо, за останні 8 років все змінилося.

— ChrisN

25

Хоча я рекомендую дефіси, я також постулюю на відповідь, яка відсутня у вашому списку:

Нічого взагалі

API моєї компанії є URI , як /quotationrequests/, /purchaseorders/і так далі.
Незважаючи на те, що ви сказали, що це інтранет-додаток, ви перерахували SEO як перевагу. Google відповідає шаблону / foobar / у URL-адресі для запиту?q=foo+bar
Я дуже сподіваюся, що ви не розглядаєте можливість здійснення PHP-дзвінка до будь-якої довільної рядки, яку користувач передає в адресний рядок, як пропонує @ ServAce85!

— Ніколас Шенкс
джерело

+1, щоб вказати на очевидний вибір. Він також розмежовує / запрошення пропозицій / з / котирування / запити /.

— Джош Петтіт

33

Що погано в цій відповіді, це те, що з точки зору SEO, машина не може зрозуміти, де закінчується одне слово, а інше починається, тому ця інформація втрачається. Людям читачам теж важко. Краще мати кілька розділювачів рівня слів, ніж нічого.

— Al Sweigart

3

@AlSweigart SEO не доречний, оскільки це інтранет-додаток за стіною входу.

— Ніколас Шенкс

2

Я погоджуюся з @ niel-mcguigan, що навіть якщо це інтранет-додаток, якщо ви користуєтесь дефісами скрізь, це потрібно пам’ятати одне менше.

— Дрю Гудвін

2

@DrewGoodwin Ярмарок досить. Хоча зауважте, що я сказав "постулат" не "рекомендую" :-) І домени зазвичай не мають дефісів у них, тому використання їх у шляхах - це ще одне, що слід пам’ятати.

— Ніколас Шенкс

18

Взагалі, це не матиме достатнього впливу для того, щоб турбуватись, тим більше, що це інтранет- додаток, а не загальнодоступний Інтернет-додаток. Зокрема, оскільки це інтранет , SEO не викликає особливих проблем, оскільки ваша інтранета не повинна бути доступною для пошукових систем. (і якщо це так, це не інтранет-додаток).

І будь-яка основа, яка стоїть за цією сіллю, або вже має за замовчуванням спосіб це зробити, або досить легко змінити спосіб роботи з компонентами URL-адрес з декількома словами, тому я б не переживав про це занадто.

Це означає, що я бачу різні варіанти:

Дефіс

Найбільша небезпека для дефісів полягає в тому, що той самий символ (як правило) використовується також для віднімання і числового заперечення (тобто мінус або від’ємник ).
Дефіси почуваються ніяково в компонентах URL. Здається, вони мають сенс лише в кінці URL-адреси для розділення слів у заголовку статті. Або, наприклад, заголовок питання про переповнення стека, який додається в кінці URL для цілей SEO та зрозумілості користувачів.

Підкреслення

Знову ж таки, вони неправильно входять до компонентів URL. Вони розбивають потік (і красу / простоту) URL-адреси, оскільки вони по суті додають великий, важкий уявний простір посеред чистої, поточної URL-адреси.
Вони, як правило, поєднуються з підкресленнями. Якщо ви очікуєте, що ваші користувачі скопіюють і вставлять ваші URL-адреси в MS Word або інші подібні програми для редагування тексту або в будь-яке інше місце, яке може відображатись за URL-адресою та стилювати його підкресленням (як, наприклад, традиційні посилання ), можливо, ви захочете уникайте підкреслення як розділювачів слів. Особливо під час друку підкреслена URL-адреса з підкресленнями має вигляд, ніби вона має пробіли замість підкреслених.

CamelCase

На сьогоднішній день мій улюблений, оскільки це робить, що URL-адреси здаються кращими та не мають жодних помилок, які мають попередні два варіанти.
Може бути трохи складніше для читання для людей , які мають важкий час дифференцирующего прописні від малих, але це не повинно бути великою проблемою , в URL, тому що більшість «слова» повинні бути компонентами URL і будуть розділені в /будь-якому випадку . Якщо ви виявите, що у вас є компонент URL, який має більше 2 "слів", вам, мабуть, слід спробувати знайти кращу назву для цієї концепції.
У нього можливі проблеми з чутливістю до регістру, але більшість платформ можуть бути налаштовані як на регістр, так і на чутливість регістру. У будь-якому випадку це справді проблема лише у 2 випадках: а) люди вводять URL-адресу, і б.) Програмісти (оскільки ми не людина) вводимо URL-адресу. Опечатки завжди є проблемою, незалежно від чутливості регістру, тому це нічим не відрізняється від усіх одного випадку.

— cdeszaq
джерело

13

Не згоден. Подивіться на SO, подивіться всі сайти wordpress, подивіться на більшість новинних сайтів, усі вони використовують дефіси. Крім того, справа з верблюдами поєднує випадки, на мою думку, в Інтернеті має бути все нижнє регістр.

— Fabien Warniez

4

На мою думку, Мережа фактично повинна бути нечутливою до регістру. Що стосується конвенції, якщо ви дотримуєтеся маршруту RoR (рубін на рейках), ви використовуєте підкреслення. Зазвичай я роблю це для того, щоб він відповідав маршрутам, що генеруються на рейках та моїх названих маршрутах. Тим не менш, я вважаю, що для мене тире читається краще, ніж підкреслення.

— rpbaltazar

1

Можливо, вони мають внутрішню пошукову систему у своїй інтрамережі?

— Juha Untinen

3

Не згоден. Обидва ваші аргументи проти дефісів є хибними. Немає небезпеки щодо заперечення чи віднімання, оскільки ми говоримо про назву частини кортежу, ви ніколи не повинні функціонувати та не оцінювати іменну частину кортежу для математики чи заперечення. Немає нічого незручного в використанні дефісів в URI, оскільки це давній кращий досвід, який використовується дефіцитом налагоджених сайтів. Вони також не вимагають натискання клавіші Shift і практично всі їх трактують як межі слів.

— tpartee

2

Наскільки я пам’ятаю, дефіси були найпоширенішою нормою в URL-адресах, і це, безумовно, вважається найкращою практикою в сучасних стандартах. Не використовувати їх, тому що почуття ніяково мені здається незручним.

— пістолет-піт

2

Коротка відповідь:

слова з нижньою буквою із дефісом як роздільник

Довга відповідь:

Яка мета URL-адреси?

Якщо вказівка на адресу - це відповідь, то скорочена URL-адреса також добре справляється. Якщо ми не полегшимо читання та підтримку, це не допоможе розробникам та інженерам. Вони представляють сутність на сервері, тому вони повинні бути логічно названі.

Подумайте про використання розділових знаків у своїх URL-адресах. URL-адреса http://www.example.com/green-dress.html нам набагато корисніша, ніж http://www.example.com/greendress.html . Ми рекомендуємо використовувати дефіси (-) замість підкреслення (_) у своїх URL-адресах.

Походячи з фону програмування, camelCase - популярний вибір для іменування спільних слів.

Але RFC 3986 визначає URL-адреси як регістрові для різних частин URL-адреси. Оскільки URL-адреси враховують великі регістри, зберігання його низької клавіші (нижній регістр) завжди безпечне і вважається хорошим стандартом. Тепер це виймає з вікна справу верблюда.

Джерело: https://metamug.com/article/rest-api-naming-best-practices.html#word-delimiters

— Сортувальник
джерело

-1

ось найкраще з обох світів.

Мені також "подобаються" підкреслення, окрім усіх ваших позитивних моментів щодо них, є і певний стиль старої школи.

Тож, що я роблю, це використовувати підкреслення і просто додати невелике правило перезапису у файл .htaccess у файл Apache, щоб переписати всі підкреслення на дефіси.

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

— користувач2597538
джерело