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

Question

В настоящее время я разрабатываю очередь задач с RESTful API.

Чтобы справиться с задачей, работник должен оформить аренду.

PUT .../leases

Если в очереди задач есть доступные задачи, это будет выполнено успешно, будет создана аренда, и сервер ответит со статусом 201.

Я не уверен, как справиться с этим случаем, когда нет доступных задач. Невозможно создать аренду, если нет доступных задач. Какой код статуса HTTP подойдет для этого случая?

• 204 No Content - Клиент не сделал ничего плохого, но данных нет.

• 400 Bad Request - Это imho не применимо, так как означает, что «сервер не может понять запрос», что не так

Тем временем я думал, что этот подход может быть не идеальным. Либо я использую 503, как рекомендовано Брайаном, а также подкреплен отрывком REST на практике , либо я изменяю весь процесс.

Я думал об аренде, которую можно было создать предварительно. Это значит

1. PUT до /leases
2. Либо создайте аренду, назначьте задачу и ответьте 201, либо создайте предварительную аренду и ответьте 202
3. Предварительная аренда останется на некоторое время. Если задачи становятся доступными, они назначаются для предварительной аренды. Если в течение определенного периода времени нет задачи, аренда удаляется и сервер отвечает 410
4. Затем клиент должен начать снова с 1.

Answer 1

Поскольку ресурс контролируется сервером, и клиент ничего не может сделать, чтобы повлиять на результат, наиболее подходящим был бы код с диапазоном 500.

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

Answer 2

404 почти работает, но я считаю его ресурсом, с которым вы имеете дело, и вы делаете PUT для создания ресурса. Конечно, его не существует, поэтому вы создаете его.

Я бы согласился с вашей первой мыслью о 400 Bad Request в узком смысле этого определения. Но если вы расширите определение, включив в него что-то, что может пойти не так с запросом, это будет соответствовать вашей ситуации, и я думаю, что это приемлемо. Например, мы отправляем обратно 400, если запрос не соответствует ожидаемой нами схеме и если в ресурсе есть ошибки проверки. Для нашего сервиса, если мы можем программно определить, что это неверный запрос, мы отправим обратно 400.

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

Я не думаю, что 500 работают, потому что они более необработанные вещи, и это тот случай, с которым вы можете справиться и предоставить информационные ответы.

Надеюсь, это поможет.

Answer 3

404 - Not Found может быть использовано. Википедия суммирует его как:

Запрошенный ресурс не найден, но может снова стать доступным в будущем.Последующие запросы клиента допустимы.

Answer 4

IIS отправляет метод 405 Not Allowed, если я пытаюсь использовать неподдерживаемый метод (например, PUT, когда ожидается GET). И он отправляет 404 Not Found, если конечная точка вообще не существует.