usepoint
menu

URI и URL: как выглядят адреса в интернете

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

uri-url

Содержание:

В первой части мы разобрались, как данные бегают по сети, что такое IP-адрес, домен, хостинг. Это всё - про «нижние уровни»: сеть, сервера, соединения.

Но когда вы открываете сайт или работаете с API, чаще всего вы видите не IP-адрес, а строку вроде:

https://example.com/shop/orders?status=new&page=2

Или:

mailto:support@example.com

Или:

myapp://product/123?from=push

Все эти строки - идентификаторы ресурсов. В мире веба для них есть формальный термин: URI. А то, что мы в быту называем «адрес сайта» или «URL» - это частный случай URI.

Нам нужно разобраться:

  • что такое URI;
  • что такое URL и как он устроен;
  • зачем вообще разделяют эти понятия и как к ним относиться на практике.

Что такое URI: общее понятие

URI (Uniform Resource Identifier) - это унифицированный идентификатор ресурса.

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

Resource (ресурс) - что угодно, к чему мы хотим обратиться: веб-страница, картинка, API-эндпойнт, файл, почтовый ящик, запись в приложении, чат, документ в облаке. «Ресурс» - это не обязательно что-то в интернете, это может быть сущность внутри конкретной системы.

Identifier (идентификатор) - строка, по которой ресурс можно однозначно узнать в рамках какой-то системы. Как паспортный номер для человека или инвентарный номер для вещи.

Uniform (унифицированный) - формат идентификатора стандартизирован. То есть разные системы могут использовать URI, и все будут понимать, как этот идентификатор примерно устроен.

URI - это просто строка-идентификатор в стандартизованном формате.

Одни URI описывают, где ресурс лежит и как к нему обратиться (это как раз URL), другие могут описывать ресурс без привязки к конкретному месту.

Структура URI: схема, путь, параметры

URI в общем виде состоит из нескольких логических частей. Упрощённо:

<схема>:<что-то_дальше_по_правилам_этой_схемы>

Схема (scheme) - это первое слово до двоеточия. Оно говорит к какому миру относится этот идентификатор и как с ним обращаться. Например:

  • http: - ресурсы по протоколу HTTP;
  • https: - то же, но поверх шифрования (TLS);
  • mailto: - электронная почта;
  • ftp: - файловое FTP-подключение;
  • tel: - телефонный номер;
  • myapp: или app:// - пользовательские (кастомные) схемы для конкретных приложений.

После схемы идёт то, что понимает уже конкретная схема.

Для https: это будет структура, похожая на привычный URL (домен, путь, query-параметры и т.п.), для mailto: - адрес электронной почты и дополнительные параметры, для tel: - номер телефона.

Например:

mailto:support@example.com

Здесь:

  • схема - mailto
  • часть после двоеточия - support@example.com (формат e-mail, а не веб-адрес)

Другой пример:

myapp://product/123?from=push

Здесь уже схема myapp (кастомная). Остальное интерпретируется самим приложением:

  • //product/123 - путь внутри логики приложения (например, экран товара с ID 123),
  • ?from=push - параметр, который приложение может использовать (например, «пользователь пришёл по push-уведомлению»).

URI - это не обязательно адрес в интернете и не обязательно что-то, что открывается в браузере. Это просто стандартный формат строк-идентификаторов.

Что такое URL и как он устроен

Теперь перейдём к тому, с чем вы сталкиваетесь каждый день.

URL (Uniform Resource Locator) - это унифицированный указатель местоположения ресурса. Если проще, то это такой URI, который не только идентифицирует ресурс, но и говорит, где он находится и как до него добраться по сети.

Например:

https://shop.example.com:8080/orders/123?include=items&debug=true

Разберём по частям.

  1. Схема (scheme)
    В начале https://.
    Это говорит нам о тои, что будет использоваться протокол HTTPS (HTTP поверх TLS, об этом в следующих главах) и по умолчанию ожидать, что запрос будет идти по TCP-соединению, на стандартный порт 443 (если другой порт не указан явно).
  2. Домен (host / hostname)
    В этом примере - shop.example.com.
    Это доменное имя, которое через DNS превратится в IP-адрес сервера. Разбор DNS мы уже делали ранее.
  3. Порт (port)
    После домена стоит :8080.
    Порт - это номер «входа» на сервере для конкретного приложения. Мы уже обсуждали порты как «номера квартир» в «доме» с IP-адресом.
    Если порт не указан, то берётся порт по умолчанию для схемы:
    • http → порт 80;
    • https → порт 443.
  4. Здесь порт указан явно, значит клиент пойдёт на 8080, а не на 443.
  5. Путь (path)
    В примере - /orders/123.
    Путь описывает, какой именно ресурс внутри сервера нас интересует.
    В типичном веб-приложении:
    • /orders может означать «раздел с заказами»;
    • /orders/123 - «конкретный заказ с ID = 123».
  6. Query-параметры (строка запроса, query string)
    Это часть после знака ?:
    ?include=items&debug=true

Здесь:

  • include=items - один параметр (include), значение - items;
  • debug=true - другой параметр.

Query-параметры обычно используются для дополнительных опций: фильтры, сортировки, настройки. При этом сам путь (/orders/123) указывает на базовый ресурс, а параметры уточняют, в каком виде его нужно вернуть.
Формально параметры разделяются &, каждый параметр - имя=значение.
Сервер читает эти параметры и использует их в логике:

  • status=new,
  • page=2,
  • limit=50,
  • sort=created_at.

(Опционально) Фрагмент (fragment)
В URL может быть ещё и фрагмент - часть после #, например:
https://example.com/docs/page#chapter2

  1. Всё, что после #chapter2, не уходит на сервер, а используется на стороне клиента (обычно в браузере) - чтобы прокрутить страницу до нужного места или переключить вкладку на фронтенде.

В итоге URL всегда отвечает минимум на два вопроса:

  1. Куда идти - схема, домен, порт.
  2. Что именно там просить - путь и query-параметры (а фрагмент - подсказка клиенту, что делать на самом ресурсе).

Разница между URI и URL: теория и практика

Теперь главный вопрос: если URL - это частный случай URI, а в реальной жизни все говорят почти только «URL», нужно ли вообще заморачиваться?

Теоретически (как в стандартах):

  • URI - общее понятие. Любая строка, которая однозначно идентифицирует ресурс в каком-то пространстве имён.
  • URL - такой URI, который указывает местоположение ресурса и способ доступа (через какую схему/протокол и куда именно идти).
  • URN (Uniform Resource Name) - идентификатор, который задаёт «имя» ресурса, не привязанное напрямую к месту. Например, нечто вроде «официальный ISBN книги».

Примеры для интуиции:

  • mailto:admin@example.com - это URI, но не «веб-адрес сайта». Он не указывает, где в интернете лежит HTML-страница. Он говорит: «вот такой почтовый ящик, к нему можно обратиться через почтовый клиент».
  • https://example.com/profile - это и URI, и URL, потому что он идентифицирует ресурс (страницу профиля) и даёт способ доступа (по сети, через HTTP/HTTPS, на конкретный домен).

На практике большинство разработчиков и пользователей говорят «URL» про любые веб-адреса, которые видят в браузере или документации API. Слово «URI» чаще всплывает в стандартах HTTP/REST, в архитектурных обсуждениях и в формулировках вроде «URI ресурса», «идентификатор ресурса».

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

  1. Любой URL - это URI, но не любой URI - это URL.
    https://example.com - и URI, и URL.
    mailto:boss@example.com - URI, но не URL в смысле веб-адреса сайта.
  2. Когда речь про веб и HTTP-API, почти всегда подразумевают URL, даже если в тексте написано «URI».
    Например, когда говорят: «ресурс доступен по такому URI» и показывают строку https://api.example.com/v1/users/123, - можно смело понимать это как URL.
  3. Различие важно в формальных стандартах и спецификациях, но в повседневной работе редко имеет практические последствия - в девяти случаях из десяти хватает слова «URL», а слово «URI» можно воспринимать как более общее.

Кастомные схемы URI: не только веб-страницы

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

Мы уже видели примеры вроде:

mailto:support@example.com

tel:+123456789

myapp://product/123?from=push

Здесь:

  • mailto: говорит почтовому клиенту: «создай письмо этому адресату»;
  • tel: говорит системе: «попробуй набрать этот номер в телефонном приложении»;
  • myapp:// - это уже полностью пользовательская схема, которую может зарегистрировать конкретное приложение.

Кастомные схемы позволяют открывать мобильное приложение из браузера (deep linking), передавать ему параметры (ID товара, источник перехода и т.д.) или «подцеплять» одно приложение к другому через стандартный формат URI.

С точки зрения нашей картины мира это всё URI. URL - это в основном то, что начинается с http:// или https:// и указывает путь к ресурсу по HTTP.

Зачем отличать URI и URL

При обсуждении API и архитектуры вы будете видеть фразы вроде «URI ресурса», «базовый URL сервиса», «endpoint URL». Важно понимать, что это не три разных существа, а просто разные уровни формальности одного и того же понятия: адреса ресурса.

Когда фронтенд и бэкенд обсуждают контракты, они будут говорить:
«У нас есть endpoint GET /api/v1/users/{id}».
За этим стоит конкретный URL, в который добавляется домен и схема, а внутри команды могут говорить и «URL», и «URI», и «путь».

При интеграциях с внешними системами вы часто будете видеть документацию в терминах: «Base URL: https://api.partner.com/v2» и «Resource URI: /orders/{id}».
Это просто разные куски одной строки:
https://api.partner.com/v2/orders/123.