Я разрабатываю API на основе HTTP для приложения интрасети. Я понимаю, что это довольно маленькая проблема в великой схеме вещей, но: использовать ли дефисы, подчеркивания или camelCase для разграничения слов в URI?
Вот мои первоначальные мысли:
верблюжьего
дефис
Подчеркивание
Я склоняюсь к тому, чтобы подчеркнуть все. Тот факт, что большинство крупных игроков использует их, является убедительным (см. https://stackoverflow.com/a/608458/360570).
Вы должны использовать дефисы в URL-адресе сканируемого веб-приложения. Зачем? Поскольку дефис разделяет слова (так что поисковая система может индексировать отдельные слова) и не является символом . Подчеркивание - это символ слова, то есть его следует считать частью слова.
Дважды щелкните его в Chrome: camelCase
Дважды щелкните это в Chrome: under_score
Дважды щелкните его в Chrome: дефенд
Посмотрите, как Chrome (я слышал, что Google делает поисковую систему тоже) думает только одно из двух слов:
camelCase
и underscore
также требуют, чтобы пользователь использовал клавишу shift, а hyphenated
- нет.
Итак, если вы должны использовать дефисы в сканируемом веб-приложении, почему бы вам не потрудиться сделать что-то другое в приложении для интрасети? Еще одна вещь, которую нужно запомнить.
Стандартная передовая практика для 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
Пока я рекомендую дефисы, я также постулирую ответ, который отсутствует в вашем списке:
Ничего вообще
/quotationrequests/
, /purchaseorders/
и т.д.?q=foo+bar
В целом, это не будет иметь достаточного влияния, чтобы беспокоиться о нем, особенно потому, что это приложение для интрасети, а не общедоступное интернет-приложение. В частности, поскольку это интранет, SEO не вызывает беспокойства, поскольку ваша интрасеть не должна быть доступна поисковым системам. (и если это так, это не приложение для интрасети).
И любая инфраструктура, заслуживающая внимания, либо уже имеет способ по умолчанию, либо довольно легко изменить, как она работает с многоязычными компонентами URL, поэтому я бы не стал слишком беспокоиться об этом.
Итак, вот как я вижу различные варианты:
Hyphen
Подчеркивание
CamelCase
/
в любом случае. Если вы обнаружите, что у вас есть компонент URL, длина которого превышает 2 слова, вам следует, вероятно, попытаться найти лучшее название для этой концепции.здесь лучшее из обоих миров.
Я также "как" подчеркиваю, помимо всех ваших положительных моментов о них, есть и стиль старой школы.
Итак, я использую символы подчеркивания и просто добавляю небольшое правило перезаписи в ваш файл Apache.htaccess, чтобы переписать все символы подчеркивания в дефисы.