Uriy MerkUriy Efremochkin personal website

Good URL

URL адреса, удобные, простые, полезные и продуктивные или хороший тон адресной архитектуры web-приложений.

Исчерпывающая информация о web-адресах

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

Сама по себе ссылка (или «отсылка») чаще всего представляет собой символьную строку, идентифицирующую какой-либо сетевой ресурс, его часть или состояние, которую называют «Единым указателем ресурсов». Но в разговорной речи, в зависимости от контекста, чаще можно встретить другие названия: английскую аббревиатуру «URL», «URL-адрес» или просто «адрес».

Единый указатель ресурсов (англ. URL — Uniform Resource Locator) — единообразный локатор (определитель местонахождения) ресурса. По-английски «URL» целиком произносится как /ɜː(ɹ)l/, по-русски чаще говорят [у-эр-э́л], [ю-ар-эл] или [урл] (сленг). Ранее назывался Universal Resource Locator — универсальный локатор ресурса. URL — это стандартизированный способ записи адреса ресурса в сети Интернет.

Материал из Википедии — свободной энциклопедии

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

Структура web-адреса

Существует стандарт структуры URL повсеместно используемый даже вне всемирной паутины:

Cтандарт структуры URL

В структуре явно выделяются основные части URL (схема, хост, путь, параметры и якорь), которые в свою очередь можно разделить на составные. Ниже мы подробнее разберём каждую часть структуры.

Как видно, все части структуры являются необязательными. И почти все части структуры имеют свои идентифицирующие символы (зарезервированные символы), например символ вопроса (?) указывает на то, что далее идёт последовательность символов составляющих GET-параметры. На самом деле эта последовательность может быть пустой, как и в случаях с другими частями структуры.

Хост и схема обычно разделены двойным слешем. Но вы уже, наверное, заметили по схеме, что двойной слеш является необязательным. Сам автор структуры URL Тимом Бернерсом-Ли на сегодняшний день признаёт избыточность двойного слеша в этом месте структуры. Современные реализации схемы URL в программно-аппаратном обеспечении позволяют не указывать две косые черты в случаях когда указана схема.

Относительность и абсолютность адреса

Все части структуры адреса являются необязательными. Поэтому, по полноте записи принято различать абсолютные и относительные адреса. При этом не учитываются «GET-параметры» и «якорь», а берутся во внимание только месторасположение ресурса, способ доступа к нему и путь до ресурса.

Полная запись URL, начинающаяся с указания протокола (например «http://»), называется абсолютным адресом.

Неполные адреса иерархически ссылаются относительно какой-либо опущенной части адреса, из-за чего их и называют относительными. Обычно опускается левая часть адреса, и в зависимости от того, относительно какой опущенной части ссылается запись адреса их различают так:

Не редко к абсолютному адресу так же присваивают и относительные к протоколу адреса, т. к. стандартом в web является протокол http, который и считается в данном случае опущенным. Относительные адреса (кроме относительных протоколу) часто называют «ссылками». Это более простое разделение на абсолютные адреса и ссылки, часто используемое при описании структуры URI.

Схема

Схема представляет из себя наименование или аббревиатуру сетевого протокола или схемы обращения к ресурсу.

Схема является обязательной частью абсолютного адреса. Так же схема определяет назначение и вид остальных частей записи URL.

Хост

Запись хоста в структуре URL является адресом узла в сети используемой схемы, на котором расположен запрашиваемый ресурс или сервис, предоставляющий данный ресурс.

Прикладной уровень в стеке протоколов TCP/IP более обширный одноимённого уровня модели OSI. В семействе протоколов прикладного уровня TCP/IP входят 3 верхних уровня (прикладной, представительский и сеансовый) модели OSI.

Вот несколько примеров популярных схем и зарезервированных за ними портов:
HTTP — 80,
HTTPS — 443,
FTP — 21,
XMPP — 5222

Большой список назначения портов

При использовании основных общепринятых схем URL, представляющих из себя протокол прикладного уровня стека OSI (HTTP, FTP, SMTP (mailto), и другие), минимальной записью <хост> является символьное имя в пространстве имён DNS (доменное имя) или IP-адрес. При этом, в полной записи <хост>, указывается так же и номер порта, следующий за символом-разделителем двоеточия (:). Но за каждым популярным протоколом прикладного уровня зарезервирован его идентифицирующий порт, который обычно опускается в записи хоста.

Значения этой части структуры URL клиентские агенты (браузеры) умеют автоматически исправлять, помогая пользователям исправлять допущенные ими ошибки:

Иерархический путь

Иерархическая часть URL напоминает иерархическую запись адреса файла в *nix операционных системах.

Запись иерархического пути в структуре URL имеет один корневой раздел, а вложенность разделов отмечается символом прямого слеша (/) (Коса́я черта́). Каждый документ может находится на любом уровне вложенности.

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

Якорь

Якорь обычно идентифицирует часть документа и/или состояние документа.

Юзабилити URL

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

Длинные и неудобоваримые адреса часто возникают из-за лени программистов. Надо один раз всех программистов собрать и объяснить, что пока адреса не станут нормальными, проект не откроется. Повозмущаются и сделают как надо.

Артемий Лебедев

Кому и как поможет хороший указатель web-ресурса:

Существует такое понятие, как ЧПУ, или «Человекопонятный Уникальный Идентификатор Ресурса» (англ. friendly URLs). В Википедии дают такое определение этого понятия: это веб-адреса, удобные для восприятия человеком (а также систем и методов построения таких адресов). Данное понятие используется уже очень давно в кругах веб-разработчиков и специалистов по поисковой оптимизации. Но я считаю это понятие не совсем грамотным. Хотя, с этим понятием связывают большое количество полезных рекомендации к усовершенствованию адресно-указательной архитектуры веб-приложений.

Возможно, название «Полнотекстовые адреса» было бы более грамотным. Для удобства я бы ещё разделил это на два понятия, каждое из которых охватывало бы принципы «дружелюбности» URL в отдельности для программно-аппаратных средств и людей (пользователей, разработчиков и т.д.). Я осмелюсь ввести такие понятия, как «юзабилити URL» и «технически-дружелюбные адреса». Хотя, эти понятия пересекаются, в любом случае, для каждого из них можно выделить отдельные рекомендации и принципы «дружелюбности».

Почему сразу «юзабили»? Потому, что понятие «юзабилити URL» в моём представлении может охватить большое количество принципов и правил, имеющих прямое отношение к улучшению степени удобности использования приложений, а так же удобства применения разработчиками и контент-менеджерами в развитии приложений.

Ниже я приведу несколько основных правил и принципов юзабилити URL.

1. Различайте разделы и простые документы

Раздел, так же как и документ, является отдельной веб-страницей и имеет свой адрес. Адрес раздела должен завершаться символом слеша (/), что и отличает его от простого документа. Отсюда следует, что вполне возможно и допускается существование двух документов с одинаковым именем, один из которых завершается символом слеша, а другой — нет. У каждой такой страницы своё назначение.

Примеры:
/catalog/fridges/lg/ — раздел каталога со списком холодильников производства LG
/catalog/fridges/lg — подробное описание качества холодильников производства LG, гарантийных особенностей на холодильники этого производителя и т. д.

Если страница является коллекцией документов, т. е. содержит дочерние документы и/или разделы, то адрес страницы должен заканчиваться на (/). Иначе слеш лучше не ставить, тогда путь пользователя будет смотреться завершённым.

Как себя проверить? Очень просто:
Например, мы находимся в категории холодильников каталога бытовой техники, в котором перечислен список производителей холодильников, тогда должна быть возможность в качестве адреса на категорию производителя ставить просто имя производителя (это один из плюсов использования символа слеша в конце адресов разделов):
/catalog/fridges/
    bosch
    lg
    samsung
    siemens

Правило: посетитель всегда должен получить осмысленное и предсказуемое содержимое, если он стер часть адреса до ближайшей косой черты.

2. Используйте мощь иерархии

Разделяйте документы, объединяйте в группы по каким-либо общим признакам и используйте вложенность по разделам.

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

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

3. Предоставляйте список вложенных документов в разделах

Каждый раздел должен предоставлять список всех вложенных документов или разделов. А так же хорошим тоном является указание смежных по тематике документов из других разделов или глубоко вложенных в данный раздел.

Таким образом, пользователь, попадая на такую страницу, сможет легко сориентироваться в разделе и понять куда следовать за более подробной информацией по интересующей теме.

4. Именуйте документы грамотно

Наименование документа в иерархическом пути должно состоять из ключевых слов документа.

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

В противном случае, т. е. когда документ не является разделом с вложенными документами и не является по смыслу списком, название документа должно быть именем нарицательным в единственном числе или именем собственным описывающим содержимое документа.

В случае, если нет возможности использовать в качестве имени документа имя нарицательное или собственное, например, когда нет подходящего имени описывающего содержимое всего документа, возможно использование короткого словосочетания. Но при этом необходимо учитывать пункт «6. Используйте короткие и простые адреса».

5. Используйте соглашение «Lower-case-dashes» для именования веб-ресурсов

Для наименования документов состоящих из нескольких слов (словосочетаний) рекомендуется использовать соглашение именования «Lower-case-dashes» (Lowercase words are separated by dashes), т. е. слова в нижнем регистре разделённые символом дефисоминуса (-).

Вот несколько причин, из-за которых стоит придерживаться именно такого соглашения об именовании:

Вы, возможно, захотите сказать: Но ведь Википедия использует разный регистр букв и символ нижнего подчёркивания в качестве разделителя слов. Но это почти тоже, что и строка поискового запроса, это так называемое исключение, так как в случае Википедии для полного идеального соответствия имени документа и заголовка документа, необходимо использовать оригинальный регистр слов разделённых, наиболее редким для имён собственных, символом нижнего подчёркивания (_). Так или иначе, такое решение относительно адресной архитектуры несёт за собой и проблемные стороны.

Пример использования:
Вот это одно_слово и это тоже одноСлово, а вот это уже два-слова.

6. Используйте короткие и простые адреса

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

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

Три правила:

Примеры ошибочных URL:
    data:
    name?name
    table#008

7. Опускайте протокол и хост по умолчанию

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

Указание протокола даже в полных адресах необязательно. Можно использовать запись, начинающуюся с (//), тогда будет использоваться текущий протокол. Но при ссылках на чужие ресурсы убедитесь, что у них поддерживаются схемы, используемые в вашем случае по умолчанию.

8. Используйте относительные к хосту адреса вместо относительных к разделу

Это избавит от возможных проблем и ошибок проектирования и разработки.

9. Избегайте идентификаторов сеансов (сессий) в адресах

Встречется множество таких примеров: при использовании библиотеки Spring Security, фреймворка Code Igniter и в разных других случаях.

Необходимо следить, чтобы их не было в адресах. Это, во-первых, не приятно выглядит внешне. Во-вторых, это может быть причиной дублирования ресурса по разным адресам. Подробнее в следующем пункте «10. Избегайте дублирование контента».

10. Избегайте дублирование контента

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

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

Пример: Если однажды при индексировании сайта поисковику попадутся страницы с адресами, в которых подставлены случайные идентификаторы, а при следующем сканировании попадутся те же ресурсы, но в адреса которых будут подставлены другие случайные идентификаторы, это послужит причиной появления дубликатов в индексе поисковика.

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

11. Не используйте расширения .html, .htm, .xhtml и .xht

В обычных ситуациях совсем необязательно использовать расширения для HTML страниц, так как это подразумевается по умолчанию для определённого типа документа (<!doctype>) — DTD (document type definition, описание типа документа).

Отсебятина (обращение к читателю)

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

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

А вот такие у меня планы на будущее по развитию данной темы:

Если вы считаете, что такими способами, описанными в данной статье, никто и никогда не будет использовать веб-адреса, то, скорее всего, вы уже достаточно сильно заражены инфекцией грязных и неудобных интернет-адресов, которой заражено наверно около 70% веб-страниц. Если в нашей повседневной интернет-деятельности будут чаще использоваться веб-приложения с хорошей адресной архитектурой, мы сможем совсем по-другому взглянуть на URL и использовать его во всё большем разнообразии способов и для большего количества ситуаций.

Помогите мне исправить и дополнить данную статью вашими или чужими мыслями, полезными ссылками по теме и, конечно же, полезными примерами. Задавайте свои вопросы в комментариях, пишите свои пожелания по дальнейшему развитию статьи и участвуйте в обсуждении. А так же делитесь ссылочкой с друзьями и коллегами по цеху. Я верю, что вместе мы сможем сделать интернет хоть чуточку чище и удобнее.

Поделитесь с коллегами ссылочкой: