REST - Получить коллекцию с HTTP-кешем после удаления

Question

Я создаю REST API, который имеет следующие конечные точки:

GET /api/v1/categories - Get all categories
DELETE /api/v1/categories/$id - Delete a specific category

Мобильное приложение получает все категории в первый раз, но позже оно получает только последние измененные категории (используя Last-Модифицированный заголовок HTTP).

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

Как лучше всего решить эту проблему?

Я думаю использовать мягкое удаление (флаг, указывающий, что категория была удалена), и когда приложения получают последние измененные категории, сервер возвращает все измененные категории с даты, прошедшей в заголовке HTTP, включая удаленныекатегории.Однако если приложения запрашивают все категории (без заголовка Last-Modified), сервер возвращает все категории, кроме удаленных (помеченных флажком).

Является ли представленное решение лучшим решением для этой проблемы?

Answer 1

Как лучше всего решить эту проблему?

Вы можете обратиться к сети за вдохновением.См. RFC 7234 .

Важными моментами этого являются: сеть является распределенной системой, и каждый клиент получает возможность управлять своим собственным локальным кэшем представлений ресурсов.Ресурсы доставляются клиентам с метаданными, описывающими их свежесть ;клиент имеет право повторно использовать свою локальную копию штата, пока она не устареет.Успешные небезопасные операции с ресурсом автоматически удаляют ранее кэшированные представления для этого ресурса, и существует механизм ( 304 ), позволяющий серверу дешево сообщать клиенту, что ранее кэшированное представление все еще свежо.

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

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