Produits Entr'ouvert » w.c.s.

Je ne suis pas sûr de vouloir ça¹; mais si on fait ça il faut au moins que les autres endpoints sous /api/user/ se comportent de la même manière. (et des tests sur ces situations)

[1] (d'abord parce que ça vient comme réponse à une lenteur du provisioning)

Je peux aussi renvoyer un 404 pour pouvoir différencier les situations (il faut qu'on continue de considérer les 403, i.e. erreurs de signature comme des erreurs) mais il me faudra ensuite modifier le code des cellules. Dis mois ton choix entre 404 ou renvoyer une information vide et je ferai la modification aux autres endpoints.

Absolument pas enthousiaste sur la 404, mais ce que je proposerais c'est retourner {"err": 1, "data": []}, et modifier le endpoint pour également retourner cette structure quand tout va bien; et là il est peut-être nécessaire d'avoir une url d'endpoint différente pour ne pas casser la compatibilité (je ne sais pas trop les appels qui peuvent être faits à Vincennes), puis modifier combo en conséquence.

J'ai regardé ce qui était utilisé comme API à Vincennes et user/forms n'en fait pas partie; c'est donc uniquement utilisé par Combo. Ma préférence du coup c'est de simplement modifier l'API dans w.c.s. après avoir modifié combo pour gérer correctement la présente et la nouvelle API (#13521).

Très basiquement, la partie "retours" de ce patch deviendrait :

--- a/wcs/api.py
+++ b/wcs/api.py
@@ -461,7 +461,7 @@ class ApiUserDirectory(Directory):
                 d.update(form.get_json_export_dict(include_files=False))
             drafts.append(d)

-        return json.dumps(drafts,
+        return json.dumps({'err': 0, 'data': drafts},
                 cls=misc.JSONEncoder,
                 encoding=get_publisher().site_charset)

@@ -499,7 +499,7 @@ class ApiUserDirectory(Directory):
                 d.update(form.get_json_export_dict(include_files=False))
             forms.append(d)

-        return json.dumps(forms,
+        return json.dumps({'err': 0, 'data': forms},
                 cls=misc.JSONEncoder,
                 encoding=get_publisher().site_charset)

Dans la partie "ne pas retourner de liste mais un dictionnaire avec une clé data contenant la liste", il y a aussi le retour du _q_index de ApiFormdefsDirectory.

À rebaser, + préfixer le message de commit par "api: ".

Dans la documentation il y a aussi un exemple de retour de /api/user/drafts, à actualiser également.

Et qui c'est qui va acker si tu modifies mon patch ? :) C'est malin faut qu'on trouve une troisième personne maintenant.

:-D

On peut considérer qu'il est acké, allez... mais on va de toute façon attendre la MEP de jeudi 9 avant de pusher, donc plutôt attendre mardi 14 (et d'ici là, si un liégeois de passage...).

J'ai regardé ce qui était utilisé comme API à Vincennes et user/forms n'en fait pas partie; c'est donc uniquement utilisé par Combo. Ma préférence du coup c'est de simplement modifier l'API dans w.c.s. après avoir modifié combo pour gérer correctement la présente et la nouvelle API (#13521).

Je me trouvais donc à faire ce travail mais c'était "il y a environ un an". Avant de reprendre ici, il me semble nécessaire de refaire un tour exhaustif de nos installations.

Avec le patch proposé par Benjamin, on ne change pas tout :

• /api/formdefs/ et /api/category/<slug>/formdefs
• /api/user/forms
• /api/user/drafts/

• /api/forms/<formdef>/list

Donc je proposer de migrer ça aussi, afin que ceux qui jouent avec les API n'aient pas à deviner où ça a changé : quand c'était une liste, c'est maintenant une err/data. Ça simplifiera le discours à tenir pour informer du changement.

(avis bienvenus)

(avis bienvenus)

Déjà arriver à faire évoluer Vincennes pour gérer les deux; et puis pour /api/forms/<formdef>/list il y aura aussi Liège qui utilise cette API.

Le versionning c'était pas si mal finalement :)