04-09-2019, 04:55 PM
Si je dis "la route xxx/check renvoie sur le endpoint xxx en lui disant de juste checker le formulaire", alors il ne faut pas que j'ai un autre endpoint dont la route serait "xxx/check", faute de quoi les deux se marcheront dessus.
Ou dit autrement, si le endpoint écoute les routes "xxx" (parce que c'est "le endpoint xxx") et la route "xxx/check" (parce qu'il s'agit d'un endpoint de formulaire qui doit pouvoir être requêté pour "validateOnly") alors un autre endpoint "yyy" ne doit pas écouter cette route "xxx/check". Comme mes routes sont automatiques, le endpoint "xxx" écoute tout seul "xxx/", et "yyy" n'écoutera que "yyy/" mais si jamais j'ai yyy = "xxx/check", parce que c'est le nom du endpoint, alors j'ai 1 route écoutée par 2 endpoints: une fois parce qu'il s'agit du check de xxx et une autre fois parce qu'il existe un endpoint "xxx/check"...
Bon, après, avec un paramètre GET/POST, j'ai un soucis du même type: si jamais le endpoint voulait utiliser le paramètre GET "validateOnly" (pour une raison idiote : ) ), alors ce paramètre issu du endpoint empiètera sur le paramètre général servant à dire "fait juste la validation".
Ca me pousse à préférer, finalement, un header HTTP custom: y'a peu de risques que cela marche sur autre chose (et cela colle à l'aspect "global" de la chose: les headers HTTP de la requête me servent beaucoup à gérer des "trucs globaux", comme le format à retourner ou la langue de la page, donc, rajouter le comportement "check ou submit normal?" à ce niveau là, c'est pas déconnant).
Ok, je pense que je vais donc faire pareil, et piocher un nom de header bateau genre "X-Form-Action: validate" (histoire d'être extensible)
Ou dit autrement, si le endpoint écoute les routes "xxx" (parce que c'est "le endpoint xxx") et la route "xxx/check" (parce qu'il s'agit d'un endpoint de formulaire qui doit pouvoir être requêté pour "validateOnly") alors un autre endpoint "yyy" ne doit pas écouter cette route "xxx/check". Comme mes routes sont automatiques, le endpoint "xxx" écoute tout seul "xxx/", et "yyy" n'écoutera que "yyy/" mais si jamais j'ai yyy = "xxx/check", parce que c'est le nom du endpoint, alors j'ai 1 route écoutée par 2 endpoints: une fois parce qu'il s'agit du check de xxx et une autre fois parce qu'il existe un endpoint "xxx/check"...
Bon, après, avec un paramètre GET/POST, j'ai un soucis du même type: si jamais le endpoint voulait utiliser le paramètre GET "validateOnly" (pour une raison idiote : ) ), alors ce paramètre issu du endpoint empiètera sur le paramètre général servant à dire "fait juste la validation".
Ca me pousse à préférer, finalement, un header HTTP custom: y'a peu de risques que cela marche sur autre chose (et cela colle à l'aspect "global" de la chose: les headers HTTP de la requête me servent beaucoup à gérer des "trucs globaux", comme le format à retourner ou la langue de la page, donc, rajouter le comportement "check ou submit normal?" à ce niveau là, c'est pas déconnant).
Ok, je pense que je vais donc faire pareil, et piocher un nom de header bateau genre "X-Form-Action: validate" (histoire d'être extensible)