1
00:00:03,879 --> 00:00:07,577
اسمحوا لي أن أبدأ بإعطائكم

2
00:00:07,577 --> 00:00:11,705
مقدمة سريعة لمدة 10 دقائق عن أساسيات الربط الشبكي.

3
00:00:11,705 --> 00:00:18,769
كلما كنت أدرس اللغة الإنجليزية، كلما أدركت أنه فقط لاستخدام أجمل ميزاتها

4
00:00:18,769 --> 00:00:23,210
الزاوي تحتاج إلى فهم العديد من FINs المتصلة المختلفة

5
00:00:23,210 --> 00:00:27,165
قبل أن تتمكن من فهم ما تفعله مع الزاوي.

6
00:00:27,165 --> 00:00:29,929
بحلول اللحظة التي تبدأ في مطاردة كل واحد من هذه FINs،

7
00:00:29,929 --> 00:00:32,890
فإنها سوف تصبح دورات كاملة من تلقاء نفسها وقريبا جدا،

8
00:00:32,890 --> 00:00:37,539
وأنا في نهاية المطاف تدريس كامل منهج علوم الكمبيوتر لك.

9
00:00:37,539 --> 00:00:41,174
ولكن نظرا لحقيقة أن لدينا وقتا محدودا،

10
00:00:41,174 --> 00:00:43,554
وسوف أركز على تقديم لكم الضروريات

11
00:00:43,554 --> 00:00:48,344
التي تحتاجونها لفهم كل موضوع من المواضيع.

12
00:00:48,344 --> 00:00:53,383
الآن، ما نغطيه في هذه الوحدة بالذات سيتطلب

13
00:00:53,383 --> 00:00:57,829
على الأقل فهمًا بدائيًا لكيفية عمل شبكات الكمبيوتر

14
00:00:57,829 --> 00:01:01,310
قبل أن نفهم لماذا نحتاج إلى استخدام HTTP،

15
00:01:01,310 --> 00:01:03,587
ولماذا نتواصل مع الخادم.

16
00:01:03,587 --> 00:01:08,284
ما هو سبب التأخير هو أنه عندما تتحدث إلى خادم،

17
00:01:08,284 --> 00:01:09,394
وهلم جرا.

18
00:01:09,394 --> 00:01:14,111
وأيضا، البروتوكولات المختلفة التي تحتاج إلى أن تكون على بينة

19
00:01:14,111 --> 00:01:17,420
من قبل أن تتمكن حتى من التواصل مع الخادم.

20
00:01:17,420 --> 00:01:20,239
لذا، مع وضع كل هذا في الاعتبار

21
00:01:20,239 --> 00:01:25,950
، مقدمة سريعة لمدة 10 دقائق عن أساسيات الشبكات.

22
00:01:25,950 --> 00:01:30,575
نبدأ في إدراك أن تطبيقات الويب لم تعد قائمة بذاتها.

23
00:01:30,575 --> 00:01:38,015
لديهم دائما اقتباس إلغاء الاقتباس سحابة الخلفية دعم تطبيق الويب الخاص بك.

24
00:01:38,015 --> 00:01:40,370
الآن، في هذه الأيام كل شيء على السحابة.

25
00:01:40,370 --> 00:01:46,444
قريبا جدا سوف تكون على سحابة أيضا، على الأقل على سحابة تسعة مع بطانة فضية.

26
00:01:46,444 --> 00:01:55,939
ولكن بالنظر إلى أننا بحاجة إلى دعم Silverside لتطبيقنا الزاوي للعمل بشكل صحيح،

27
00:01:55,939 --> 00:01:58,615
فسوف تستضيف الخادم.

28
00:01:58,615 --> 00:02:06,140
وهذه الأيام استضافة الخادم يتم بسهولة جدا باستخدام واحدة

29
00:02:06,140 --> 00:02:09,619
من خدمات البنية التحتية القائمة على السحابة.

30
00:02:09,619 --> 00:02:15,860
أشياء مثل Amazon أو خدمات الويب أو Heroku أو Digital Ocean

31
00:02:15,860 --> 00:02:21,650
أو أشياء أخرى كثيرة توفر دعم خادم قائم على السحابة

32
00:02:21,650 --> 00:02:26,574
يمكنك الاستفادة منه لتوفير دعم الخادم للتطبيق الزاوي الخاص بك.

33
00:02:26,574 --> 00:02:32,363
لذلك، على جانب الخادم، ما هو متاح بالضبط على جانب الخادم؟

34
00:02:32,363 --> 00:02:39,814
عادة ما يكون لديك واجهة أمامية للخادم تتحدث إلى التطبيق الزاوي الخاص بك.

35
00:02:39,814 --> 00:02:45,349
لذا، هذا هو منطق الخادم وخلف الكواليس،

36
00:02:45,349 --> 00:02:52,790
يتواصل منطق الخادم مع تخزين مستمر مثل قاعدة بيانات

37
00:02:52,790 --> 00:02:56,905
حيث يتم تخزين بياناتك واستردادها من.

38
00:02:56,905 --> 00:03:01,069
عندما تدخل عالم الشبكات، سوف تكون قريبا جدا قصفت

39
00:03:01,069 --> 00:03:04,264
مع 304 اختصارات صغيرة.

40
00:03:04,264 --> 00:03:08,930
الأشياء التي كنت تعتقد أنك تعرف ما هي عليه من اللغة الإنجليزية العادية

41
00:03:08,930 --> 00:03:11,509
أو لديهم معنى

42
00:03:11,509 --> 00:03:15,610
أو غرض مختلف تماما عندما تقابلهم في عالم الشبكات.

43
00:03:15,610 --> 00:03:17,764
لذلك، دعونا نفحص عدد قليل منهم.

44
00:03:17,764 --> 00:03:22,159
لذلك، في عالم الشبكات سوف تسمع الناس يتحدثون عبر بروتوكول HTTP.

45
00:03:22,159 --> 00:03:26,379
البروتوكول الذي يتم استخدامه للاتصال بين العميل والخادم.

46
00:03:26,379 --> 00:03:29,000
هذا هو بروتوكول طبقة التطبيق

47
00:03:29,000 --> 00:03:34,409
الذي سوف نتحدث لفترة وجيزة عن أكثر قليلا في بقية هذه المحاضرة.

48
00:03:34,409 --> 00:03:41,004
يحتاج بروتوكول HTTP لكي يعمل إلى عنوان URL ليتم توفيره إليه، وهو

49
00:03:41,004 --> 00:03:42,955
محدد موقع الموارد الموحد.

50
00:03:42,955 --> 00:03:51,095
لذا، هذه سلسلة من الأحرف مفصولة بخطوط مائلة في كل نقطتين TTP،

51
00:03:51,095 --> 00:03:55,694
على https: المرفقة أمامه.

52
00:03:55,694 --> 00:03:58,530
وأنا متأكد إذا كنت تستخدم شبكة الإنترنت العالمية،

53
00:03:58,530 --> 00:04:02,655
كنت على دراية كبيرة مع ما تبدو عليه عناوين URL.

54
00:04:02,655 --> 00:04:06,435
الآن، بالإضافة إلى ذلك، سوف تسمع الناس يتحدثون عن JSON،

55
00:04:06,435 --> 00:04:11,607
وليس لصديقك Jason ولكن JavaScript Object Notation.

56
00:04:11,607 --> 00:04:19,026
لذا، فإن تدوين كائن JavaScript هو أحد طرق ترميز البيانات التي يتم شحنها

57
00:04:19,026 --> 00:04:22,850
من جانب الخادم إلى جانب العميل أو العكس.

58
00:04:22,850 --> 00:04:26,038
وأيضا، سوف تسمع الناس يتحدثون عن XML،

59
00:04:26,038 --> 00:04:30,574
بعد طريقة أخرى لترميز البيانات بينما هو في الشحن العابر

60
00:04:30,574 --> 00:04:33,240
بين العميل وموقع الخادم.

61
00:04:33,240 --> 00:04:41,584
الآن، وأيضا سوف تسمع الناس يتحدثون عن بروتوكولات مستوى أعلى تسمى SOAP،

62
00:04:41,584 --> 00:04:46,550
وليس النوع الذي تستحم به، ولكن SOAP كبروتوكول

63
00:04:46,550 --> 00:04:55,034
يسمح بالاتصال بين كيانات التوزيع داخل الشبكة.

64
00:04:55,034 --> 00:04:59,449
وأيضا، سوف تسمع الناس يتحدثون عن ريست، وليس شيئا

65
00:04:59,449 --> 00:05:02,479
أن تحصل على الكثير من الذهاب من خلال هذه الدورة بالذات.

66
00:05:02,479 --> 00:05:06,057
REST أو نقل الدولة التمثيلية.

67
00:05:06,057 --> 00:05:10,850
سيكون لدي محاضرة أقصر مكرسة خصيصا

68
00:05:10,850 --> 00:05:14,089
لريست قليلا في وقت لاحق في هذه الوحدة.

69
00:05:14,089 --> 00:05:18,410
وفي عالم HTTP، ستسمع الناس يتحدثون عن GET و

70
00:05:18,410 --> 00:05:23,449
PUT و POST و DELETE، وستتساءل،

71
00:05:23,449 --> 00:05:25,235
ماذا تعني جميعًا؟

72
00:05:25,235 --> 00:05:29,454
دعونا نتعلم قليلا عن هذا في هذه المحاضرة،

73
00:05:29,454 --> 00:05:34,459
وأيضا محاضرة عن ريست التي سترى قليلا في وقت لاحق.

74
00:05:34,459 --> 00:05:38,959
أحد الأشياء الهامة التي تحتاج إلى فهمها عند التواصل

75
00:05:38,959 --> 00:05:45,439
مع خادم هو أن اتصال خادم العميل يسبب كمية غير متوقعة

76
00:05:45,439 --> 00:05:48,350
من التأخير أو كمية غير محددة من التأخير

77
00:05:48,350 --> 00:05:54,454
أثناء جلب البيانات أو تحميلها إلى الخادم من جانب العميل.

78
00:05:54,454 --> 00:05:57,566
لذا، مما يعني أنه ضمن تطبيق خادم العميل الخاص بك

79
00:05:57,566 --> 00:06:00,409
تحتاج إلى إبقاء المستخدم

80
00:06:00,409 --> 00:06:07,970
على علم بحقيقة أن شيئًا ما يحدث خلف الكواليس وتكون قادرًا على التعامل مع التأخير

81
00:06:07,970 --> 00:06:14,149
وربما لا يتمكن من الحصول على البيانات من جانب الخادم.

82
00:06:14,149 --> 00:06:18,589
من المحتمل جداً أنه عند محاولة الاتصال بخادم،

83
00:06:18,589 --> 00:06:20,959
قد يفشل الاتصال بالخادم، قد يقوم

84
00:06:20,959 --> 00:06:27,224
الخادم بإرجاع بيانات غير صحيحة أو قد يتسبب في حدوث خطأ في الاتصال.

85
00:06:27,224 --> 00:06:31,129
كل هذه يجب التعامل معها على جانب العميل الخاص بك بشكل مناسب

86
00:06:31,129 --> 00:06:37,259
بحيث التطبيق الخاص بك لا يزال يعمل حتى في وجود هذه المشاكل.

87
00:06:37,259 --> 00:06:43,939
القفز إلى بروتوكول طبقة التطبيق الأكثر شعبية المستخدمة للاتصال

88
00:06:43,939 --> 00:06:48,569
بين العميل والخادم، بروتوكول نقل النص التشعبي

89
00:06:48,569 --> 00:06:51,785
ولكن هذا هو بروتوكول اتصال خادم العميل.

90
00:06:51,785 --> 00:06:54,019
الآن، قد يكون ذلك أو لا يكون له معنى كبير بالنسبة

91
00:06:54,019 --> 00:06:58,250
لك إلا إذا كان لديك خلفية كافية في الشبكات ولكن

92
00:06:58,250 --> 00:07:04,189
هذا هو بروتوكول يستخدم لترميز الرسائل التي تقوم بتبادلها بين تطبيق العميل الخاص بك،

93
00:07:04,189 --> 00:07:08,416
وهو تطبيق الزاوي في هذه الحالة، وجانب الخادم.

94
00:07:08,416 --> 00:07:14,300
لذلك، يسمح لك بروتوكول HTTP هذا باسترداد المستندات المستندة إلى النص التشعبي

95
00:07:14,300 --> 00:07:19,459
من جانب الخادم بشكل متزايد يتم

96
00:07:19,459 --> 00:07:25,298
ترميز المعلومات التي يتم تنزيلها من جانب الخادم في أحد تنسيقات الترميز القياسية مثل JSON أو XML.

97
00:07:25,298 --> 00:07:28,759
ولكي تتمكن من التحدث إلى خادم،

98
00:07:28,759 --> 00:07:35,270
لديك الدعم من إجراءات HTTP المختلفة،

99
00:07:35,270 --> 00:07:39,295
أو ما نشير إليه باسم أفعال HTTP: الرأس، GET، POST، PUT،

100
00:07:39,295 --> 00:07:44,634
DELETE، TRACE، OPTIONCT، CONNECT.

101
00:07:44,634 --> 00:07:51,069
سنرى على وجه الخصوص الأفعال GET و PUT و POST و DELETE بمزيد من التفصيل

102
00:07:51,069 --> 00:07:57,654
عندما نفحص بروتوكول API الباقي في وقت لاحق قليلاً.

103
00:07:57,654 --> 00:08:00,904
كيف يعمل بروتوكول HTTP؟

104
00:08:00,904 --> 00:08:08,487
في بروتوكول HTTP، تقوم بإرسال طلب من تطبيق العميل الخاص بك إلى الخادم

105
00:08:08,487 --> 00:08:12,990
ويتم ترميز هذا على شكل رسالة طلب HTTP.

106
00:08:12,990 --> 00:08:18,767
عادةً ما تحمل رسالة الطلب عنوان URL في رسالة الطلب تشير إلى

107
00:08:18,767 --> 00:08:22,279
ما تريد من جانب الخادم إرساله إليك

108
00:08:22,279 --> 00:08:24,920
وهذا عادةً رسالة GET

109
00:08:24,920 --> 00:08:29,805
إذا كنت تريد تنزيل البيانات من موقع الخادم.

110
00:08:29,805 --> 00:08:35,404
وسوف تحدد أيضا أي خادم معين كنت التواصل مع.

111
00:08:35,404 --> 00:08:39,320
عندما يتلقى الخادم طلبك، سيقوم الخادم

112
00:08:39,320 --> 00:08:45,215
باسترداد البيانات من تخزين البيانات الخاصة به، عادة قاعدة بيانات على جانب الخادم،

113
00:08:45,215 --> 00:08:49,160
ثم قم بحزم هذه البيانات في أربعة مناسبة مرة أخرى،

114
00:08:49,160 --> 00:08:53,595
وإرسال البيانات مرة أخرى إليك على جانب العميل الخاص بك.

115
00:08:53,595 --> 00:08:58,430
إذا كنت تحصل على شفرة HTML و CSS و javascript القياسية من جانب الخادم،

116
00:08:58,430 --> 00:09:00,746
فسيكون متصفحك قادرًا على تقديم ذلك.

117
00:09:00,746 --> 00:09:05,705
مرة أخرى مع تطبيقات مثل الزاوي، أنت تتصل في المقام الأول بالخادم

118
00:09:05,705 --> 00:09:12,919
ثم استرداد البيانات في شكل إما JSON أو XML في معظم الأحيان.

119
00:09:12,919 --> 00:09:16,730
باستثناء التنزيل الأولي لجميع الموارد

120
00:09:16,730 --> 00:09:22,259
المطلوبة لتطبيق الزاوي ليتم تنفيذها داخل المتصفح الخاص بك.

121
00:09:22,259 --> 00:09:29,929
لذلك، كما رأينا في وقت سابق يتطلب تطبيق هتب الرسائل ليتم إرسالها

122
00:09:29,929 --> 00:09:31,954
بين العميل والخادم.

123
00:09:31,954 --> 00:09:36,524
رسالة طلب يتم إرسالها عادة من العميل إلى الخادم،

124
00:09:36,524 --> 00:09:42,600
وتتكون رسالة الطلب من سطر طلب بالإضافة إلى مجموعة من الرؤوس

125
00:09:42,600 --> 00:09:47,309
حيث تقوم بتوفير معلومات إضافية لتأهيل الطلب.

126
00:09:47,309 --> 00:09:49,889
سنرى استخدام مختلف الرؤوس

127
00:09:49,889 --> 00:09:53,129
والإعدادات في الرؤوس ونحن نذهب من خلال بعض

128
00:09:53,129 --> 00:09:56,634
التمارين في هذه الوحدة بالذات.

129
00:09:56,634 --> 00:09:59,159
يتم فصل سطر الطلب والرؤوس

130
00:09:59,159 --> 00:10:04,500
من نص رسالة الطلب بواسطة سطر فارغ واحد.

131
00:10:04,500 --> 00:10:08,279
قد يحتوي نص الرسالة على بيانات إضافية خاصة

132
00:10:08,279 --> 00:10:11,754
إذا كان العملاء إرسال البيانات عبر إلى جانب الخادم.

133
00:10:11,754 --> 00:10:13,769
على سبيل المثال، عند إرسال نموذج،

134
00:10:13,769 --> 00:10:20,819
يتم ترميز المعلومات داخل النموذج إلى تنسيق JSON

135
00:10:20,819 --> 00:10:24,409
ثم يتم إرسالها إلى جانب الخادم من جانب العميل.

136
00:10:24,409 --> 00:10:28,860
لذلك، سيتم ذلك باستخدام رسالة POST أو PUT.

137
00:10:28,860 --> 00:10:33,610
بالنظر إلى تفاصيل أكثر قليلاً عن رسالة طلب HTTP،

138
00:10:33,610 --> 00:10:38,134
ستحتوي رسالة الطلب النموذجية في سطر الطلب على الطريقة،

139
00:10:38,134 --> 00:10:39,011
وهي إما GET أو PUT أو PAUSE

140
00:10:39,011 --> 00:10:43,455
أو DELETE أو بعض الأفعال الأخرى التي رأيتها سابقًا.

141
00:10:43,455 --> 00:10:48,360
ثم، متبوعًا بعنوان URL وإصدار بروتوكول HTTP

142
00:10:48,360 --> 00:10:52,500
الذي تستخدمه للاتصال من العميل إلى جانب الخادم.

143
00:10:52,500 --> 00:10:57,120
يحتوي حقل الرأس عادةً على اسم حقل رأس ونقطتين

144
00:10:57,120 --> 00:11:00,539
وقيمة حقل الرأس هذا.

145
00:11:00,539 --> 00:11:08,100
ويمكن ترميز محتويات الجسم، كما ذكرت، إما بتنسيق JSON أو XML.

146
00:11:08,100 --> 00:11:16,419
في ما يلي مثال على رسالة طلب HTTP النموذجية

147
00:11:16,419 --> 00:11:19,294
التي قد يتم إرسالها إلى الخادم من العميل.

148
00:11:19,294 --> 00:11:23,169
لذا، في رسالة الطلب هذه، نطلب من الخادم الاحتفاظ

149
00:11:23,169 --> 00:11:28,090
بصفحة index.hmtl من جانب الخادم إلى جانب العميل

150
00:11:28,090 --> 00:11:31,320
بحيث يمكن عرضها في المتصفح على جانب العميل.

151
00:11:31,320 --> 00:11:37,029
عادةً ما يحتوي طلب مثل هذا على نص فارغ في رسالة الطلب.

152
00:11:37,029 --> 00:11:42,309
سيتم ترميز معظم المعلومات في سطر الطلب بالإضافة إلى رؤوس

153
00:11:42,309 --> 00:11:44,559
رسالة الطلب.

154
00:11:44,559 --> 00:11:49,179
عندما يرسل العميل الطلب إلى الخادم،

155
00:11:49,179 --> 00:11:55,355
سيقوم الخادم بمعالجة الطلب ثم إرسال رد إلى جانب العميل.

156
00:11:55,355 --> 00:12:05,679
يتم تنظيم رسالة الرد في ثلاثة أجزاء مرة أخرى. يتم

157
00:12:05,679 --> 00:12:08,940
تخزين سطر حالة يحتوي على بعض المعلومات حول كيفية معالجة الطلب وما يتم إرساله مرة أخرى إلى العميل.

158
00:12:08,940 --> 00:12:16,149
سوف تحتوي الرؤوس على تفاصيل إضافية لما هو موجود في رسالة الاستجابة،

159
00:12:16,149 --> 00:12:22,654
ثم تليها سطر فارغ ثم النص الفعلي للرسالة.

160
00:12:22,654 --> 00:12:28,750
مثال على ما يمكن أن يتم تضمينه عادة في رسالة استجابة HTTP.

161
00:12:28,750 --> 00:12:32,766
في هذه الحالة، تعود رسالة الاستجابة هذه مع 200

162
00:12:32,766 --> 00:12:36,549
وهو رمز حالة الرسالة.

163
00:12:36,549 --> 00:12:40,644
إذا رأيت هنا، 200 في سطر الطلب كرمز حالة.

164
00:12:40,644 --> 00:12:43,360
وهذا يعني أن طلبك كان ناجحًا

165
00:12:43,360 --> 00:12:50,169
وأن الخادم قادر على إرجاع البيانات التي طلبتها من جانب الخادم.

166
00:12:50,169 --> 00:12:56,544
وبعد ذلك، سيحتوي الرأس على توجيهات إضافية إلى جانب العميل،

167
00:12:56,544 --> 00:13:02,735
بما في ذلك معلومات حول كيفية ترميز النص الفعلي للرسالة.

168
00:13:02,735 --> 00:13:07,099
بعد ذلك، قد يحتوي النص الأساسي، إذا كنت قد طلبت صفحة HTML فهرس،

169
00:13:07,099 --> 00:13:12,399
سيحتوي نص الرسالة على رمز HTML

170
00:13:12,399 --> 00:13:18,534
لبدء فهرس صفحة HTML كما ترى في هذا المثال هنا.

171
00:13:18,534 --> 00:13:27,210
واحدة من أجزاء من المعلومات في سطر الحالة التي أشير إليها باسم رمز الحالة هذا.

172
00:13:27,210 --> 00:13:31,304
إذا كان الخادم قادرًا على معالجة طلبك بشكل صحيح،

173
00:13:31,304 --> 00:13:34,990
فسيتم إرسال رد مع درجة حالة 200،

174
00:13:34,990 --> 00:13:37,450
مما يعني أن كل شيء على ما يرام على جانب الخادم،

175
00:13:37,450 --> 00:13:40,914
ويقوم جانب الخادم بإرجاع البيانات بشكل صحيح.

176
00:13:40,914 --> 00:13:45,294
إذا كان الخادم غير قادر على معالجة الطلب لأي سبب من الأسباب،

177
00:13:45,294 --> 00:13:50,259
فسيتم ترميز هذه المعلومات في رمز الحالة في

178
00:13:50,259 --> 00:13:53,309
سطر الحالة هذا من رسالة الرد.

179
00:13:53,309 --> 00:13:56,950
رموز الحالة المختلفة، عادة، التي سوف تواجهها

180
00:13:56,950 --> 00:13:59,210
عند تلقي رد من جانب الخادم،

181
00:13:59,210 --> 00:14:05,864
تتضمن 201 مما يعني أنه عند محاولة إنشاء كائن على جانب الخادم،

182
00:14:05,864 --> 00:14:11,230
تم إنشاؤه بنجاح أو 301 مما يعني أن كل ما

183
00:14:11,230 --> 00:14:13,750
تطلبه قد نقل بشكل دائم إلى موقع جديد،

184
00:14:13,750 --> 00:14:17,889
وأنك على الموقع الجديد لهذا المورد

185
00:14:17,889 --> 00:14:20,205
سيتم إرجاعه إلى جانب العميل الخاص بك.

186
00:14:20,205 --> 00:14:26,014
400s و 500s تشير عادة إلى أن هناك بعض المشاكل على جانب الملقم.

187
00:14:26,014 --> 00:14:31,210
A 404 هو شيء غالباً ما تصادفه عند

188
00:14:31,210 --> 00:14:35,110
طلب شيء غير موجود على جانب الخادم.

189
00:14:35,110 --> 00:14:38,860
وبالمثل، يعني 500 أن الخادم هو مجرد التخلي،

190
00:14:38,860 --> 00:14:43,620
فإنه غير قادر على معالجة طلبك ومن ثم يرسل مرة أخرى خطأ خادم داخلي.

191
00:14:43,620 --> 00:14:47,575
هذه هي اثنين من رموز الخطأ الشائعة التي سوف تواجهها.

192
00:14:47,575 --> 00:14:53,629
الباقية لها معنى محدد كما هو مذكور في هذا الجدول هنا.

193
00:14:53,629 --> 00:14:57,625
هناك أكثر من رموز الحالة التي أعطيتها لك في هذا الجدول

194
00:14:57,625 --> 00:15:00,519
ولكن هذه هي بعض من رموز الحالة الأكثر شيوعا

195
00:15:00,519 --> 00:15:06,220
التي سوف تواجهها في رسالة الرد القادمة من جانب الخادم.

196
00:15:06,220 --> 00:15:13,044
نقطة أخرى ذكرتها هي حقيقة أن الخادم قد ترميز البيانات

197
00:15:13,044 --> 00:15:21,534
بتنسيق معين مثل XML أو لغة الترميز الموسعة أو JSON،

198
00:15:21,534 --> 00:15:24,085
تدوين كائن JavaScript لذلك.

199
00:15:24,085 --> 00:15:28,690
الآن، عادة في هذه الدورة بالذات سوف نتعامل مع البيانات

200
00:15:28,690 --> 00:15:31,164
التي يتم ترميزها بشكل رئيسي في JSON.

201
00:15:31,164 --> 00:15:38,544
معظم التطبيقات، والتطبيقات من جانب العميل بما في ذلك تطبيقات الهاتف المحمول هذه الأيام،

202
00:15:38,544 --> 00:15:40,450
وعادة ما تتصل مع الخادم

203
00:15:40,450 --> 00:15:49,240
وتنسيق تبادل البيانات هو JSON افتراضيا في معظم الحالات.

204
00:15:49,240 --> 00:15:54,968
هذا هو السبب في أنني سأقضي بضع دقائق في شرح لك حول JSON.

205
00:15:54,968 --> 00:16:01,000
تدوين كائن javascript، أو JSON، هو تنسيق تبادل بيانات خفيف الوزن.

206
00:16:01,000 --> 00:16:09,279
السبب في أن تنسيق بيانات JSON يهمنا على وجه التحديد في هذه الدورة هو أن

207
00:16:09,279 --> 00:16:13,955
تدوين كائن javascript، كما يوحي الاسم، يتم

208
00:16:13,955 --> 00:16:20,480
تعيينه بسهولة إلى كائن javascript تستخدمه مع أي من رموز javascript.

209
00:16:20,480 --> 00:16:24,890
لذا، فإن تحويل كائن javascript إلى تدوين JSON

210
00:16:24,890 --> 00:16:26,924
، والعكسي، أمر واضح للغاية.

211
00:16:26,924 --> 00:16:30,350
إن تدوين JSON هو، ما نسميه،

212
00:16:30,350 --> 00:16:35,045
كوصف ذاتي ويسهل فهمه تدوين.

213
00:16:35,045 --> 00:16:38,230
في تنسيق تدوين كائن javascript،

214
00:16:38,230 --> 00:16:44,335
يتم تنظيم البيانات بطريقة محددة نظيفة للغاية.

215
00:16:44,335 --> 00:16:47,810
يتم تنظيم هذا كمجموعة من أزواج الاسم/القيمة،

216
00:16:47,810 --> 00:16:52,855
وهذا منظم كقائمة مرتبة من القيم.

217
00:16:52,855 --> 00:16:56,674
يمكنك رؤية مثال على ذلك على الجانب الأيمن هنا،

218
00:16:56,674 --> 00:17:03,980
لقد استخدمنا بالفعل بيانات JSON هذه مع تطبيقنا الزاوي بالفعل في وقت سابق.

219
00:17:03,980 --> 00:17:08,809
لذلك، الآن ترى لماذا يتم تنظيم البيانات بهذه الطريقة.

220
00:17:08,809 --> 00:17:15,503
وأنت تدرك أيضًا أنه من السهل جدًا التعامل مع هذه البيانات

221
00:17:15,503 --> 00:17:21,335
داخل صوت جافا سكريبت الخاص بك، يتم اكتشاف typescript في تطبيقك الزاوي.

222
00:17:21,335 --> 00:17:27,484
مع هذا أكمل نظرة عامة سريعة على أساسيات الشبكات.

223
00:17:27,484 --> 00:17:33,109
سننتقل الآن إلى وممارسة حيث سنقوم بإعداد خادم بدائي

224
00:17:33,109 --> 00:17:39,080
كان يخدم بعض البيانات التي يمكننا الاتصال بها من تطبيقنا الزاوي

225
00:17:39,080 --> 00:17:42,140
ومن ثم تبادل البيانات مع خادم.

226
00:17:42,140 --> 00:17:48,079
الآن، سنقوم بتطوير خادم كامل في واحدة من الدورات اللاحقة،

227
00:17:48,079 --> 00:17:52,400
كود عقدة JS ودورة تطوير جانب الخادم التي من

228
00:17:52,400 --> 00:17:56,669
شأنها أن تأتي كدورة أخيرة في هذا التخصص.