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

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

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

Должно ли это быть 400 неверных запросов, 403 запрещенных, 409 конфликтных, 416 запрашиваемых диапазонов неудовлетворенных (?) Или 422 необработанных объектов? Чтобы вы посоветовали?

Соответствующий вопрос и ответ предлагают 409, но ситуация немного отличается:https://stackoverflow.com/a/13463815/638546

Ответы на вопрос(2)

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

 Julian Reschke04 мар. 2013 г., 09:33
Нет, 417 нетпоймать все, У него очень специфический вариант использования.
Решение Вопроса

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

10.4.4 403 Запрещено

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

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

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

400 не совсем уместно, потому что запрос действителен, и вы это прекрасно понимаете; Это'просто просит больше, чем тыГотов отправить сразу.

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

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

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

416 конкретно относится кСпектр" заголовок, так чтов целом.

417 также относится к полю заголовка (в данном случае "Ожидать»), так что's также

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

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

 Akseli Palén04 мар. 2013 г., 10:04
@cHao хороший;) Спасибо
 Julian Reschke04 мар. 2013 г., 17:58
cHao: вы должны заглянуть в реестр кодов состояния IANA, а не RFC 2616. См.iana.org/assignments/http-status-codes/http-status-codes.xml
 cHao04 мар. 2013 г., 18:07
@JulianReschke: Опять же, эта ссылка указывает на RFC 4918. Код был создан для WebDAV, и я не знаюне видел ничего поддерживающего его использование вне этого контекста.
 cHao04 мар. 2013 г., 14:53
@JulianReschke: код состояния 422 определен вRFC 4918, который описывает WebDAV ... и больше нигде не могу найти. Если бы сервер отправил это мне назад, когда я занимался чем-то, не связанным с WebDAV, я был бы весьма удивлен, поскольку я бы не сталЯ даже не знаю, что код существует после просмотра RFC 2616. :)
 Julian Reschke04 мар. 2013 г., 18:50
@cHao: каждый раз, когда вы принимаете тела запросов JSON или XML, они синтаксически правильны, но что-то еще внутри них не позволяет вам выполнить запрос
 Julian Reschke04 мар. 2013 г., 09:33
Нет, 422 не относится к WebDAV. Но это действительно не правильный статус здесь.
 cHao04 мар. 2013 г., 18:38
@JulianReschke: Вы знаете пример реального использования этого? Я'мы еще не видели законного; дела яМы видели, что до сих пор лучше обслуживать 400 или 403.
 Julian Reschke04 мар. 2013 г., 18:26
@CHao: ссылка указывает на RFC 4918, потому что этогде это определено. Коды состояния HTTP расширяемы; тот'почему есть реестр? И да, 422 (и другие коды состояния, отличные от RFC2616) используются на практике вне WebDAV.
 cHao04 мар. 2013 г., 19:28
@Julian: если тело запроса находится в форме, которую сервер не может использовать, оно 's по определению неверно. Можно легко утверждать, что тыне принимает JSON или XML, но форматоснован на JSON или XML, который проверяется на конкретную схему ... и, следовательно, 400 будет соответствовать лучше. Но что угодно. :) ямы изменили основной аргумент против 422, так какПо крайней мере, возможно, полезно в других случаях, кроме этого.

Ваш ответ на вопрос