Подтвердить что ты не робот

Код состояния HTTP REST, если DELETE невозможно

Мой вопрос довольно общий для кода состояния HTTP, когда DELETE невозможно на ресурсе (но не в отношении прав пользователя).

У нас есть RESTful API для типа ресурса.

Метод DELETE разрешен на ресурсе, однако при некоторых условиях ресурс не может быть удален (если есть данные, привязанные к этому ресурсу).

Каков правильный код состояния HTTP для возврата к клиенту в этой ситуации?

Вот некоторые из возможностей, которые я собрал и почему это кажется неуместным в моем случае:

  • 403 (Запрещено): По большей части это связано с правами пользователя.
  • 405 (метод не разрешен): похоже, что API не предназначен для ответа на этот метод для этого типа ресурсов.
  • 409 (конфликт): кажется целесообразным, но клиент должен иметь возможность разрешить конфликт с API, но это не так.

Обновление: Связывание данных, которое предотвращает удаление ресурса, не может быть изменено с помощью REST API. Однако ресурс может быть "освобожден" по-другому, поскольку база данных, из которой поступают данные, также доступны другими приложениями, которые могут изменять состояние ресурса (SQL DELETE в БД всегда может это сделать).

4b9b3361

Ответ 1

Я бы сказал, что 409 является наиболее подходящим, учитывая его формулировку в RFC:

Код состояния 409 (конфликт) указывает, что запрос не мог    быть завершена из-за конфликта с текущим состоянием цели    ресурс. Этот код используется в ситуациях, когда пользователь может    способный разрешить конфликт и повторно отправить запрос. Сервер    СЛЕДУЕТ генерировать полезную нагрузку, которая содержит достаточную информацию для пользователя    признать источник конфликта.

(акцент мой)

Основываясь на моем понимании описания в вопросе, причина, по которой DELETE не разрешена, - это точно конфликт с текущим состоянием целевого ресурса. Как указано в RFC, полезная нагрузка ответа может указывать причину и, при желании, пользователь может ее решить. Я ничего не вижу в спецификации, что делает 409 неуместным только потому, что API не предлагает возможности разрешения конфликтов.

Ответ 2

Ответ

A 409 Conflict определенно неверен, если клиент не может разрешить конфликт и удалить запрос позже. То есть, если ресурс не отслеживает состояние, можно ли его удалить или нет, 409 Conflict не подходит.

A 403 Запрещено не обязательно означает, что не разрешено:

Однако запрос может быть запрещен по причинам, не связанным с учетными данными.
  - RFC 7231

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

Я думаю, что 405 Method Not Allowed - правильный путь.

Код статуса 405 (метод не разрешен) указывает, что метод, полученный в строке запроса, известен исходному серверу, но не поддерживается целевым ресурсом.
  - RFC 7231

Метод DELETE не поддерживается для этого ресурса. Это похоже на то, что вы описываете. Спецификация HTTP не имеет понятия типа ресурса - всего лишь ресурса. Бывает так, что люди группируют отдельные ресурсы под одной и той же конечной точкой для здравомыслия, но это просто удобство для разработчиков и пользователей. Что касается спецификации HTTP, /widgets/12 и /widgets/15 и /widgets/3453 - это три разных ресурса. Тот факт, что один и тот же объект представляет все три из этих ресурсов на сервере, совершенно не имеет значения. Я думаю, что "тип", о котором вы думаете, а HTTP - это просто детали реализации.