Дефис, подчеркивание или camelCase как разделитель слов в URI?

Question

Дефис, подчеркивание или camelCase как разделитель слов в URI?

233

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

Вот мои первоначальные мысли:

верблюжьего

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

дефис

более эстетично, чем другие альтернативы
по-видимому, широко используется в части пути URI
никогда не видел строки строки с переносимой строкой запроса в дикой природе.
возможно, лучше для SEO (это может быть мифом)

Подчеркивание

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

Я склоняюсь к тому, чтобы подчеркнуть все. Тот факт, что большинство крупных игроков использует их, является убедительным (см. https://stackoverflow.com/a/608458/360570).

Joshua Johnson 24 апр. 2012, в 15:53

Источник

0

Из всего, что я прочитал, вы должны использовать дефисы , но подчеркивания кажутся более простыми в управлении.
ServAce85 08 июнь 2012, в 23:42
2

@ ServAce85 Почему?
Josh Johnson 25 июнь 2012, в 15:08
1

Я считаю, что дефисы когда-то были лучше для целей SEO. Сейчас это может быть не так, но так много людей приняли его, что это более широко признается как лучшая практика. С другой стороны, подчеркивания могут быть более легкими в программировании бэкэнда. Я использую PHP, поэтому гораздо проще использовать подчеркивание для имени функции, чем дефис. camelCase может быть проще всего реализовать, но читать его часто сложно. Наконец, я думаю, что вы были правы, когда сказали, что никогда не видите hyphenated query string in the wild с hyphenated query string in the wild . Обычно это время для CamelCase.
ServAce85 25 июнь 2012, в 16:30
0

В соответствии с этим вопросом подчеркивание не является допустимым вариантом: stackoverflow.com/questions/3641722/…
wytten 11 янв. 2013, в 19:35
2

Возможные дубликаты Существуют ли какие-либо рекомендации по соглашениям об именах для API REST?
Aurora0001 10 июнь 2017, в 17:41
0

Вы упомянули популярные API, я хотел бы добавить один: Google. Насколько я видел, Google вообще ничего не использует между словами (см., Например, API Google Maps Matrix API).
nbeuchat 06 нояб. 2017, в 02:05

Показать ещё 4 комментария

Теги:

rest

url

api

restful-url

uri

5 ответов

89

Стандартная передовая практика для API REST состоит в том, чтобы иметь дефис, а не на верблюжьем или подчеркивании.

Это происходит от Марка Массе "REST API Design Rulebook" от Oreilly.

Кроме того, обратите внимание, что сам переполнение стека использует дефисы в 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-actually

Al Sweigart 26 авг. 2013, в 19:29

3

Если вы посмотрите главу о рекомендациях для строки запроса в REST API Design Rulebook, вы заметите, что рекомендации различаются в зависимости от части правила. Там нет явного правила о вхождении в строки запроса, но вы обнаружите, что все примеры в разделе о строках запроса, что все ключи в случае верблюда.
Michael Lang 28 июль 2015, в 19:37

19

Пока я рекомендую дефисы, я также постулирую ответ, который отсутствует в вашем списке:

Ничего вообще

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

Nicholas Shanks 03 дек. 2012, в 17:42

4

Случайный избиратель: Не хочешь объяснить, что плохого в этом ответе? Я улучшу, где смогу, или вы просто проголосовали против, потому что вы не согласны с этим?
Nicholas Shanks 27 авг. 2013, в 09:09
0

+1 за указание на очевидный выбор. Он также устраняет неоднозначность / quotationrequests / from / quotation / запросы /.
Josh Petitt 04 сен. 2013, в 05:24
24

Что плохо в этом ответе, так это то, что с точки зрения SEO у машины нет возможности понять, где заканчивается одно слово, а где начинается другое, поэтому эта информация теряется. Это также трудно для читателей. Лучше иметь несколько разделителей на уровне слов, чем ничего.
Al Sweigart 28 май 2015, в 20:46
3

@ AlSweigart SEO не имеет значения, так как это приложение для внутренней сети за стеной входа в систему.
Nicholas Shanks 29 май 2015, в 12:17
2

Я согласен с @ niel-mcguigan, что, несмотря на то, что это приложение для интрасети, если вы везде используете дефисы, это одна вещь, которую нужно помнить.
Drew Goodwin 17 июнь 2016, в 20:40
1

@DrewGoodwin Достаточно справедливо. Хотя обратите внимание, что я сказал «постулат», а не «рекомендовать» :-) И домены обычно не содержат дефисов, поэтому использование их в путях - это еще одна вещь, которую нужно запомнить.
Nicholas Shanks 21 дек. 2016, в 15:07
0

Насколько я видел, Google использует это решение в своих API (посмотрите, например, Google Maps API)
nbeuchat 06 нояб. 2017, в 02:06

Показать ещё 5 комментариев

12

В целом, это не будет иметь достаточного влияния, чтобы беспокоиться о нем, особенно потому, что это приложение для интрасети, а не общедоступное интернет-приложение. В частности, поскольку это интранет, SEO не вызывает беспокойства, поскольку ваша интрасеть не должна быть доступна поисковым системам. (и если это так, это не приложение для интрасети).

И любая инфраструктура, заслуживающая внимания, либо уже имеет способ по умолчанию, либо довольно легко изменить, как она работает с многоязычными компонентами URL, поэтому я бы не стал слишком беспокоиться об этом.

Итак, вот как я вижу различные варианты:

Hyphen

Самая большая опасность для дефиса заключается в том, что один и тот же символ (обычно) также используется для вычитания и численного отрицания (т.е. минус или отрицательный).
Дефисы чувствуют себя неудобно в компонентах URL. Кажется, что они только имеют смысл в конце URL-адреса для разделения слов в заголовке статьи. Или, например, заголовок вопроса о переполнении стека, который добавляется в конец URL-адреса для SEO и целей пользовательской ясности.

Подчеркивание

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

CamelCase

На сегодняшний день мой любимый, поскольку он делает URL-адреса, кажется, более эффективными и не имеет никаких ошибок, которые выполняются двумя предыдущими.
Может быть немного сложнее прочитать для людей, которые имеют трудное время, отличая верхний регистр от нижнего регистра, но это не должно быть большой проблемой в URL-адресе, потому что большинство "слов" должны быть компонентами URL и разделены по a / в любом случае. Если вы обнаружите, что у вас есть компонент URL, длина которого превышает 2 слова, вам следует, вероятно, попытаться найти лучшее название для этой концепции.
У него есть возможная проблема с чувствительностью к регистру, но большинство платформ можно настроить так, чтобы они были чувствительны к регистру или не учитывали регистр. Любое это только на самом деле проблема для 2-х случаев: a) люди, набравшие URL-адрес, и b) программисты (поскольку мы не являемся людьми), набрав URL-адрес. Typos всегда являются проблемой, независимо от чувствительности к регистру, поэтому это ничем не отличается от всего одного случая.

cdeszaq 31 окт. 2012, в 14:18

10

Не согласен. Посмотрите на SO, посмотрите все WordPress сайты, посмотрите на большинство новостных сайтов, все они используют дефисы. Также верблюжьи кейсы сочетаются с кейсами, на мой взгляд веб должен быть все строчными.
Fabien Warniez 11 май 2015, в 22:22
3

На мой взгляд, сеть должна быть без учета регистра, на самом деле. Что касается соглашения, если вы будете следовать подходу маршрутов RoR (ruby on rails), вы должны использовать подчеркивание. Обычно я делаю так, чтобы это было единообразно в зависимости от маршрутов, созданных рельсами, и моих названных маршрутов. Тем не менее, я считаю, что для меня тире читать лучше, чем подчеркивание.
rpbaltazar 24 сен. 2015, в 13:05
1

Возможно, у них есть внутренняя поисковая система в их интранете?
Juha Untinen 04 апр. 2016, в 05:50
3

Не согласен. Оба ваших аргумента против дефисов ошибочны. Нет никакой опасности в отрицании или вычитании, потому что здесь мы говорим об именной части кортежа, вы никогда не должны функционировать или оценивать именную часть кортежа на предмет математики или отрицания. Также нет ничего неловкого в использовании дефисов в URI, так как это давняя лучшая практика, используемая нехваткой устоявшихся сайтов. Они также не требуют нажатия клавиши Shift и воспринимаются как границы слов практически всеми.
tpartee 03 фев. 2017, в 01:05
2

Насколько я помню, дефисы были широко используемой нормой в URL и определенно считаются лучшей практикой в современных стандартах. Не использовать их, потому что чувство неловкости кажется мне неловким.
pistol-pete 03 март 2017, в 18:20

Показать ещё 3 комментария

2

здесь лучшее из обоих миров.

Я также "как" подчеркиваю, помимо всех ваших положительных моментов о них, есть и стиль старой школы.

Итак, я использую символы подчеркивания и просто добавляю небольшое правило перезаписи в ваш файл Apache.htaccess, чтобы переписать все символы подчеркивания в дефисы.

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

user2597538 09 июнь 2015, в 23:52

Ещё вопросы

Из всего, что я прочитал, вы должны использовать дефисы , но подчеркивания кажутся более простыми в управлении.
Я считаю, что дефисы когда-то были лучше для целей SEO. Сейчас это может быть не так, но так много людей приняли его, что это более широко признается как лучшая практика. С другой стороны, подчеркивания могут быть более легкими в программировании бэкэнда. Я использую PHP, поэтому гораздо проще использовать подчеркивание для имени функции, чем дефис. camelCase может быть проще всего реализовать, но читать его часто сложно. Наконец, я думаю, что вы были правы, когда сказали, что никогда не видите hyphenated query string in the wild с hyphenated query string in the wild . Обычно это время для CamelCase.
В соответствии с этим вопросом подчеркивание не является допустимым вариантом: stackoverflow.com/questions/3641722/…
Возможные дубликаты Существуют ли какие-либо рекомендации по соглашениям об именах для API REST?
Вы упомянули популярные API, я хотел бы добавить один: Google. Насколько я видел, Google вообще ничего не использует между словами (см., Например, API Google Maps Matrix API).
Если вы посмотрите главу о рекомендациях для строки запроса в REST API Design Rulebook, вы заметите, что рекомендации различаются в зависимости от части правила. Там нет явного правила о вхождении в строки запроса, но вы обнаружите, что все примеры в разделе о строках запроса, что все ключи в случае верблюда.
Случайный избиратель: Не хочешь объяснить, что плохого в этом ответе? Я улучшу, где смогу, или вы просто проголосовали против, потому что вы не согласны с этим?
+1 за указание на очевидный выбор. Он также устраняет неоднозначность / quotationrequests / from / quotation / запросы /.
Что плохо в этом ответе, так это то, что с точки зрения SEO у машины нет возможности понять, где заканчивается одно слово, а где начинается другое, поэтому эта информация теряется. Это также трудно для читателей. Лучше иметь несколько разделителей на уровне слов, чем ничего.
@ AlSweigart SEO не имеет значения, так как это приложение для внутренней сети за стеной входа в систему.
Я согласен с @ niel-mcguigan, что, несмотря на то, что это приложение для интрасети, если вы везде используете дефисы, это одна вещь, которую нужно помнить.
@DrewGoodwin Достаточно справедливо. Хотя обратите внимание, что я сказал «постулат», а не «рекомендовать» :-) И домены обычно не содержат дефисов, поэтому использование их в путях - это еще одна вещь, которую нужно запомнить.
Насколько я видел, Google использует это решение в своих API (посмотрите, например, Google Maps API)
Не согласен. Посмотрите на SO, посмотрите все WordPress сайты, посмотрите на большинство новостных сайтов, все они используют дефисы. Также верблюжьи кейсы сочетаются с кейсами, на мой взгляд веб должен быть все строчными.
На мой взгляд, сеть должна быть без учета регистра, на самом деле. Что касается соглашения, если вы будете следовать подходу маршрутов RoR (ruby on rails), вы должны использовать подчеркивание. Обычно я делаю так, чтобы это было единообразно в зависимости от маршрутов, созданных рельсами, и моих названных маршрутов. Тем не менее, я считаю, что для меня тире читать лучше, чем подчеркивание.
Возможно, у них есть внутренняя поисковая система в их интранете?
Не согласен. Оба ваших аргумента против дефисов ошибочны. Нет никакой опасности в отрицании или вычитании, потому что здесь мы говорим об именной части кортежа, вы никогда не должны функционировать или оценивать именную часть кортежа на предмет математики или отрицания. Также нет ничего неловкого в использовании дефисов в URI, так как это давняя лучшая практика, используемая нехваткой устоявшихся сайтов. Они также не требуют нажатия клавиши Shift и воспринимаются как границы слов практически всеми.
Насколько я помню, дефисы были широко используемой нормой в URL и определенно считаются лучшей практикой в современных стандартах. Не использовать их, потому что чувство неловкости кажется мне неловким.

Neil McGuigan · Accepted Answer · 2013-08-26T19-41-00.000Z

Вы должны использовать дефисы в URL-адресе сканируемого веб-приложения. Зачем? Поскольку дефис разделяет слова (так что поисковая система может индексировать отдельные слова) и не является символом . Подчеркивание - это символ слова, то есть его следует считать частью слова.

Дважды щелкните его в Chrome: camelCase
Дважды щелкните это в Chrome: under_score
Дважды щелкните его в Chrome: дефенд

Посмотрите, как Chrome (я слышал, что Google делает поисковую систему тоже) думает только одно из двух слов:

camelCase и underscore также требуют, чтобы пользователь использовал клавишу shift, а hyphenated - нет.

Итак, если вы должны использовать дефисы в сканируемом веб-приложении, почему бы вам не потрудиться сделать что-то другое в приложении для интрасети? Еще одна вещь, которую нужно запомнить.

Мой Firefox 24 в Windows 7 думает, что «дефис» - это два слова.
и он ведет себя так же для 'under_score'.
любое соглашение для queryString, например ?event_id=1 или ?eventId=1 ???
@ user2727195 Несмотря на то, что URL-адреса чувствительны к регистру, рекомендуется использовать строчные буквы везде, где это возможно, поскольку это исключает возможность опечатки.
@ user2727195 также я бы выбрал термин id из имени параметра и просто event=1
Некоторые слова могут быть написаны через дефис (на английском языке): grammarbook.com/punctuation/hyphens.asp Не лучше ли подчеркнуть в этом отношении?