Приносим извинения, если для этого есть ответ. Я нашел связанные вопросы (например, HTTP status code for a partial successful request), но не совсем то же самое.HTTP-ответ, получающий ресурс, когда доступны только частичные данные
Я создаю API, который возвращает данные, которые агрегируются из нескольких источников. Иногда некоторая критическая часть данных недоступна, и клиент должен быть осведомлен, а данные об ошибках включены в ответ.
Помимо серьезности недостающего поля (ов), остальная часть ресурса является действительной и полезной и может рассматриваться как частичное обновление (например, если у вас есть разрешения на просмотр части ресурса).
До сих пор варианты
- возвращение 200, считают его частичный ресурс, обрабатывать поля данных об ошибке в приложении, как вы бы с любыми другими данными
- возвращение 207, чтобы подчеркнуть, что это не в полной мере успешно, но 207 не является строго HTTP.
- возвращение 500 и обрабатывать успешно возвращаемые данные в приложении, как на 200
Я неравнодушен к варианту 1, но я не полностью убежден. Есть ли ясный способ справиться с этим? Возможно, определите конкретный content-type
?
Его субъективное, лично я бы сказал, что 500 подходит, поскольку данные ошибочны, поскольку они не соответствуют ожиданию соответствующего запроса. Вы можете добавить любые настраиваемые заголовки ответов, которые вам нравятся, например. 'X-Response-Type: partial' и поручить вашим клиентам ссылаться на значение перед обработкой данных ответа, если они получают код 500 –
Hi @AlexK. Я могу видеть дело на 500, но поскольку мы специально обрабатываем отсутствие данных в полезной манере, и ресурс может (и будет) возвращаться согласованным образом, 200 будет более уместным. Если вы хотите провести параллель, я бы сказал, что она похожа на обработанное исключение в коде, тогда как 500 будет аналогично необработанному исключению. Может быть, это не хорошая параллель? Мы возвращаем тип контента, который подчеркивает, что информация является частичной для оповещения клиента. Это имеет смысл с вашего POV? – guioconnor
Лично я возвращаю '200' и укажу, какие данные отсутствуют в теле ответа (ваш вариант №1). REST, насколько мне известно, очень ресурсоцентричен, и поскольку в вашем случае ресурс является ** действительным и полезным ** (и, другими словами, «он существует»), '200' кажется лучшим выбор. Возможно, также не рекомендуется обманывать «контент-тип», поскольку это может смутить некоторых клиентов. Просто пойдите с простым 'application/json' (или XML). Я также заметил, что многие API-интерфейсы имеют тенденцию «ошибаться» в направлении «200» и возвращать богатые статусы в качестве данных. Кажется более «идиоматическим» таким образом. – sigriston