Должен ли REST API защищать данные позади?

Question

В случае запросов DELETE, которые могут каскадироваться при удалении большого количества данных, должен ли мой REST API слепо продолжить или предупредить об этом и запросить подтверждение?

Я создаю API, который абстрагирует манипуляции сложными данными, хранящимися в реляционной БД. Удаление элемента, на который ссылаются другие элементы, следует логически удалить их, а затем выполнить каскад.

Простым примером (не связанным с реальным случаем) будет набор из трех таблиц «Дерево/Ветвь/Лист»: Листовые строки имеют внешний ключ к идентификатору филиала, а строки ветви аналогично включают в себя идентификатор дерева. API позволяет DELETE на любом уровне, но если вы удалите элемент дерева, он будет внутренне каскадом удалять все ветви и листы, которые прямо или косвенно ссылаются на него.

Так на DELETE запрос для дерева, API может:

• просто соблюдать и не все каскадные абсорбция
• отказаться на том основании, что это нарушило бы целостность, так что вы должны удалить все зависимые пункты вручную сначала (не очень практично)
• ничего не удалять и отправить заявление «это удалит 1 дерево, 31 ветви и 987 листьев, пожалуйста, подтвердите». Подтверждение может принимать форму дополнительного заголовка или суффикса в URL (/ force), но ни один из них не является очень REST, и по моему опыту такие вещи часто напрямую обходят при написании клиентов (на самом деле отправляется только запрос на удаление + подтверждение). Я также сомневаюсь в HTTP-коде для такого ответа.

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

Answer 1

Как обычно для таких вопросов, ответ действительно «зависит от». Лично, если бы на пути того, чтобы «подтвердить» большой делеции, я бы вместо этого:

1. Добавить заголовок depth или cascading. Вместо «ты действительно хочешь этого?» вы знаете, что попросите своих разработчиков убедиться, что они хотят сделать глубокое удаление. Depth является стандартным заголовком, но отображается в спецификации WebDAV. Cascading не было бы, поэтому вы можете префикс его X- в зависимости от того, чувствуете ли вы, что это хорошая идея =)
2. Ответьте на вопрос 409, если этот заголовок не указан. Вот как это делает WebDAV и имеет здесь большой смысл.

Однако, с моей точки зрения, я бы предпочел вариант «восстановить».