اسمحوا لي أن أبدأ بإعطائكم
مقدمة سريعة لمدة 10 دقائق عن أساسيات الربط الشبكي.
كلما كنت أدرس اللغة الإنجليزية، كلما أدركت أنه فقط لاستخدام أجمل ميزاتها
الزاوي تحتاج إلى فهم العديد من FINs المتصلة المختلفة
قبل أن تتمكن من فهم ما تفعله مع الزاوي.
بحلول اللحظة التي تبدأ في مطاردة كل واحد من هذه FINs،
فإنها سوف تصبح دورات كاملة من تلقاء نفسها وقريبا جدا،
وأنا في نهاية المطاف تدريس كامل منهج علوم الكمبيوتر لك.
ولكن نظرا لحقيقة أن لدينا وقتا محدودا،
وسوف أركز على تقديم لكم الضروريات
التي تحتاجونها لفهم كل موضوع من المواضيع.
الآن، ما نغطيه في هذه الوحدة بالذات سيتطلب
على الأقل فهمًا بدائيًا لكيفية عمل شبكات الكمبيوتر
قبل أن نفهم لماذا نحتاج إلى استخدام HTTP،
ولماذا نتواصل مع الخادم.
ما هو سبب التأخير هو أنه عندما تتحدث إلى خادم،
وهلم جرا.
وأيضا، البروتوكولات المختلفة التي تحتاج إلى أن تكون على بينة
من قبل أن تتمكن حتى من التواصل مع الخادم.
لذا، مع وضع كل هذا في الاعتبار
، مقدمة سريعة لمدة 10 دقائق عن أساسيات الشبكات.
نبدأ في إدراك أن تطبيقات الويب لم تعد قائمة بذاتها.
لديهم دائما اقتباس إلغاء الاقتباس سحابة الخلفية دعم تطبيق الويب الخاص بك.
الآن، في هذه الأيام كل شيء على السحابة.
قريبا جدا سوف تكون على سحابة أيضا، على الأقل على سحابة تسعة مع بطانة فضية.
ولكن بالنظر إلى أننا بحاجة إلى دعم Silverside لتطبيقنا الزاوي للعمل بشكل صحيح،
فسوف تستضيف الخادم.
وهذه الأيام استضافة الخادم يتم بسهولة جدا باستخدام واحدة
من خدمات البنية التحتية القائمة على السحابة.
أشياء مثل Amazon أو خدمات الويب أو Heroku أو Digital Ocean
أو أشياء أخرى كثيرة توفر دعم خادم قائم على السحابة
يمكنك الاستفادة منه لتوفير دعم الخادم للتطبيق الزاوي الخاص بك.
لذلك، على جانب الخادم، ما هو متاح بالضبط على جانب الخادم؟
عادة ما يكون لديك واجهة أمامية للخادم تتحدث إلى التطبيق الزاوي الخاص بك.
لذا، هذا هو منطق الخادم وخلف الكواليس،
يتواصل منطق الخادم مع تخزين مستمر مثل قاعدة بيانات
حيث يتم تخزين بياناتك واستردادها من.
عندما تدخل عالم الشبكات، سوف تكون قريبا جدا قصفت
مع 304 اختصارات صغيرة.
الأشياء التي كنت تعتقد أنك تعرف ما هي عليه من اللغة الإنجليزية العادية
أو لديهم معنى
أو غرض مختلف تماما عندما تقابلهم في عالم الشبكات.
لذلك، دعونا نفحص عدد قليل منهم.
لذلك، في عالم الشبكات سوف تسمع الناس يتحدثون عبر بروتوكول HTTP.
البروتوكول الذي يتم استخدامه للاتصال بين العميل والخادم.
هذا هو بروتوكول طبقة التطبيق
الذي سوف نتحدث لفترة وجيزة عن أكثر قليلا في بقية هذه المحاضرة.
يحتاج بروتوكول HTTP لكي يعمل إلى عنوان URL ليتم توفيره إليه، وهو
محدد موقع الموارد الموحد.
لذا، هذه سلسلة من الأحرف مفصولة بخطوط مائلة في كل نقطتين TTP،
على https: المرفقة أمامه.
وأنا متأكد إذا كنت تستخدم شبكة الإنترنت العالمية،
كنت على دراية كبيرة مع ما تبدو عليه عناوين URL.
الآن، بالإضافة إلى ذلك، سوف تسمع الناس يتحدثون عن JSON،
وليس لصديقك Jason ولكن JavaScript Object Notation.
لذا، فإن تدوين كائن JavaScript هو أحد طرق ترميز البيانات التي يتم شحنها
من جانب الخادم إلى جانب العميل أو العكس.
وأيضا، سوف تسمع الناس يتحدثون عن XML،
بعد طريقة أخرى لترميز البيانات بينما هو في الشحن العابر
بين العميل وموقع الخادم.
الآن، وأيضا سوف تسمع الناس يتحدثون عن بروتوكولات مستوى أعلى تسمى SOAP،
وليس النوع الذي تستحم به، ولكن SOAP كبروتوكول
يسمح بالاتصال بين كيانات التوزيع داخل الشبكة.
وأيضا، سوف تسمع الناس يتحدثون عن ريست، وليس شيئا
أن تحصل على الكثير من الذهاب من خلال هذه الدورة بالذات.
REST أو نقل الدولة التمثيلية.
سيكون لدي محاضرة أقصر مكرسة خصيصا
لريست قليلا في وقت لاحق في هذه الوحدة.
وفي عالم HTTP، ستسمع الناس يتحدثون عن GET و
PUT و POST و DELETE، وستتساءل،
ماذا تعني جميعًا؟
دعونا نتعلم قليلا عن هذا في هذه المحاضرة،
وأيضا محاضرة عن ريست التي سترى قليلا في وقت لاحق.
أحد الأشياء الهامة التي تحتاج إلى فهمها عند التواصل
مع خادم هو أن اتصال خادم العميل يسبب كمية غير متوقعة
من التأخير أو كمية غير محددة من التأخير
أثناء جلب البيانات أو تحميلها إلى الخادم من جانب العميل.
لذا، مما يعني أنه ضمن تطبيق خادم العميل الخاص بك
تحتاج إلى إبقاء المستخدم
على علم بحقيقة أن شيئًا ما يحدث خلف الكواليس وتكون قادرًا على التعامل مع التأخير
وربما لا يتمكن من الحصول على البيانات من جانب الخادم.
من المحتمل جداً أنه عند محاولة الاتصال بخادم،
قد يفشل الاتصال بالخادم، قد يقوم
الخادم بإرجاع بيانات غير صحيحة أو قد يتسبب في حدوث خطأ في الاتصال.
كل هذه يجب التعامل معها على جانب العميل الخاص بك بشكل مناسب
بحيث التطبيق الخاص بك لا يزال يعمل حتى في وجود هذه المشاكل.
القفز إلى بروتوكول طبقة التطبيق الأكثر شعبية المستخدمة للاتصال
بين العميل والخادم، بروتوكول نقل النص التشعبي
ولكن هذا هو بروتوكول اتصال خادم العميل.
الآن، قد يكون ذلك أو لا يكون له معنى كبير بالنسبة
لك إلا إذا كان لديك خلفية كافية في الشبكات ولكن
هذا هو بروتوكول يستخدم لترميز الرسائل التي تقوم بتبادلها بين تطبيق العميل الخاص بك،
وهو تطبيق الزاوي في هذه الحالة، وجانب الخادم.
لذلك، يسمح لك بروتوكول HTTP هذا باسترداد المستندات المستندة إلى النص التشعبي
من جانب الخادم بشكل متزايد يتم
ترميز المعلومات التي يتم تنزيلها من جانب الخادم في أحد تنسيقات الترميز القياسية مثل JSON أو XML.
ولكي تتمكن من التحدث إلى خادم،
لديك الدعم من إجراءات HTTP المختلفة،
أو ما نشير إليه باسم أفعال HTTP: الرأس، GET، POST، PUT،
DELETE، TRACE، OPTIONCT، CONNECT.
سنرى على وجه الخصوص الأفعال GET و PUT و POST و DELETE بمزيد من التفصيل
عندما نفحص بروتوكول API الباقي في وقت لاحق قليلاً.
كيف يعمل بروتوكول HTTP؟
في بروتوكول HTTP، تقوم بإرسال طلب من تطبيق العميل الخاص بك إلى الخادم
ويتم ترميز هذا على شكل رسالة طلب HTTP.
عادةً ما تحمل رسالة الطلب عنوان URL في رسالة الطلب تشير إلى
ما تريد من جانب الخادم إرساله إليك
وهذا عادةً رسالة GET
إذا كنت تريد تنزيل البيانات من موقع الخادم.
وسوف تحدد أيضا أي خادم معين كنت التواصل مع.
عندما يتلقى الخادم طلبك، سيقوم الخادم
باسترداد البيانات من تخزين البيانات الخاصة به، عادة قاعدة بيانات على جانب الخادم،
ثم قم بحزم هذه البيانات في أربعة مناسبة مرة أخرى،
وإرسال البيانات مرة أخرى إليك على جانب العميل الخاص بك.
إذا كنت تحصل على شفرة HTML و CSS و javascript القياسية من جانب الخادم،
فسيكون متصفحك قادرًا على تقديم ذلك.
مرة أخرى مع تطبيقات مثل الزاوي، أنت تتصل في المقام الأول بالخادم
ثم استرداد البيانات في شكل إما JSON أو XML في معظم الأحيان.
باستثناء التنزيل الأولي لجميع الموارد
المطلوبة لتطبيق الزاوي ليتم تنفيذها داخل المتصفح الخاص بك.
لذلك، كما رأينا في وقت سابق يتطلب تطبيق هتب الرسائل ليتم إرسالها
بين العميل والخادم.
رسالة طلب يتم إرسالها عادة من العميل إلى الخادم،
وتتكون رسالة الطلب من سطر طلب بالإضافة إلى مجموعة من الرؤوس
حيث تقوم بتوفير معلومات إضافية لتأهيل الطلب.
سنرى استخدام مختلف الرؤوس
والإعدادات في الرؤوس ونحن نذهب من خلال بعض
التمارين في هذه الوحدة بالذات.
يتم فصل سطر الطلب والرؤوس
من نص رسالة الطلب بواسطة سطر فارغ واحد.
قد يحتوي نص الرسالة على بيانات إضافية خاصة
إذا كان العملاء إرسال البيانات عبر إلى جانب الخادم.
على سبيل المثال، عند إرسال نموذج،
يتم ترميز المعلومات داخل النموذج إلى تنسيق JSON
ثم يتم إرسالها إلى جانب الخادم من جانب العميل.
لذلك، سيتم ذلك باستخدام رسالة POST أو PUT.
بالنظر إلى تفاصيل أكثر قليلاً عن رسالة طلب HTTP،
ستحتوي رسالة الطلب النموذجية في سطر الطلب على الطريقة،
وهي إما GET أو PUT أو PAUSE
أو DELETE أو بعض الأفعال الأخرى التي رأيتها سابقًا.
ثم، متبوعًا بعنوان URL وإصدار بروتوكول HTTP
الذي تستخدمه للاتصال من العميل إلى جانب الخادم.
يحتوي حقل الرأس عادةً على اسم حقل رأس ونقطتين
وقيمة حقل الرأس هذا.
ويمكن ترميز محتويات الجسم، كما ذكرت، إما بتنسيق JSON أو XML.
في ما يلي مثال على رسالة طلب HTTP النموذجية
التي قد يتم إرسالها إلى الخادم من العميل.
لذا، في رسالة الطلب هذه، نطلب من الخادم الاحتفاظ
بصفحة index.hmtl من جانب الخادم إلى جانب العميل
بحيث يمكن عرضها في المتصفح على جانب العميل.
عادةً ما يحتوي طلب مثل هذا على نص فارغ في رسالة الطلب.
سيتم ترميز معظم المعلومات في سطر الطلب بالإضافة إلى رؤوس
رسالة الطلب.
عندما يرسل العميل الطلب إلى الخادم،
سيقوم الخادم بمعالجة الطلب ثم إرسال رد إلى جانب العميل.
يتم تنظيم رسالة الرد في ثلاثة أجزاء مرة أخرى. يتم
تخزين سطر حالة يحتوي على بعض المعلومات حول كيفية معالجة الطلب وما يتم إرساله مرة أخرى إلى العميل.
سوف تحتوي الرؤوس على تفاصيل إضافية لما هو موجود في رسالة الاستجابة،
ثم تليها سطر فارغ ثم النص الفعلي للرسالة.
مثال على ما يمكن أن يتم تضمينه عادة في رسالة استجابة HTTP.
في هذه الحالة، تعود رسالة الاستجابة هذه مع 200
وهو رمز حالة الرسالة.
إذا رأيت هنا، 200 في سطر الطلب كرمز حالة.
وهذا يعني أن طلبك كان ناجحًا
وأن الخادم قادر على إرجاع البيانات التي طلبتها من جانب الخادم.
وبعد ذلك، سيحتوي الرأس على توجيهات إضافية إلى جانب العميل،
بما في ذلك معلومات حول كيفية ترميز النص الفعلي للرسالة.
بعد ذلك، قد يحتوي النص الأساسي، إذا كنت قد طلبت صفحة HTML فهرس،
سيحتوي نص الرسالة على رمز HTML
لبدء فهرس صفحة HTML كما ترى في هذا المثال هنا.
واحدة من أجزاء من المعلومات في سطر الحالة التي أشير إليها باسم رمز الحالة هذا.
إذا كان الخادم قادرًا على معالجة طلبك بشكل صحيح،
فسيتم إرسال رد مع درجة حالة 200،
مما يعني أن كل شيء على ما يرام على جانب الخادم،
ويقوم جانب الخادم بإرجاع البيانات بشكل صحيح.
إذا كان الخادم غير قادر على معالجة الطلب لأي سبب من الأسباب،
فسيتم ترميز هذه المعلومات في رمز الحالة في
سطر الحالة هذا من رسالة الرد.
رموز الحالة المختلفة، عادة، التي سوف تواجهها
عند تلقي رد من جانب الخادم،
تتضمن 201 مما يعني أنه عند محاولة إنشاء كائن على جانب الخادم،
تم إنشاؤه بنجاح أو 301 مما يعني أن كل ما
تطلبه قد نقل بشكل دائم إلى موقع جديد،
وأنك على الموقع الجديد لهذا المورد
سيتم إرجاعه إلى جانب العميل الخاص بك.
400s و 500s تشير عادة إلى أن هناك بعض المشاكل على جانب الملقم.
A 404 هو شيء غالباً ما تصادفه عند
طلب شيء غير موجود على جانب الخادم.
وبالمثل، يعني 500 أن الخادم هو مجرد التخلي،
فإنه غير قادر على معالجة طلبك ومن ثم يرسل مرة أخرى خطأ خادم داخلي.
هذه هي اثنين من رموز الخطأ الشائعة التي سوف تواجهها.
الباقية لها معنى محدد كما هو مذكور في هذا الجدول هنا.
هناك أكثر من رموز الحالة التي أعطيتها لك في هذا الجدول
ولكن هذه هي بعض من رموز الحالة الأكثر شيوعا
التي سوف تواجهها في رسالة الرد القادمة من جانب الخادم.
نقطة أخرى ذكرتها هي حقيقة أن الخادم قد ترميز البيانات
بتنسيق معين مثل XML أو لغة الترميز الموسعة أو JSON،
تدوين كائن JavaScript لذلك.
الآن، عادة في هذه الدورة بالذات سوف نتعامل مع البيانات
التي يتم ترميزها بشكل رئيسي في JSON.
معظم التطبيقات، والتطبيقات من جانب العميل بما في ذلك تطبيقات الهاتف المحمول هذه الأيام،
وعادة ما تتصل مع الخادم
وتنسيق تبادل البيانات هو JSON افتراضيا في معظم الحالات.
هذا هو السبب في أنني سأقضي بضع دقائق في شرح لك حول JSON.
تدوين كائن javascript، أو JSON، هو تنسيق تبادل بيانات خفيف الوزن.
السبب في أن تنسيق بيانات JSON يهمنا على وجه التحديد في هذه الدورة هو أن
تدوين كائن javascript، كما يوحي الاسم، يتم
تعيينه بسهولة إلى كائن javascript تستخدمه مع أي من رموز javascript.
لذا، فإن تحويل كائن javascript إلى تدوين JSON
، والعكسي، أمر واضح للغاية.
إن تدوين JSON هو، ما نسميه،
كوصف ذاتي ويسهل فهمه تدوين.
في تنسيق تدوين كائن javascript،
يتم تنظيم البيانات بطريقة محددة نظيفة للغاية.
يتم تنظيم هذا كمجموعة من أزواج الاسم/القيمة،
وهذا منظم كقائمة مرتبة من القيم.
يمكنك رؤية مثال على ذلك على الجانب الأيمن هنا،
لقد استخدمنا بالفعل بيانات JSON هذه مع تطبيقنا الزاوي بالفعل في وقت سابق.
لذلك، الآن ترى لماذا يتم تنظيم البيانات بهذه الطريقة.
وأنت تدرك أيضًا أنه من السهل جدًا التعامل مع هذه البيانات
داخل صوت جافا سكريبت الخاص بك، يتم اكتشاف typescript في تطبيقك الزاوي.
مع هذا أكمل نظرة عامة سريعة على أساسيات الشبكات.
سننتقل الآن إلى وممارسة حيث سنقوم بإعداد خادم بدائي
كان يخدم بعض البيانات التي يمكننا الاتصال بها من تطبيقنا الزاوي
ومن ثم تبادل البيانات مع خادم.
الآن، سنقوم بتطوير خادم كامل في واحدة من الدورات اللاحقة،
كود عقدة JS ودورة تطوير جانب الخادم التي من
شأنها أن تأتي كدورة أخيرة في هذا التخصص.