Rest API UPDATE/DELETE - проверить, существует ли ресурс или нет?

Question

Это принципиально передовая практика вопрос. В моем Rest API (который я сейчас работаю) у меня есть маршруты, соответствующие PUT и DELETE запросам по URL-адресам, таким как /resources/{resourceID}. За API лежит SQL DB.

В общем, выполнение DELETE или UPDATE запрос на несуществующий идентификатор ресурса в базах данных SQL не дает ошибку, только affectedRows возвращает 0.

Теперь у меня есть вопрос о том, как выполнить такой запрос правильно:

1. проверка, если ресурс с указанным идентификатором существует до UPDATE или DELETE (который включает в себя дополнительный запрос SQL)
2. вызвать witho запроса UPDATE/DELETE ut для проверки наличия и проверки результата запроса SQL и возврата HTTP 404 в случае, если affectedRows == 0?

Я лично предпочитаю более поздний. Но я могу думать о других СУБД (не SQL или не реляционных), где выполнение, UPDATE или DELETE запросов может не возвращать информацию о затронутых строках. Как действовать в таких случаях?

Answer 1

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

В основном:

• Для баз данных, измененные строки могут быть проверены, просто выполнить DELETE или UPDATE.
• Для баз данных, недоступных этой функции, сначала выполните запрос.

Answer 2

Как пользователь вашего API, я ожидал бы получить HTTP 404 для несуществующего ресурса, не зависящего от используемого метода HTTP.

Я пытаюсь удалить /users/ted, когда я действительно хотел удалить /users/tod, может стать большой проблемой. Без 404 Я бы предположил, что все работает нормально, и пользователь, которого я хотел удалить, фактически был удален. Когда на самом деле я удалил несуществующего пользователя.

Answer 3

В службе обновления я вернул 201 (CREATED) в случае, если ресурса нет, и вы хотите, чтобы ваши услуги были «толерантными», в противном случае возвратите 404, если вы хотите, чтобы ваши клиенты строго придерживались вашего протокола. В случае удаления вы можете вернуть 404, если клиент пытается удалить не существующий ресурс, или если вы отслеживаете удаленные ресурсы (некоторые службы делают это, они просто отмечают «удаленный» ресурс, например, чтобы предоставить клиентам возможность отменить операцию), вы можете вернуть 409 (CONFLICT), чтобы сообщить клиенту, что ресурс уже удален. В случае СУБД, которые не дают информации о затронутых строках, вы можете запросить ресурс до выполнения действия (будь то вставка, обновление или удаление). Это немного перебор, но если это единственный способ узнать о состоянии ресурса, прежде чем действовать на него, и вы не ожидаете проблем с производительностью, это может быть жизнеспособным решением.