Я бы сказал, что это скорее деталь реализации резервного хранилища. По всей вероятности, механизм хранения для обоих почти наверняка одинаков.
Я бы не изменил ни API DELETE, ни версию, потому что контракт на 100% одинаков по сети. Клиент не знает, как это реализовано за кулисами; они не должны в любом случае. Реализация должна измениться так, чтобы DELETE всегда приводил к мягкому удалению через некоторый момент времени (например, когда вы публикуете sh новую версию). Если вы используете DELETE, вы также открываете вещи, где клиенты могут делать то, что вы не собираетесь; например, запуск реального удаления с использованием указанной c версии API.
Необходимо изменить то, как старые API работают со всеми другими поддерживаемыми методами, такими как GET, POST, PATCH и т. Д. Более старые API должны давать 404 для мягко удаленного ресурса (подразумевая, что DELETE был постоянным). POST вероятно самый необычный случай. Это может вернуть 409, но это означает, что ресурс существует, или это может привести к обновлению, которое также восстанавливает существующего ресурса. Этот API, вероятно, даже продолжит возвращать 201, подразумевая, что ресурс был создан, когда он действительно был только что обновлен в хранилище.
Помните, что Передача репрезентативного состояния - это просто представление вашей бизнес-логики c. Сохраняйте API-интерфейсы одинаковыми (и, следовательно, клиенты ломаются) и корректируйте реализацию для адаптации к новым правилам. API DELETE не изменяется (и обычно не зависит от версии). Клиенты не знают, что делает человек за занавеской . Если по проводам дела продолжаются одинаково, клиенты не мудрее.
Надеюсь, это поможет.