Правильный код состояния HTTP для использования за пределами известных данных

Question

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

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

Данные внутреннего календаря, которые он использует для этого, периодически загружаются порциями. Так что, если пользователь делает запрос на дату, которая находится за (или до) загруженного диапазона дат, как должен реагировать API?

Изначально я думал об ошибке 4xx, но синтаксис и запрос технически верны. Попытка точно такого же запроса в другое время (когда данные за эту дату были загружены) привела бы к успешному ответу.

Глядя на ошибки 5xx, не кажется идеальным совпадением. 503 Сервис недоступен выглядит мне ближе всего, но, кажется, сосредоточиться на временных ошибках. Эта ситуация может длиться месяцами потенциально. Сложная проблема заключается в том, что сам API не знает, когда будет загружено больше данных, поэтому мы также не можем легко использовать заголовок Retry-After.

Что бы вы сделали? Спасибо!

Answer 1

Не используйте для этого код состояния HTTP 4xx или 5xx.

Их следует использовать только в том случае, если в запросе или ответе есть ошибка, а ее нет.

4xx ошибки означают, что запрос не выполнен (чего он не сделал), а 5xx означает ошибку сервера.

Определенно используйте ответ 2xx, либо 200 OK, либо 202 Принят

Answer 2

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

Также важно добавить заголовок Location с конечной точкой, обслуживающей фактическое состояние асинхронной операции, так что клиент можетконтролировать его на периодической основе.

Answer 3

Для объяснения, рассматриваемая конечная точка GET не возвращает ресурс, это просто инструмент для возврата конкретной информации об известных датах.

Это ресурс в REST sense.

Ключевая абстракция информации в REST - это ресурс.Любая информация, которая может быть названа, может быть ресурсом: документ или изображение, временная служба (например, «сегодняшняя погода в Лос-Анджелесе»), коллекция других ресурсов, не виртуальный объект (например, человек) и т. Д.,Другими словами, любая концепция, которая может быть целью гипертекстовой ссылки автора, должна соответствовать определению ресурса.Ресурс - это концептуальное отображение набора сущностей, а не сущности, которая соответствует сопоставлению в любой конкретный момент времени.

В частности, тот факт, что что-то является ресурсом, не существует ни в одномспособ зависит от реализации, используемой для обеспечения представления ресурса.

, если пользователь делает запрос на дату, которая выходит за пределы (или до) загруженного диапазона дат, как следуетответ API?

Обычно, возвращая тело сообщения, которое объясняет клиенту, в чем проблема, и включая в метаданные код ответа, который указывает характер ответа на общие компоненты.

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

В большинстве случаев, подобных этому, вы хотите сообщить об ошибке и указать кешам хранить ответ для latпоэтому используйте .

Поэтому вы захотите использовать код состояния 404 Не найдено .

Код состояния 404 (Не найдено) указывает на то, чтоисходный сервер не нашел текущего представления для целевого ресурса или не хочет раскрывать, что он существует.

404, по сути, является намеком на то, что написание target-uriнеправильно или что клиент не должен был запрашивать этот конкретный ресурс.В любом случае это проблема с запросом, и ее следует обрабатывать таким образом.

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

Обратите внимание, что стандарт HTTP явно указывает на тот факт, что 404 может использоваться в временных условиях:

AКод состояния 404 не указывает, является ли это отсутствие представления временным или постоянным