Ввод подробного сообщения об ошибке REST в заголовок предупреждения HTTP, хорошая/плохая идея?

Мы разрабатываем стандартную службу REST с использованием кодов состояния HTTP в качестве кода ответа, если что-то пошло не так. (например, неверный ввод пользователя возвратит клиенту "400 Bad Request" )

Однако мы чувствовали, что более подробное сообщение об ошибке будет полезно для клиента. (например, неверная входная ошибка связана с тем, что X является непризнанным именем параметра)

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

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

Кажется, нет ограничений на использование этого заголовка для других предупреждений (например, сообщение об ошибке REST), даже те, которые не связаны с предупреждениями о кеше в соответствии с первоначальным намерением этого заголовка. Нам нравится семантика, и мы планировали использовать код предупреждения 299, который, по-видимому, подходит для счета довольно хорошо:

299 Прочее постоянное предупреждение. Текст предупреждения МОЖЕТ включать произвольную информацию , которая должна быть представлена пользователю пользователя или зарегистрирована. Система, получающая это предупреждение, НЕ ДОЛЖНА предпринимать какие-либо автоматические действия.

Итак, учитывая неверный ввод ошибки, представленный в верхней части этого вопроса, мы думаем о том, чтобы поместить наше сообщение об ошибке REST, как в следующем примере:

HTTP/1.1 400 Bad Request
Warning: 299 ServiceName "Invalid input error: X is unrecognized parameter name."

Это хорошая идея/практика? Мы также обнаружили, что некоторые службы подробно описывают это сообщение в заголовке X-Warning, но это кажется не стандартным. Мы задаемся вопросом, что подумает об этом. Есть ли также более эффективная/стандартизованная практика для передачи подробных сообщений об ошибках в ответах REST?

Ответ 1

Почему бы просто не изменить фразу причины? Это то, для чего оно есть. Текст "Плохой запрос" является стандартным. Если вы хотите включить дополнительную информацию, используйте тело ответа. Спецификация HTTP говорит, что вы ДОЛЖНЫ включать тело ответа с подробностями ошибки.

ОБНОВЛЕНИЕ

Основываясь на более позднем чтении RFC 7231 и связанных с ним материалов, представляется единственной веской причиной изменения фразы причины, чтобы локализовать текст, а не предоставлять более конкретное значение. Извините.

Ответ 2

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

Иногда меньше информации лучше.

Ответ 3

Я сторонник общего подхода. Мы должны предположить, что клиентский разработчик находится в другой команде от разработчика услуг, может быть, в другом часовом поясе и т.д. Возможно, даже другая компания. Нехорошо вернуть ответ "нет, что плохой запрос", как клиент может решить проблему.

Итак, философски: расскажите клиенту о том, что они могут исправить. Ошибки, которые являются чисто областью сервера (например, ошибка подключения к базе данных или какая-то логическая проблема), справедливо просто вернуть ошибку 500. И здесь я не буду отправлять какие-либо подробности, мы не хотим раскрывать информацию о нашей внутренней реализации клиенту.

До сих пор я возвращал данные в тело ответа, используя JAX/RS:

return Response.status(400).entity("some message here").build();

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

Ответ 4

Если это предложение, оно представляет собой альтернативу для отправки подробных сообщений об ошибках. [http://tools.ietf.org/html/draft-nottingham-http-browser-hints]

Несмотря на то, что это I-D, он довольно стабилен в последнее время, и я не вижу проблем с созданием собственной реализации. (Я сделал.)

Ответ 5

429 Слишком много запросов (RFC 6585) Пользователь отправил слишком много запросов за определенный промежуток времени. Предназначен для использования с схемами ограничения скорости.

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

Вы также можете (и поощряетесь спецификацией HTTP) настраивать тело ответа HTTP, поэтому вы можете изменить "Слишком много запросов" на любое объяснение, которое вы хотите.