Кратко

  • Deprecation из RFC 9745 сообщает, когда ресурс станет или стал нерекомендуемым, а Sunset из RFC 8594 — когда его URI, вероятно, перестанет отвечать; по умолчанию это подсказки о конкретном ресурсе, а не доказательство миграции.
  • Акт перехода клиента должен связать наблюдавшиеся заголовки с утвержденным охватом, заменой, владельцами зависимостей, данными об использовании, тестами совместимости, исключениями, условиями отката и фактическим поведением после отключения.

Анализ

Самый коварный вывод сервиса начинается с нормального ответа. Клиент отправляет привычный запрос и получает 200 OK. Ошибок нет, содержимое кажется прежним. Изменился только заголовок: теперь в нем стоит Deprecation с будущей датой. Команда сервера может обоснованно сказать, что предупредила потребителей. Но библиотека клиента могла отбросить неизвестное поле, а наблюдение — проверять лишь долю отказов.

RFC 9745 придает этому предупреждению общую форму. Значение Deprecation — дата Structured Fields. Будущая дата указывает, когда ресурс планируется считать нерекомендуемым; прошедшая — когда такой статус вступил в силу. Само объявление не меняет поведение ресурса. Он может и дальше отвечать как прежде, хотя после наступления даты потребителю уже нельзя полагаться на неизменность поведения.

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

RFC 8594 с помощью Sunset описывает следующую стадию: момент, когда URI предположительно перестанет отвечать. Это тоже подсказка. Она не гарантирует доступность до указанного времени и недоступность после него. Заголовок не предсказывает, что последует: ошибка, перенаправление или полная невозможность обращения. Если Sunset используется вместе с Deprecation, RFC 9745 запрещает ставить его раньше даты нерекомендованности. Правильный порядок устраняет явное противоречие, но не подтверждает готовность клиентов.

Наблюдаемый ресурс уже заявленного охвата

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

Поэтому собранный заголовок точно доказывает лишь один факт: конкретный URI вернул конкретное значение в конкретное время. Он не позволяет без дополнительного основания включить все методы, регионы, учетные записи и интеграции. И наоборот, отсутствие поля на одном пути не выводит его из решения, объявленного в другом месте.

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

Обнаруженная замена не разрешает автоматическое переключение

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

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

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

Акт перехода клиента

Первый раздел акта фиксирует сигнал: канонический URI, момент и источник наблюдения, отпечаток ответа, значения Deprecation и Sunset, связанные ссылки. Затем он называет объявленный охват и сторону, вправе расширить его за пределы одного ресурса. Противоречащие друг другу описания остаются открытым расхождением.

Второй раздел описывает замену. Помимо нового URI или версии, он сравнивает запросы, ответы, аутентификацию, авторизацию, аудитории, квоты, порядок операций, ошибки, хранение и региональную доступность. Документация доказывает, что сообщил поставщик. Контрольный запуск доказывает поведение одной версии клиента при конкретных условиях. Их нельзя смешивать в безусловное слово «совместимо».

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

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

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

Разные даты принадлежат разным решениям

Deprecation датирует статус ресурса. Sunset выражает ожидание доступности. У каждого клиента своя цель, у исключения — срок, у отката — техническая граница, у фактического отключения — наблюдаемое время после события.

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

Источники

  1. RFC 9745 — The Deprecation HTTP Response Header Field
  2. RFC 8594 — The Sunset HTTP Header Field
  3. Реестр IANA типов отношений ссылок