Bonjour à l’équipe n8n academy,
J’ai récemment vu deux messages qui soulevaient des problèmes relatifs à la Section 3 du QS101 : Quickstart :
Après l’avoir résolu, j’ai remarqué que le problème provient d’une perte de contexte quand les étudiants passent de la Section 2 à la Section 3 du cours, et d’informations manquantes dans les instructions de la Section 3.
La cause profonde est que ces nœuds HTTP requièrent deux en-têtes HTTP (x-assessment-id et X-API-KEY). À la Section 2, le cours guide les utilisateurs pour ajouter l’x-assessment-id via « Send Headers » et ajouter la X-API-KEY via les credentials.
Cependant, à la Section 3, les instructions disent de réutiliser soit les credentials de la Section 2, soit d’ajouter l’x-assessment-id dans les credentials (ce qui est l’inverse de l’instruction de la Section 2), et elles ne mentionnent pas du tout la X-API-KEY.
Un étudiant a mal lu et a remplacé ses credentials actuels en passant de X-API-KEY à x-assessment-id, ce qui a aussi causé l’échec de sa Section 2 qui fonctionnait, et il n’a aucune idée de comment le corriger.
Concernant la réutilisation des credentials, les étudiants ne peuvent pas simplement copier-coller le nœud car la Section 3 utilise HTTP Request comme un outil d’agent plutôt que comme un nœud normal. En conséquence, ils doivent ajouter un nouvel outil HTTP, configurer à nouveau les credentials, et risquent probablement de manquer le champ « Send Headers ».
Je propose quelques façons de réduire ce problème :
(1) Unifier le matériel des deux sections pour indiquer quelle paire clé-valeur va dans les credentials et laquelle va dans Send Headers.
(2) À la Section 3, nous pourrions leur donner à nouveau des instructions explicites sur comment configurer les credentials, tout comme nous l’avons fait à la Section 2. Ce serait un simple copier-coller, nécessitant des changements seulement à la Section 3. J’ai aussi remarqué ce modèle dans le cours Foundation, donc nous pourrions suivre cette approche.
(3) Peu probable, mais nous pourrions demander aux étudiants d’utiliser Multiple Header Auth. C’est ma préférence car les étudiants peuvent clairement voir et gérer deux en-têtes comme un seul, au lieu de nécessiter qu’ils se demandent comment les Credential Header Auth et Send Headers seront combinés, ce qui n’est correct que si la méthode d’authentification utilise Header. Et cela évite aussi le besoin pour les étudiants de copier-coller des nœuds HTTP pour les réutiliser, ce qui était initialement prévu pour éviter qu’ils ne manquent les champs Send Header, et cela pourrait échouer comme je l’ai mentionné dans le cas où un étudiant ne peut pas copier un nœud HTTP vers l’outil agent HTTP. Mais cette solution nécessitera de changer et d’auditer beaucoup de matériel, donc je ne pense pas que cela en vaut la peine.
