J'ai un ressort de démarrage de la botte api. J'ai conceptuellement 2 entités nommées Lieu et Adresse, où un Lieu DOIT avoir une Adresse. Mon problème est que je dois d'abord POSTER une entité Adresse puis POST mon entité Venue avec le lien auto de l'entité Adresse. Cela semblait correct jusqu'à ce que je commence à coder mon client de navigation. Je n'aime pas le fait que si, une fois l'adresse persistée dans la base de données, quelque chose est arrivé à rompre la connexion des utilisateurs avant que le lieu soit persistant, je finirais avec une entité indésirable dans ma base de données car elle ne serait pas associée avec n'importe quoi. Je peux coder mes clients pour revenir dans ces situations en supprimant l'adresse qui vient d'être créée, mais si mon api est utilisé par un tiers, alors j'ai un problème. Est-il possible de publier toutes mes données de sous-ressources en même temps que POST l'entité parente? Sinon, existe-t-il des stratégies communes pour balayer les enregistrements orphelins?Entité POST avec ses sous-ressources comme une transaction OU stratégie pour l'élimination des orphelins
Répondre
Voici quelques options à prendre en compte.
Si la même adresse est POSTée deux fois, il ne doit pas y avoir deux enregistrements dans la base de données. La façon de garantir cela est de normaliser l'entrée d'adresse puis de vérifier si cette adresse a déjà été ajoutée. Si cela a déjà été ajouté, renvoyez un conflit 409 ou 200 OK. Si une nouvelle adresse est en fait créée, vous pouvez renvoyer un 201 CREATED. Vous devez d'abord normaliser les données afin que plusieurs variations de la même adresse ne provoquent pas plusieurs entrées. Par exemple lors de la normalisation tourner tout "Smith St." et "smith street" et "Smith Str." dans "SMITH STREET". Vous pouvez appliquer cette logique à tous les champs de l'adresse. Ensuite, vous pouvez vérifier si cette adresse est déjà dans la base de données.
Si c'est trop de travail, alors ne considérez pas que Address soit sa propre table/collection dans le DB. Peut-être que l'adresse soit un champ dans le lieu. Si, à un moment donné, le code doit prendre une adresse d'un site et la mettre dans sa propre table, cela peut arriver au besoin.
Une autre idée consiste à avoir un service qui prend à la fois lieu et adresse en entrée. Peut-être que vous pouvez l'appeler VenueRequest. Cet objet contiendra deux champs principaux, Lieu et Adresse. Le service fera le travail de stocker à la DB l'adresse puis le lieu.
ok merci, je vais aller avec la première option, je pense. – gezinspace
Le problème est-il que l'utilisateur ajoute à nouveau la même adresse après la restauration de la connexion, ce qui entraîne la double adresse dans la base de données? Ou est-ce la préoccupation qu'ils ne procéderont jamais à ajouter le lieu de sorte que l'adresse qu'ils ont déjà ajouté est inutile? –
le souci est qu'ils ne procéderaient pas à ajouter le lieu afin que l'adresse déjà créée est inutile – gezinspace
parce que quand ils essaient à nouveau, ils vont soumettre toutes les données pertinentes ensemble et il va juste créer une nouvelle adresse, ce qui est bien mais l'adresse déjà créé est toujours là. – gezinspace