Я работаю над веб-сайтом, на котором мы проводим серьезную реструктуризацию. Есть пункт, который может показаться немного привередливым, но я так или иначе не вижу стандарта.
Когда вы используете реальные слова в URL-адресе с / в качестве разделителя, следует использовать единственное или множественное число типа. Так
/user/fred
против
/users/fred
SO, кажется, использует «вопросы», «пользователи» и т. Д., Но мне было интересно, есть ли какой-нибудь авторитетный совет в любом случае.
PS. Я не мог понять, принадлежит ли это SO SU или SF. Не стесняйтесь двигаться, если вы можете решить, в какое ведро он должен поместиться.
Я всегда слышал, что это не имеет значения, если вы внутренне последовательны.
При этом в системной архитектуре * nix это всегда единственное. (например, «пользователь», «дом», «мнт» и т. д. (или должно быть «и т. д.»?)), так что это может быть лучшим вариантом по умолчанию, поскольку это уже распространено?
Я лично предпочитаю множественное число, оно указывает на то, что существует коллекция Users, в которой вы ищете fred.
Чтобы сделать ответ @Satanicpuppy более точным, не всегда верно, что в системной архитектуре * nix это всегда единственное число. Я думаю, что в системах * nix, поскольку системные администраторы в основном обращаются к ним с помощью терминала, приоритетом является меньше печатать, и поэтому мы
have proc and not process,
have mnt and not mount,
have var and not variable,
have usr and not user,
...
и список продолжается, еще одна причина, по которой они использовали аббревиатуру (здесь речь идет не о форме единственного или множественного числа, а о том, почему она сокращена). Независимо от ОС в старые времена существовали ограничения на файловую систему. Ограничения были на обоих Maximum Pathname Length и Maximum Filename Length . Может быть, вы помните (если вы достаточно взрослые;)) файл verylongnames.txt превратился в verylo ~ 1.txt в windows, а если нет вот объяснение).
Но в последние годы все изменилось: ограничения исчезли, в настоящее время важным вопросом является UX и удобочитаемость, и большинство пользователей используют графический интерфейс для взаимодействия с компьютерами. И это хорошая причина, что во всех основных операционных системах (Linux, OS X и Windows) правила именования каталогов пользователей одинаковы:
Users
'-Documents
'-Downloads
'-Movies/Videos
'-Pictures
единственное исключение - каталог Users в Linux называется домашним.
Помимо вышеперечисленных причин, в сети чаще используются формы множественного числа:
В Django часто используется множественное число: например, в руководстве по приложению для опросов документация django:
# To get a list of polls
/polls/
# To get an individual poll item
/polls/5/
Еще один хороший пример - Google, который использует:
google.com/analytics
google.com/analytics/settings
google.com/analytics/feeds
google.com/books
google.com/catalogs
google.com/maps
google.com/places
google.com/trends
также Bing использует форму множественного числа:
bing.com/images
bing.com/maps
bing.com/results
bing.com/videos
И, конечно же, stackoverflow:
stackoverflow.com/users/
stackoverflow.com/feeds/
stackoverflow.com/questions/
stackoverflow.com/tags/
stackoverflow.com/help/badges
Я предпочитаю единственное /user/fred потому что для непрофессионала это более грамматически правильно: вы смотрите на профиль пользователя для пользователя fred. Однако если /users/ показывает всех пользователей, затем /users/fred имеет больше смысла.
В конечном итоге @Satanicpuppy верен, важно то, что вы последовательны.
В любом случае, вероятно, будет хорошей идеей настроить 301 редирект с неправильной версии на каноническую. Таким образом, когда кто-то набирает ссылку, а не копирует ее, он получает 301 вместо 404.
Лично я бы использовал / users / в качестве страницы со списком пользователей (если он есть) и / user / fred / в качестве домашней страницы fred. Но делать работу беспорядочно, особенно если вы хотите использовать редирект 301, поэтому в реальной системе я бы выбрал один и придерживался его.
Я предпочитаю множественное число. Если вы представляете, что ваш сайт не является динамическим, и вам нужно было создать сайт, просто используя папки и файлы, которые обслуживались apache. Тогда папка будет во множественном числе. Например документы скорее, чем документ.