Produits Entr'ouvert » w.c.s.

Pour les données structurées c'est quand même mieux de passer dans le POST, plutôt qu'inventer des types se sérialisation sur la query string.

Ce serait envisageable d'obtenir une querystring qui ait du sens, c'est à dire ?list=a&list=b ?

Par exemple je ne serais pas bien chaud pour cette forme, qui selon ce qu'il y a en face pourrait faire qu'une des deux valeurs soit ignorée (typiquement si elle fait request.POST[key]), je préférerais &list=a,b qui évite ça, en entendant bien que c'est assez subjectif.

_~~

Alternativement, en étant strict sur le fait que la query string c'est du texte, lever une erreur quand on y passe autre chose, ça attraperait le problème évoqué plus tôt, de manière plus compréhensible.rep

Indiqué sur la PR : je ne suis pas fan de la magie proposée, qui va de plus planter si un des éléments contient une virgule. Personnellement je ne trouve pas problématique l'usage de |join:...

C'est problématique pour la raison évoquée que quand on l'oublie c'est difficile à détecter. Ensuite on peut remonter à la raison pour laquelle c'est oublié : on permet d'envoyer les listes telles quelles dans les données POST, pour un œil non averti on est donc dans une situation du type « des fois faut mettre |join, des fois pas », c'est dommage.

Mais l'objet du ticket c'est aussi de dire qu'actuellement on envoie une sérialisation inutilisable, qu'il ne faudrait pas.

Donc juste lever une erreur quand on essaye d'envoyer une liste, ça serait OK.

Après moi je ne comprend pas pourquoi la forme ?list=a&list=b serait inventer un truc, c'est le comportement par défaut de la lib requests, c'est géré automatiquement par les ListField DRF, c'est récupérable nativement en Django avec request.GET.getlist...

Après moi je ne comprend pas pourquoi la forme ?list=a&list=b serait inventer un truc

La phrase entière était : Pour les données structurées c'est quand même mieux de passer dans le POST, plutôt qu'inventer des types se sérialisation sur la query string.

Elle est une généralité sur les données structurées, pas spécifiquement posée pour les listes.

Puis sur la proposition de s'accorder sur ?list=a&list=b je note que je ne suis pas enthousiaste sur cette forme particulière. Je note aussi dans la PR :

Avec ma préférence pour que ça produise key=v1,v2, plutôt que key=v1&key=v2, mais ça peut se discuter un peu.

Et donc si on s'accorde pour minimiser le risque d'ignorer des données (je cite l'emploi de request.POST[key]) parce qu'il y a d'autres avantages ("c'est géré automatiquement par les ListField DRF"), pourquoi pas.

Automatic expiration