Как правильно определить well-known URI: рекомендации автора стандарта

Well-known URI это специальные адреса вроде /.well-known/change-password, где клиент (браузер, бот или софт) может запросить информацию о целом сайте, не проверяя каждую страницу отдельно. Идеальный пример это /robots.txt: поисковые роботы скачивают политику доступа один раз вместо проверки заголовков на каждом запросе. Но эта техника работает только в одном сценарии: клиент уже знает сайт и ему нужно узнать что-то про сайт целиком.

Проблема в том, что многие разработчики регистрируют well-known URI просто потому что это выглядит "правильно", или надеются, что место в реестре придаст их протоколу легитимность. На самом деле такая регистрация может создать ненужные ограничения. Например, паттерн "один сервис на один сайт" не масштабируется: если организации нужно запустить несколько сервисов, придётся создавать отдельные сайты. Лучше передавать полный URL, если протокол это позволяет.

Ключевые факты

Well-known URI подходит, когда клиент знает сайт и нужно узнать что-то про сайт целиком (как robots.txt)
Часто их используют неправильно: как URL-shortcut вместо полной адресации, или для придания "официальности" протоколу
Проблема с discovery: какой хост искать (login.example.com или example.com?), нужны ли редиректы, работает ли это в поддоменах
Контент-метаданные требуют сложной инфраструктуры, если сайт хостит нескольких издателей (как /~username/), а не один
Нужна стратегия миграции для существующих развёртываний, явное указание схем (http/https/другие), обязательная регистрация в реестре

Ред. "Well-known" это когда в спецификации говорят "все знают, как это работает", но потом выясняется, что все по-разному это понимают.

Почему это важно

Well-known URI решают одну конкретную проблему: быстрое получение информации о сайте целиком без сканирования. Но если в вашем протоколе этой проблемы нет, регистрация лишь создаёт архитектурные ограничения и жёсткие связи между сервисом и доменом. Разработчики часто путают "это выглядит официально" с "это решает мою задачу", что приводит к хрупким спецификациям, которые не выживают первого контакта с реальными развёртываниями.

Ред. Регистрация в реестре это не сертификат качества. Как и строка в словаре.

Кому это важно

Это касается архитекторов веб-протоколов, авторов RFC и стандартов, разработчиков, которые интегрируют или расширяют существующие протоколы вроде OAuth, WebFinger или других spec-driven систем. Также релевантно тем, кто запускает сложные хосты со множественными сервисами или издателями под одним доменом; им нужно понять, почему well-known подход может не подойти.

Ред. "Это важно для архитекторов" обычно означает "вы это уже сломали в production, но ещё не заметили".

Как это применить

Перед тем как регистрировать well-known URI, ответьте на три вопроса: (1) клиент уже знает сайт и это должно быть сайт целиком, (2) вы не просто передаёте полный URL под видом "сокращения", (3) ваша архитектура действительно требует 1:1 映射 сервис-домен. Если оставили развёртывание с фиксированной точкой доступа (вроде /robots.txt), спланируйте миграцию на /.well-known/ и дайте достаточно времени. Явно укажите, какие URL-схемы поддерживаются (не только http/https), и продумайте поведение при редиректах между поддоменами.

Ред. "Дайте достаточно времени" означает "не менее одного цикла боли пользователей".

Можно ли доверять

Автор это один из авторов спецификации RFC для well-known URI и текущий Designated Expert, отвечающий за реестр. Это не мнение, это практический опыт из тысяч пропозалов и консультаций. Статья строится на конкретных примерах (robots.txt, change-password, /~username/ в виртуальных хостах) и явно отделяет требования к регистрации от рекомендаций по лучшей практике. Источник надёжный.

Ред. Designated Expert это кто-то, кому регулярно говорят "нет", и он это обоснует.

Риски и подводные камни

Основной риск это жёсткая связь 1:1 между сервисом и сайтом. Если организация растёт и нужны дополнительные сервисы, придётся создавать новые домены и разбираться с маршрутизацией трафика. Discovery-механизмы могут не работать в сложных топологиях (поддомены, редиректы, виртуальные хосты). Если well-known URI содержит контент-метаданные вроде политик для отдельных издателей, администратор должен будет поддерживать сложный инструментарий для управления доступом. Наконец, мигрировать уже развёрнутые системы на новый формат дорого и долго; лучше это спланировать изначально.

Ред. "Мигрировать дорого и долго" это способ сказать "вы застряли с этим навсегда".