Код состояния HTTP, когда один запрос запрашивает слишком большой ресурс или слишком много из них

Кто-нибудь знает, какой код статуса HTTP является правильным для следующей ситуации?

Анонимный клиент может запросить набор элементов из коллекции RESTful API с помощью GET /collection/?range_start=100&range_end=200. Пример запроса возвращает список из 100 элементов (в JSON). Существует также ограничение, скажем 300, на количество элементов, которые клиент может запросить. Каким должен быть код состояния ответа, если клиент запрашивает 1000 экземпляров в диапазоне [100, 1100], что означает 700 элементов за лимит?

Должно ли это быть 400 Bad Request, 403 Forbidden, 409 Conflict, 416 запрошенного диапазона Не устраивает (?) или 422 Unprocessable Entity? Что бы вы порекомендовали?

Связанный вопрос и ответ предлагают 409, но ситуация несколько отличается: qaru.site/info/539309/...

Ответ 1

403 звучит как наиболее подходящий выбор. В основном это говорит: "Ну, э-э, вы этого не видите", что здесь в значительной степени.

10.4.4 403 Запрещено

Сервер понял запрос, но отказывается его выполнять.Авторизация не поможет, и запрос НЕ ДОЛЖЕН повториться. [...]

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

Все остальные коды кажутся мне конкретными значениями, которые дисквалифицируют их использование здесь.

400 не совсем подходит, потому что запрос действителен, и вы понимаете его просто отлично; он просто просит больше, чем вы готовы отправить сразу.

409 не подходит, потому что он специально связан с "состоянием" ресурса. (Это подходит для связанного с вами вопроса, потому что в этом случае ошибка добавляла к коллекции, которая была уже "полной". Однако в вашем случае это не тот ресурс, который имеет проблему, это запрос.) Кроме того,

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

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

416 относится к заголовку "Range", поэтому он вообще отсутствует.

417 также ссылается на поле заголовка (в данном случае "Ожидать" ), поэтому оно также выходит.

422 не подходит, потому что это специально означает, что вы отправили сущность, которая синтаксически корректна, но все еще сломана. Поскольку GET традиционно не имеют тела запроса (нет сущности), нет ничего необработанного. Если клиент был POSTing запроса, у вас может быть почти случай... но тогда вам также нужно будет сделать хороший пример, почему API RESTful требует POST, который ничего не обновляет.

(Я уверен, что на 47% код тоже не имеет большого смысла за пределами WebDAV... но похоже, что существуют возможные варианты использования. Только не этот.)

Ответ 2

Это всегда должно приводить к ошибке клиента 400 серии. Именно эта ошибка является выбором разработчика API/CGI. Я ожидал бы либо 405, 406, 416, либо "catch-all" 417. Разработчик api имеет контроль над текстом (телом) этих сообщений об ошибках, чтобы включить более полезную информацию.