Hyphen, underscore или camelCase как разделитель слов в URI?

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

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

верблюжьего

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

дефис

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

Стандартная передовая практика для 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

Ответ 3

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

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

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

Ответ 4

В целом, это не будет иметь достаточного влияния, чтобы беспокоиться о нем, особенно потому, что это приложение для интрасети, а не общедоступное интернет-приложение. В частности, поскольку это интранет, 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 всегда являются проблемой, независимо от чувствительности к регистру, поэтому это ничем не отличается от всего одного случая.

Ответ 5

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

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

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

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