Produits Entr'ouvert » Authentic 2

On fait déjà ça quelque part dans Publik ?
J’imaginais ce comportement enclenché par une requête GET sur /api/users/?uuids=<uuid1>,<uuid2>,<uuid3>,… mais il y a peut-être une approche plus élégante.

Réponse générale :

Pour une querystring, la manière de passer des arguments multiples c'est généralement de passer plusieurs fois le paramètre (en php c'est souvent codifié en ajoutant [] au nom du paramètre), donc ici ce serait ?uuids=<uuid1>&uuids=<uuid2>&....

Réponse particulière :

Non c'est vrai qu'on n'a pas ça ailleurs, mais on a pas deux web-services pareil à part la structure des réponses, on a jamais vraiment codifié la forme des requêtes. Dans ma réponse sur la commande je propose aussi de toute faire dans synchronization si tu veux, i.e. d'ajouter un paramètre full=true par exemple qui au lieu de simplement renvoyer les uuids renvoie les utilisateurs complets, avec un minimum de pagination.

Une autre solution serait de proposer une API à part pour faire des trucs "batch" /api/batch/, inspiré de SCIM, parce qu'avec la query-string on sera limité sur le nombre d'uuid qu'on peut passer (à 38 caractères par paramètre uuid, et disons une limite d'URL à 2Ko, on pourra en passer pas beaucoup plus de 50, ce qui niveau "batching" n'est pas terrible.

POST /api/batch/
{
   "atomic": False, (valeur par défaut)
   "requests": [
      {
         "path": "/api/user/",
         "query": {"uuid": "...."},
      },
....
}

c'est un peu pédestre mais c'est clair au moins.

Encore une autre possibilité c'est que si &modified_gt=.. prend bien en compte les changements sur les rôles, on a besoin de rien d'autre, /api/synchronization/ n'a à qu'à gérer un &since=... pour les suppressions d'utilisateurs, /api/user/ peut gérer tous les changements.

Ou encore on ajoute un include-deleted=true à /api/user/ qui renverrait des enregistrements de la forme {"uuid":...., "deleted": "<date-de-suppression>"}.

Voilà, choisis ton poison :)

J’ai poussé un commit de ce genre dans la branche, je regarde pour la pagination après lecture de la page de doc DRF à ce sujet avec lequel je ne suis pas très familier.

Benjamin Dauvergne a écrit :

je dirai de virer la partie pagination et de juste vérifier que la liste d'uuid ne dépasse pas une limite qu'on se fixe, comme 1000 (sans passer par MAX_PAGE_SIZE).

Ok.

Benjamin Dauvergne a écrit :

Je vois que tu as choisi de ne pas faire couiner a2 quand ça dépasse 1000, soit. Je pense que sur cette base tu peux continuer ton code de synchro mais tu n'auras pas les nouveaux utilisateurs.

Je regarde d’abord comment inclure #57564 par dessus ce travail, ensuite se posera la question des nouveaux usagers.