Quelles sont les méthodes courantes de suppression des objets locaux/clients à l'aide de l'API REST ?

Question

Existe-t-il un modèle de conception commun pour envoyer les objets supprimés au demandeur (client de l'API) ?

Les défis que nous rencontrons :

1. Lorsque l'objet est supprimé complètement sur l'API, le client ne saura pas que l'objet a disparu et le conservera localement (car l'API ne montre que les objets modifiés après une certaine date).
2. Si nous activons la propriété de l'objet pour montrer qu'il est supprimé (ex. "deleted = TRUE") alors éventuellement le nombre d'objets dans l'API augmente et ralentit le taux de transfert.

Une autre option que nous envisageons est d'avoir des points de terminaison séparés sur l'API pour afficher la liste des objets supprimés uniquement (est-ce le modèle que quelqu'un utilise ?).

Je cherche le moyen le plus "RESTful" de supprimer des objets locaux.

Answer 1

La façon dont je le gère est une variation de votre numéro 1 : chaque élément a un last updated dans la base de données, et si un élément est supprimé, je crée une entrée dans une autre table des éléments supprimés, et sa valeur mise à jour correspond à la date de suppression.

Le client fait une requête demandant les "changements depuis X", qui est son propre stock local. last updated ... il renvoie les nouvelles données, et un tableau d'éléments supprimés. Ensuite, sur le client, je purge ces valeurs

Answer 2

Les données périmées sont toujours un problème dans les applications client/serveur. Si un client charge des données, puis qu'un objet est supprimé sur le serveur, et que le client envoie une demande DELETE, la chose RESTFUL à faire serait de renvoyer un 404, qui indique "non trouvé". Si le client sait que s'il envoie un DELETE, et obtient un 404, la ressource a été supprimée par en dessous...

Answer 3

Et si vous pensiez à votre ressource non pas comme une liste, mais plutôt comme un ensemble de modifications ?

Par exemple, changesets ce que vous avez dans git ou SVN.

De cette façon, il y a toujours une version "tête", et le client a toujours une certaine version, et la ressource est le changement entre la dernière et la tête du client.

Ainsi, vous pourrez appliquer ce que vous avez appris en examinant/utilisant les systèmes de contrôle de version.

Si vous avez besoin de quelque chose de plus complexe, la science qui se cache derrière s'appelle la transformation opérationnelle (OT). http://en.wikipedia.org/wiki/Operational_transformation