Должен ли сервер обработать запрос, если формат ответа не поддерживается?

Question

[alexg-nn]

Привет!

В HTTP протоколе есть такой статус 406 Not Acceptable, означающий, что сервер не может вернуть ответ в том формате, который понимает клиент. Мне не понятен вот какой момент. Допустим, прилетает POST (или PUT) запрос с Accept application/json, а сервер умеет возвращать лишь XML. Вопрос: должен ли сервер выполнить действие, которое предполагается в обработчике POST/PUT запроса, а потом послать 406 ответ, либо сперва он должен проверить может ли ответить в таком формате, а только потом приступать к обработке запроса. Как то нигде не нашёл однозначного ответа на этот вопрос.
В стандарте вообще написано, мол, вывалить ответ во всех возможных форматах, а клиент сам выберет более понятный. То есть там предполагается, что POST/PUT всё таки обработается. Но хотелось бы услышать мнения.

Спасибо.

Answer 1

[Rsa97]

RFC 7231

The 406 (Not Acceptable) status code indicates that the target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request (Section 5.3), and the server is unwilling to supply a default representation.
The server SHOULD generate a payload containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate. A user agent MAY automatically select the most appropriate choice from that list. However, this specification does not define any standard for such automatic selection, as described in Section 6.4.1.

То есть, серверу РЕКОМЕНДОВАНО вернуть список допустимых вариантов (а не содержимое во всех вариантах), среди которых агент МОЖЕТ выбрать подходящий ему.

Comments

[alexg-nn]

Спасибо, не вчитался, видимо, вдумчиво в стандарт)

Я видел пример реализации, где в ответ присылается список ссылок вида
/endpoint.json
/endpoint.xml
и т.д

Но это работает только если формат задаётся расширением файла. А если negotiation проходит на уровне заголовков, как тут намекнуть на поддерживаемые форматы? Просто список написать?

[Rsa97]

alexg-nn, Конкретно по полю Accept всё отдаётся на милость сервера, он может как вернуть 406, так и вернуть нормальный ответ в любом доступном ему типе:

If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation.

А вот как именно возвращать список доступных типов, стандартом не оговорено. Можно, например, вернуть HTML-страницу с доступными вариантами.

Answer 2

[Иван Шумов]

В любой обработке любой логики сначала идет валидация запроса (что в http запросе, что в просто функции в коде). Подход Fail First. Если запрос не соответствует правилам игры - сразу до свидания, спасибо что зашли, но вам тут не рады :-)

Comments

[alexg-nn]

Вы имеете в виду Fail Fast, наверное. Fail First это что то из разряда Die Hard :)

[Иван Шумов]

alexg-nn, Fail Fast это подход для разработки PoC или концепции где цель - если оно не работает то узнать об этом до релиза. Fail First это подход в разработке где сначала проверяются все негативные условия и выходы из программы до начала обработки непосредственно логики