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

Question

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

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

PUT .../leases 

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

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

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

• 400 Bad Request - это имхо не применяется, так как это означает, что «запрос не может быть понят сервером», который не так

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

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

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

Answer 1

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

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

Answer 2

404 - Not Found может использоваться. Wikipedia подводит итог:

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

Answer 3

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

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

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

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

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

Answer 4

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