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

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

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

camelCase

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

тире

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

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

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

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

322
api rest restful-url uri url

5 ответов

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

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

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

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

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

308

стандартная лучшая практика для REST APIs - иметь тире, не 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 моей компании имеет URIs like /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-адрес и стиль его с подчеркиванием (например, links традиционно are), то вы можете избежать подчеркивания в качестве разделителей слов. Особенно при печати подчеркнутый URL-адрес с подчеркиваниями имеет тенденцию выглядеть так, как будто он имеет помещения в нем вместо подчеркивает.

CamelCase

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