Должен ли я использовать заголовок в URL?


9

В настоящее время мы принимаем согласованное соглашение об именах для сайта с несколькими веб-приложениями. Исторически я был сторонником «строчных букв»! при создании URL:

http://example.com/mysystem/account/view/1551

Однако в течение последнего года или двух, особенно с тех пор, как я начал использовать ASP.NET MVC и больше занимался URL-адресами на основе REST, я стал поклонником использования первой буквы каждого раздела / слова в URL-адресе, поскольку это делает его легче читать (имхо).

http://example.com/MySystem/Account/View/1551

Мы не находимся в ситуации, когда людям нужно читать или уметь понимать URL-адреса, так что это не драйвер сам по себе. Главное, к чему мы стремимся, - это последовательный подход, который является рациональным и имеет смысл.

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

Ответы:


10

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

Поскольку вы используете ASP.Net, я бы порекомендовал придерживаться подхода PascalCase - поскольку именно он обычно существует в рамках Microsoft (системные библиотеки и т. Д.), Но не существует «лучших практик», кроме как быть последовательными.

Большинство браузеров довольно хорошо скрывают URL-адрес от пользователя до такой степени, что очень многие люди, у которых в качестве домашней страницы есть Google, будут искать Facebook и нажимать на него - вместо того, чтобы вводить URL-адрес Facebook в своей странице. браузер.



1
Вы должны хотя бы упомянуть, что чувствительность к регистру зависит от конфигурации сервера, поэтому стоит подумать, а не указывать неправильно, что система не различает верхний и нижний регистр.
jleach

@ jdl134679 сделано.
TZHX

4

Для внутренних веб-сайтов это не так важно, если вы согласны с этим.

Для внешних общедоступных сайтов вы, вероятно, захотите придерживаться строчных букв, что является более или менее стандартным стандартом для веб-хостинга Linux / Apache. Насколько я помню, некоторые версии Firefox, похоже, обрабатывают регистр URL иначе, чем IE. Это также может относиться и к Chrome.

Наличие согласованного корпуса также имеет значение для поисковой оптимизации. Вы не хотите, чтобы Google видел в нижнем регистре.aspx и в нижнем регистре.aspx разные страницы с дублированным контентом. Хотя их алгоритмы пытаются предотвратить эту ошибочную идентичность, это происходит время от времени и может привести к тому, что страница будет оштрафована.


2

Пока пользователи могут печатать его так, как они хотят, это действительно не имеет значения. Лично я предпочитаю TitleCase, но есть многие, кто не согласен. Если вы последовательны, никто не будет возражать.

Если ваш веб-сервер по какой-то причине не может показать мне, http://foo.com/HelloWorldкогда я пытаюсь зайти http://foo.com/helloworld, вы должны выбрать строчные буквы. Хотя в наши дни люди редко вводят полные URL-адреса, внешние адреса должны быть доступны без необходимости использовать заглавные буквы.


2

То, что вы начали использовать MVC, не должно «просачиваться» в вашу абстракцию REST. Есть веские причины использовать все строчные URL-адреса с тире между словами. URI (не доменные имена) чувствительны к регистру. Если вы все в нижнем регистре и используете тире для разделения слов, вы устранили много работы с догадками и одноразовые, и если вы используете прокси-сервер (nginx, nodejs, apache ...), у вас не будет все начинает ломаться потому что это вдруг чувствительно к регистру.

«MiXeD-CaSe NaMeS. Не путайте своих пользователей с помощью« Mixing-Upper-case-and-Lower-case-Character-in-the-URL ». Придерживайтесь строчных букв, и не заставляйте их угадывать. Ваш пользователь фактически вводит URL в смешанном регистре, нормализует его на сервере и обслуживает соответствующий случай ".


1

В то время как домены верхнего уровня не чувствительны к регистру и пути Windows , использовать комбинацию капитала и Паскаль случае, наши приложения чувствительны к поступающим путям запроса, где пути или компоненты в них, как правило , нормированных на стандартном случае, так /format/JSON/и /format/json/есть запросы на два разные форматы и ссылаются на два разных ресурса.

Всякий раз, когда я видел http://www.somewebsite.com/Having/URLs/That-Look-Something-Like-This/ , я чувствовал, что намерение разработчика в основном должно показаться немного отличным от остальных, но это ничего новаторство и при этом это не поможет улучшить читаемость, особенно теперь, когда у вас есть я и л , О и 0 , другие буквы соперничающих для анализа.

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

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


0

НИКОГДА не используйте заглавие в целях удобства использования! Представьте , сколько времени вы должны тратить и кликов , чтобы выполнить для различных случае URL в вашем МОБИЛЬНОГО телефона!


Хотя на моем iPhone заглавная буква требует меньше дополнительных нажатий клавиш, чем «-» или «_».
BradS

Современные смартфоны, по крайней мере, телефоны на базе Windows, позволяют проводить пальцем по клавише «caps», чтобы добиться этого одним движением
0fnt
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.