2017-01-11 11 views
3

Приносим извинения, если для этого есть ответ. Я нашел связанные вопросы (например, HTTP status code for a partial successful request), но не совсем то же самое.HTTP-ответ, получающий ресурс, когда доступны только частичные данные

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

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

До сих пор варианты

  1. возвращение 200, считают его частичный ресурс, обрабатывать поля данных об ошибке в приложении, как вы бы с любыми другими данными
  2. возвращение 207, чтобы подчеркнуть, что это не в полной мере успешно, но 207 не является строго HTTP.
  3. возвращение 500 и обрабатывать успешно возвращаемые данные в приложении, как на 200

Я неравнодушен к варианту 1, но я не полностью убежден. Есть ли ясный способ справиться с этим? Возможно, определите конкретный content-type?

+0

Его субъективное, лично я бы сказал, что 500 подходит, поскольку данные ошибочны, поскольку они не соответствуют ожиданию соответствующего запроса. Вы можете добавить любые настраиваемые заголовки ответов, которые вам нравятся, например. 'X-Response-Type: partial' и поручить вашим клиентам ссылаться на значение перед обработкой данных ответа, если они получают код 500 –

+0

Hi @AlexK. Я могу видеть дело на 500, но поскольку мы специально обрабатываем отсутствие данных в полезной манере, и ресурс может (и будет) возвращаться согласованным образом, 200 будет более уместным. Если вы хотите провести параллель, я бы сказал, что она похожа на обработанное исключение в коде, тогда как 500 будет аналогично необработанному исключению. Может быть, это не хорошая параллель? Мы возвращаем тип контента, который подчеркивает, что информация является частичной для оповещения клиента. Это имеет смысл с вашего POV? – guioconnor

+0

Лично я возвращаю '200' и ​​укажу, какие данные отсутствуют в теле ответа (ваш вариант №1). REST, насколько мне известно, очень ресурсоцентричен, и поскольку в вашем случае ресурс является ** действительным и полезным ** (и, другими словами, «он существует»), '200' кажется лучшим выбор. Возможно, также не рекомендуется обманывать «контент-тип», поскольку это может смутить некоторых клиентов. Просто пойдите с простым 'application/json' (или XML). Я также заметил, что многие API-интерфейсы имеют тенденцию «ошибаться» в направлении «200» и возвращать богатые статусы в качестве данных. Кажется более «идиоматическим» таким образом. – sigriston

ответ

2

У вас отсутствует пункт здесь, потому что 500 указывает на отказ системы или цепи связи, а так как данные возвращаются, следует предположить, что ресурс существует и найден. То, что указало ОП, является частичным результатом, подразумевающим составные данные, относящиеся к ресурсу. Это необязательно вне сферы действия http, которая выполнила свою работу через успешную 200, если вы не выбрали контракт, в соответствии с которым частичные данные являются ошибочными и, следовательно, 40x.

+0

Мои мысли в точности, однако (я думаю, я мог бы быть более ясным в моем вопросе), система зависит от данных, агрегированных из нескольких источников, и отдельные поля могут отсутствовать из-за недоступности источников по случайным причинам. Другими словами, неудача в цепочке связи. Вопрос заключается в том, что в сложной системе агрегации, где эти сбои могут быть общими, каков будет правильный код состояния для возврата. – guioconnor

 Смежные вопросы

  • Нет связанных вопросов^_^