REST - Get collection with HTTP cache after delete

Question

I'm building a REST API which has the followings endpoints:

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

The mobile app shall gets all categories in the first time but later, it shall gets only the last modified categories (using Last-Modified HTTP header).

When a second app deletes a category, the server deletes it from the database. After the deletion, if others apps request the last modified categories, the server returns nothing about the deleted category and those apps don't remove it from their local database.

What is the best solution to this problem?

I'm thinking to use soft delete (a flag indicating that the category was deleted) and when the apps get the last modified categories, the server returns all modified categories since the date passed in HTTP header, including the deleted categories. However, if the apps request all categories (without Last-Modified header), the server returns all categories, except deleted (marked with the flag).

Is the presented solution the best one to this problem?

Answer 1

What is the best solution to this problem?

You might look to the web for inspiration. See RFC 7234 .

The high points being this: the web is a distributed system, and each client gets to manage their own local cache of representations of resources. Resources are delivered to the clients with metadata describing its freshness ; the client is entitled to re-use their local copy of state until it is stale. Successful unsafe operations on a resource automatically evict previously cached representations for that resource, and a mechanism ( 304 ) exists to allow the server to cheaply communicate to the client that a previously cached representation is still fresh.

But changes on the server don't automatically propagate to all clients, nor do they cascade from one resource to another. You need to instead think in terms of selecting the right freshness policy for each resource in isolation.

This is one of the reasons it is important to recognize that the design of your resource model needs to satisfy a different set of constraints than does the design of your data model.