Кратко

  • RFC 7807, опубликованный в марте 2016 года, задал общие форматы JSON и XML для подробностей об ошибках HTTP. Основным машинным идентификатором уже был URI поля type.
  • RFC 9457, выпущенный в июле 2023 года, заменил его и уточнил последствия относительных URI, смены адреса и нескольких проблем в одном ответе.
  • Реестр IANA предназначен для общих типов. Если type отсутствует, значение about:blank оставляет только смысл самого кода HTTP.

Чего не говорит код 403

Прокси, библиотека или браузер видят в 403 общий запрет. Для приложения, проводящего оплату, две разные причины отказа требуют разных действий. При нехватке средств можно предложить пополнение; при другом ограничении операция должна остановиться. Если назначить отдельный код HTTP каждой коммерческой причине, общий протокол утратит общность. RFC 7807 сохранил широкую роль статуса, а специальную причину поместил в тело ответа.

Пример стандарта описывает отклонённую покупку: статус 403, тип «не хватает кредита», человекочитаемый заголовок, объяснение конкретного случая, его адрес instance, расширения с балансом и счетами. application/problem+json задаёт общий контейнер, рядом определён формат XML. Но смысл конкретной нехватки средств задаёт владелец API. Инженеры стандарта не могли написать правила всех магазинов.

Для машины важен type. RFC 7807 предписал использовать его URI как главный идентификатор типа. title помогает человеку и может меняться при переводе. detail описывает именно этот случай; искать в его фразах управляющие слова рискованно. Клиент, зависящий от слова «баланс», сломается после правки текста. Клиент, распознающий URI, зависит от более чёткого обещания: оператор сохранит смысл имени.

instance отвечает на другой вопрос. Две покупки могут закончиться одинаковой нехваткой средств, но иметь разные ссылки на происшествие. Тип помогает выбирать правило обработки, экземпляр — находить запись в поддержке и журналах. Подменять одно другим означает делать каждый отказ новой категорией или, наоборот, терять отдельные случаи.

Пустой адрес с точным смыслом

При отсутствии type подразумевается about:blank. Он сообщает, что дополнительного значения сверх HTTP-статуса нет. JSON-оболочка не превращает обычный 404 в новый класс ошибок. Если оператору нужен особый сигнал для программы, он должен сам назвать проблему, объяснить её и удерживать имя от случайной смены.

Поле status внутри объекта не заменяет статус HTTP-сообщения. Если оно присутствует, его значение должно совпадать с реальным кодом ответа. Посредник способен изменить код, архив может сохранить тело без заголовков, однако универсальная HTTP-программа ориентируется на статус сообщения. Подробность в теле расширяет картину, а не захватывает управление протоколом.

Переезд адреса меняет саму ошибку

RFC 9457 сохранил конструкцию в 2023 году и показал цену неудачного имени. Относительное example-problem может разрешиться в разные ресурсы в зависимости от базового URL ответа. Одинаковая строка тогда обозначит разные типы; новый текст рекомендует абсолютные URI по возможности.

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

Пересмотренный стандарт объяснил и несколько проблем сразу. Расширение одного типа валидации может перечислить ошибки разных полей. Когда сталкиваются разные типы, рекомендуется выбрать самый важный или срочный. У одного HTTP-ответа один основной статус; мешок несвязанных диагнозов не помогает клиенту принять решение. Созданный при RFC 9457 реестр IANA принимает общие типы со спецификацией, оставляя частные названия их издателям.

Для оценки реального внедрения нужны датированные ответы серверов и версии клиентских программ. Нормативная история уже показывает разделение труда: стандарт даёт формат, оператор отвечает за постоянство конкретного имени.