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

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

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

camelCase

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

тире

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

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

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

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

5 322
url turing-complete api database-restore restful-url

5 ответов:

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

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

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

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

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

308

стандартная передовая практика для API REST должна иметь тире, не camelcase или подчеркивания.

это происходит из "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

132

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

Ничего

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

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

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

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

тире

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

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

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

CamelCase

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