تحديث مقترح: توحيد إرشادات المادة بشأن تعيين بيانات اعتماد عقدة HTTP وأداة HTTP agent

مرحباً بفريق أكاديمية n8n،

شاهدت مؤخراً منشورين يثيران مشاكل من QS101: قسم البداية السريعة 3:

بعد حل المشكلة، لاحظت أنها تنشأ من فقدان السياق عندما ينتقل الطلاب بين القسم 2 والقسم 3 من الدورة، وكذلك من نقص المعلومات في تعليمات القسم 3.

السبب الجذري هو أن عقد HTTP هذه تتطلب رأسين HTTP (x-assessment-id وX-API-KEY). في القسم 2، توجه الدورة المستخدمين لإضافة x-assessment-id عبر “Send Headers” وإضافة X-API-KEY عبر بيانات الاعتماد.

لكن في القسم 3، تقول التعليمات إما إعادة استخدام بيانات الاعتماد من القسم 2 أو إضافة x-assessment-id في بيانات الاعتماد (وهو عكس تعليمات القسم 2)، ولا تذكر X-API-KEY على الإطلاق.

أحد الطلاب أساء القراءة وقام بتجاوز بيانات الاعتماد الحالية له من X-API-KEY إلى x-assessment-id، مما تسبب أيضاً في فشل القسم 2 الذي كان يعمل، ولا يعرف كيفية إصلاحه.

فيما يتعلق بإعادة استخدام بيانات الاعتماد، لا يمكن للطلاب ببساطة نسخ والصق العقدة لأن القسم 3 يستخدم HTTP Request كأداة وكيل وليس كعقدة عادية. نتيجة لذلك، يجب عليهم إضافة أداة HTTP جديدة وإعادة تعيين بيانات الاعتماد، وربما سيفقدون حقل “Send Headers”.

أقترح عدة طرق يمكنها تقليل هذه المشكلة:

(1) توحيد محتوى القسمين لتوجيه أي زوج مفتاح-قيمة يدخل بيانات الاعتماد وأيها يدخل Send Headers.

(2) في القسم 3، يمكننا أن نرشدهم بشكل صريح مرة أخرى حول كيفية إعداد بيانات الاعتماد، تماماً كما فعلنا في القسم 2. هذا سيكون نسخ بسيط، يتطلب تغييرات فقط في القسم 3. لاحظت أيضاً هذا النمط في دورة الأساس، لذلك يمكننا اتباع هذا النهج.

شكراً على الاقتراحات.

  1. لقد أضفت مزيداً من المعلومات في القسم 3.
  2. تم تحديث هذا
  3. لم أرغب في إدخال رؤوس مخصصة في الدورات الموجهة للمبتدئين. الفكرة هي التعلم المعزز من خلال التكرار. وهو نفس الأسلوب عندما أطلب منك تسمية وتصنيف سير العمل في كل مرة، وتسمية عقدك في كل مرة. المشكلة مع إعداد بيانات اعتماد واحدة هي أنهم قد ينسون القيام بها. عندما تبدأ للتو، ومن خلال تكرار الأشياء مراراً وتكراراً، ستتذكر القيام بهذا.

مع أطيب التحيات،

شكراً، جيمي، على إلقائك نظرة على ذلك. أتفق معك بخصوص النقطة الثالثة.

هناك شيء واحد أود إضافته وهو أنه بعد إضافة مزيد من المعلومات إلى القسم 3، فإن الخطوة القديمة السادسة (لقطة الشاشة أدناه) أصبحت زائدة عن الحاجة وتتعارض، لذا أعتقد أنه يمكننا التفكير في حذفها.

مرحباً @kristinker

تم إصلاح هذا.

مع أطيب التحيات،