1
00:00:03,880 --> 00:00:06,815
اسمحوا لي أن أبدأ

2
00:00:06,815 --> 00:00:11,165
بإعطائكم مقدمة سريعة لمدة 10 دقائق عن أساسيات الشبكات.

3
00:00:11,165 --> 00:00:14,045
وبالنظر إلى أن الوقت المتاح لدينا محدود،

4
00:00:14,045 --> 00:00:16,355
فإنني سأركز على تقديم

5
00:00:16,355 --> 00:00:21,191
الضروريات التي تحتاجونها لفهم كل موضوع من المواضيع.

6
00:00:21,191 --> 00:00:26,240
الآن، ما نغطيه في هذه الوحدة بالذات سيتطلب

7
00:00:26,240 --> 00:00:30,230
على الأقل فهمًا بدائيًا لكيفية

8
00:00:30,230 --> 00:00:34,255
عمل شبكات الكمبيوتر قبل أن نفهم لماذا نحتاج إلى استخدام HTTP،

9
00:00:34,255 --> 00:00:36,700
ولماذا نتواصل مع الخادم،

10
00:00:36,700 --> 00:00:42,485
وما هو سبب التأخير عندما تتحدث إلى خادم وما إلى ذلك.

11
00:00:42,485 --> 00:00:45,920
وأيضا، البروتوكولات المختلفة التي

12
00:00:45,920 --> 00:00:50,335
تحتاج إلى أن تكون على بينة من قبل أن تتمكن حتى من التواصل مع الخادم.

13
00:00:50,335 --> 00:00:53,540
لذلك، مع وضع كل هذا في الاعتبار

14
00:00:53,540 --> 00:00:58,945
، مقدمة سريعة لمدة 10 دقائق لأساسيات الشبكات.

15
00:00:58,945 --> 00:01:03,600
نبدأ في إدراك أن تطبيقات الويب لم تعد قائمة بذاتها.

16
00:01:03,600 --> 00:01:11,030
لديهم دائما اقتباس غير الاقتباس سحابة الخلفية دعم تطبيق الويب الخاص بك.

17
00:01:11,030 --> 00:01:13,535
الآن في هذه الأيام، كل شيء على السحابة.

18
00:01:13,535 --> 00:01:15,500
قريبا جدا سوف تكون على سحابة أيضا،

19
00:01:15,500 --> 00:01:19,455
على الأقل على سحابة تسعة مع بطانة الفضة.

20
00:01:19,455 --> 00:01:23,785
ولكن، بالنظر إلى أننا بحاجة إلى

21
00:01:23,785 --> 00:01:29,090
دعم جانب الخادم لتطبيقنا الزاوي للعمل بشكل صحيح،

22
00:01:29,090 --> 00:01:31,295
فسوف تستضيف الخادم.

23
00:01:31,295 --> 00:01:36,405
وفي هذه الأيام، يتم استضافة الخادم

24
00:01:36,405 --> 00:01:42,575
بسهولة تامة باستخدام إحدى خدمات البنية التحتية المستندة إلى السحابة،

25
00:01:42,575 --> 00:01:48,260
أشياء مثل خدمات الويب الأمازون أو Heroku أو Digital

26
00:01:48,260 --> 00:01:55,190
Ocean أو العديد من الخدمات الأخرى التي توفر دعم الخادم المستند إلى السحابة.

27
00:01:55,190 --> 00:01:59,235
لذا، ما هو متاح بالضبط على جانب الخادم؟

28
00:01:59,235 --> 00:02:06,744
عادة ما يكون لديك واجهة الخادم التي تتحدث إلى التطبيق الزاوي الخاص بك،

29
00:02:06,744 --> 00:02:14,615
بحيث هو منطق الخادم وخلف الكواليس يتواصل منطق الخادم مع

30
00:02:14,615 --> 00:02:23,665
تخزين مستمر مثل قاعدة بيانات حيث يتم تخزين البيانات الخاصة بك واستردادها من.

31
00:02:23,665 --> 00:02:26,130
عندما تدخل إلى عالم الشبكات،

32
00:02:26,130 --> 00:02:31,064
سوف يتم قصفها قريبا جدا مع 304 مختصرات صغيرة،

33
00:02:31,064 --> 00:02:36,230
أشياء كنت تعتقد أنك تعرف ما هي عليه من اللغة الإنجليزية العادية أو لديهم

34
00:02:36,230 --> 00:02:38,360
معنى أو

35
00:02:38,360 --> 00:02:42,375
غرض مختلف تماما عندما تواجههم في عالم الشبكات.

36
00:02:42,375 --> 00:02:44,470
لذلك دعونا نفحص عدد قليل منهم.

37
00:02:44,470 --> 00:02:49,020
لذلك في عالم الشبكات سوف تسمع الناس يتحدثون عبر بروتوكول HTTP.

38
00:02:49,020 --> 00:02:53,215
البروتوكول الذي يتم استخدامه للاتصال بين العميل والخادم.

39
00:02:53,215 --> 00:02:56,960
هذا هو بروتوكول طبقة التطبيق الذي سوف

40
00:02:56,960 --> 00:03:01,135
نتحدث لفترة وجيزة عن أكثر قليلا في بقية هذه المحاضرة.

41
00:03:01,135 --> 00:03:07,550
يحتاج بروتوكول HTTP لكي يعمل إلى عنوان URL ليتم توفيره إليه، وهو

42
00:03:07,550 --> 00:03:09,715
محدد موقع الموارد الموحد.

43
00:03:09,715 --> 00:03:15,205
لذلك هذه عبارة عن سلسلة من الأحرف مفصولة بخطوط مائلة،

44
00:03:15,205 --> 00:03:22,355
مع نقطتين HTTP أو نقطتين HTTPS مرفقة أمامه.

45
00:03:22,355 --> 00:03:25,547
وأنا متأكد من أنك إذا كنت قد استخدمت الشبكة العالمية،

46
00:03:25,547 --> 00:03:29,395
فأنت على دراية كبيرة بما تبدو عليه عناوين URL.

47
00:03:29,395 --> 00:03:33,230
الآن بالإضافة إلى ذلك، ستسمع الناس يتحدثون عن JSON،

48
00:03:33,230 --> 00:03:38,380
وليس صديقك Jason ولكن ترميز كائن JavaScript.

49
00:03:38,380 --> 00:03:43,610
لذا فإن تدوين كائن JavaScript

50
00:03:43,610 --> 00:03:49,660
هو إحدى طرق ترميز البيانات التي يتم شحنها من جانب الخادم إلى جانب العميل أو العكس.

51
00:03:49,660 --> 00:03:54,320
وأيضا سوف تسمع الناس يتحدثون عن XML بعد طريقة أخرى

52
00:03:54,320 --> 00:04:01,205
لترميز البيانات بينما هو في الشحن العابر بين العميل والجانب الخادم.

53
00:04:01,205 --> 00:04:08,375
الآن، أيضا سوف تسمع الناس يتحدثون عن بروتوكولات مستوى أعلى تسمى SOAP،

54
00:04:08,375 --> 00:04:14,045
وليس النوع الذي تستحم به ولكن SOAP كبروتوكول

55
00:04:14,045 --> 00:04:21,975
يسمح بالاتصال بين كيانات التوزيع داخل شبكتهم.

56
00:04:21,975 --> 00:04:25,295
وأيضا، سوف تسمع الناس يتحدثون عن ريست،

57
00:04:25,295 --> 00:04:29,505
وليس شيئا أن تحصل على الكثير من الذهاب من خلال هذه الدورة معينة،

58
00:04:29,505 --> 00:04:32,510
ريست أو نقل الدولة التمثيلية.

59
00:04:32,510 --> 00:04:36,200
سيكون لدي محاضرة أقصر

60
00:04:36,200 --> 00:04:40,970
مكرسة خصيصا لريست قليلا في وقت لاحق في هذه الوحدة.

61
00:04:40,970 --> 00:04:42,905
وفي عالم HTTP،

62
00:04:42,905 --> 00:04:45,990
ستسمع الناس يتحدثون عن GET و

63
00:04:45,990 --> 00:04:50,210
PUT و POST و DELETE وستتساءل،

64
00:04:50,210 --> 00:04:52,200
ماذا تعني جميعًا؟

65
00:04:52,200 --> 00:04:55,250
دعونا نتعلم قليلا عن هذه في

66
00:04:55,250 --> 00:05:01,245
هذه المحاضرة وأيضا محاضرة عن ريست التي سترى قليلا في وقت لاحق.

67
00:05:01,245 --> 00:05:05,020
أحد الأشياء الهامة التي تحتاج إلى فهمها عند

68
00:05:05,020 --> 00:05:10,120
الاتصال بخادم هو أن اتصال خادم العميل

69
00:05:10,120 --> 00:05:15,130
يسبب كمية غير متوقعة من التأخير أو كمية غير محددة من التأخير

70
00:05:15,130 --> 00:05:21,340
أثناء جلب البيانات أو تحميلها إلى الخادم من موقع العميل.

71
00:05:21,340 --> 00:05:23,270
وهذا يعني أنه داخل تطبيق موقع العميل الخاص بك،

72
00:05:23,270 --> 00:05:27,310
تحتاج إلى إبقاء المستخدم

73
00:05:27,310 --> 00:05:31,750
على علم بحقيقة أن شيئا ما يحدث وراء الكواليس وتكون

74
00:05:31,750 --> 00:05:35,335
قادرة على التعامل مع التأخير

75
00:05:35,335 --> 00:05:41,020
وربما لا تكون قادرة على الحصول على البيانات من جانب الخادم.

76
00:05:41,020 --> 00:05:45,490
من المحتمل جداً أنه عند محاولة الاتصال بخادم،

77
00:05:45,490 --> 00:05:47,765
قد يفشل اتصال الخادم، قد يقوم الخادم

78
00:05:47,765 --> 00:05:53,920
بإرجاع بيانات غير صحيحة أو قد يتسبب في حدوث خطأ في الاتصال.

79
00:05:53,920 --> 00:05:58,750
كل هذه يجب التعامل معها على جانب العميل الخاص بك بشكل مناسب بحيث

80
00:05:58,750 --> 00:06:04,450
يستمر التطبيق الخاص بك في العمل حتى في وجود هذه المشاكل.

81
00:06:04,450 --> 00:06:09,250
القفز إلى بروتوكول طبقة التطبيقات الأكثر شعبية

82
00:06:09,250 --> 00:06:12,880
المستخدمة للاتصال بين العميل والخادم،

83
00:06:12,880 --> 00:06:15,405
بروتوكول نقل النص التشعبي.

84
00:06:15,405 --> 00:06:18,585
ولكن هذا هو بروتوكول اتصال خادم العميل.

85
00:06:18,585 --> 00:06:20,800
الآن قد يكون ذلك أو لا يكون له معنى كبير بالنسبة

86
00:06:20,800 --> 00:06:23,532
لك إلا إذا كان لديك خلفية كافية في الشبكات،

87
00:06:23,532 --> 00:06:28,480
ولكن هذا هو بروتوكول يستخدم لترميز الرسائل التي

88
00:06:28,480 --> 00:06:31,330
تبادلتها بين تطبيق العميل الخاص بك

89
00:06:31,330 --> 00:06:35,375
وهو تطبيق الزاوي في هذه الحالة وجانب الخادم.

90
00:06:35,375 --> 00:06:38,620
لذلك يسمح لك بروتوكول HTTP هذا

91
00:06:38,620 --> 00:06:47,200
باسترداد المستندات المستندة إلى النص التشعبي من جانب الخادم، ويتم

92
00:06:47,200 --> 00:06:52,495
ترميز المعلومات التي يتم تنزيلها من جانب الخادم بشكل متزايد في أحد تنسيقات الترميز القياسية مثل JSON أو XML.

93
00:06:52,495 --> 00:06:55,750
ولكي تتمكن من التحدث إلى خادم،

94
00:06:55,750 --> 00:07:04,180
لديك الدعم من إجراءات HTTP المختلفة أو ما نشير إليه على أنه أفعال HTTP،

95
00:07:04,180 --> 00:07:07,135
الرأس، GET، POST، PUT،

96
00:07:07,135 --> 00:07:11,020
DELETE، TRACE، OPTIONS، و CONNECT.

97
00:07:11,020 --> 00:07:14,080
سنرى على وجه الخصوص

98
00:07:14,080 --> 00:07:24,395
الأفعال GET و PUT و POST و DELETE بمزيد من التفصيل عندما نفحص بروتوكول REST API بعد ذلك بقليل.

99
00:07:24,395 --> 00:07:27,670
كيف يعمل بروتوكول HTTP؟

100
00:07:27,670 --> 00:07:30,010
في بروتوكول HTTP،

101
00:07:30,010 --> 00:07:35,215
تقوم بإرسال طلب GET من تطبيق العميل الخاص بك إلى الخادم.

102
00:07:35,215 --> 00:07:39,780
ويتم ترميز هذا في شكل رسالة طلب HTTP.

103
00:07:39,780 --> 00:07:43,760
عادةً ما تحمل رسالة الطلب عنوان URL

104
00:07:43,760 --> 00:07:48,995
في رسالة الطلب تشير إلى ما تريد أن يرسل لك جانب الخادم.

105
00:07:48,995 --> 00:07:52,660
وهذه عادة رسالة GET إذا كنت تريد

106
00:07:52,660 --> 00:07:57,440
تنزيل البيانات من جانب الخادم.

107
00:07:57,440 --> 00:08:02,110
ستحدد أيضًا الخادم المحدد الذي تتصل به.

108
00:08:02,110 --> 00:08:04,864
عندما يتلقى الخادم طلبك،

109
00:08:04,864 --> 00:08:09,325
سيقوم الخادم باسترداد البيانات من تخزين البيانات الخاصة به،

110
00:08:09,325 --> 00:08:11,980
عادة قاعدة بيانات على جانب الخادم،

111
00:08:11,980 --> 00:08:14,250
ثم قم بحزم هذه البيانات

112
00:08:14,250 --> 00:08:20,420
بتنسيق مناسب وإرسال البيانات مرة أخرى إليك على جانب العميل الخاص بك.

113
00:08:20,420 --> 00:08:23,285
إذا كنت تحصل على شفرة HTML و CSS

114
00:08:23,285 --> 00:08:25,240
و JavaScript القياسية من جانب الخادم،

115
00:08:25,240 --> 00:08:27,310
فسيكون متصفحك قادرًا على تقديم ذلك.

116
00:08:27,310 --> 00:08:30,144
ولكن مع تطبيقات مثل Angular،

117
00:08:30,144 --> 00:08:32,830
فأنت تتصل في المقام الأول بالخادم ثم

118
00:08:32,830 --> 00:08:39,700
تسترد البيانات في شكل إما JSON أو XML في معظم الأحيان.

119
00:08:39,700 --> 00:08:44,200
باستثناء التنزيل الأولي لجميع الموارد المطلوبة

120
00:08:44,200 --> 00:08:49,245
لتطبيق Angular الخاص بك ليتم تنفيذها داخل متصفحك.

121
00:08:49,245 --> 00:08:51,090
لذلك كما رأينا سابقًا،

122
00:08:51,090 --> 00:08:59,139
يتطلب تطبيق HTTP إرسال رسائل بين العميل والخادم.

123
00:08:59,139 --> 00:09:03,615
يتم إرسال رسالة طلب عادةً من العميل إلى الخادم

124
00:09:03,615 --> 00:09:09,500
وتتكون رسالة الطلب من سطر طلب بالإضافة إلى مجموعة من الرؤوس،

125
00:09:09,500 --> 00:09:14,170
حيث تقوم بتوفير معلومات إضافية لتأهيل الطلب.

126
00:09:14,170 --> 00:09:17,410
سنرى استخدام مختلف الرؤوس والإعدادات

127
00:09:17,410 --> 00:09:23,425
في الرؤوس ونحن نذهب من خلال بعض التمارين في هذه الوحدة بالذات.

128
00:09:23,425 --> 00:09:27,045
يتم فصل سطر الطلب والرؤوس من نص

129
00:09:27,045 --> 00:09:31,280
رسالة الطلب بواسطة سطر فارغ واحد.

130
00:09:31,280 --> 00:09:34,300
قد يحتوي نص الرسالة على بيانات إضافية

131
00:09:34,300 --> 00:09:38,460
خاصة إذا كان العميل يرسل البيانات إلى جانب الخادم.

132
00:09:38,460 --> 00:09:40,735
على سبيل المثال عند إرسال نموذج،

133
00:09:40,735 --> 00:09:45,190
يتم ترميز المعلومات داخل النموذج في

134
00:09:45,190 --> 00:09:51,115
تنسيق JSON ثم يتم إرسالها إلى جانب الخادم من جانب العميل.

135
00:09:51,115 --> 00:10:00,374
بحيث يتم ذلك باستخدام رسالة POST أو PUT.

136
00:10:00,374 --> 00:10:06,140
بالنظر إلى التفاصيل الأكثر قليلاً لرسالة طلب HTTP،

137
00:10:06,140 --> 00:10:10,225
ستحتوي رسالة الطلب النموذجية في سطر الطلب على الطريقة التي تكون إما GET أو PUT أو POST

138
00:10:10,225 --> 00:10:13,735
أو DELETE أو بعض الأفعال الأخرى التي رأيتها سابقًا،

139
00:10:13,735 --> 00:10:19,260
ثم يتبعها عنوان URL وإصدار بروتوكول HTTP الذي تستخدمه للاتصال من العميل إلى جانب الخادم.

140
00:10:19,260 --> 00:10:23,250
عادةً ما يحتوي حقل الرأس

141
00:10:23,250 --> 00:10:30,020
على اسم حقل رأس ونقطتين وقيمة حقل الرأس هذا.

142
00:10:30,020 --> 00:10:36,090
ويمكن ترميز محتويات الجسم، كما ذكرت، إما بتنسيق JSON أو XML.

143
00:10:36,090 --> 00:10:39,355
في ما يلي مثال

144
00:10:39,355 --> 00:10:46,040
على رسالة طلب HTTP النموذجية التي قد يتم إرسالها إلى الخادم من العميل.

145
00:10:46,040 --> 00:10:48,000
لذا في رسالة الطلب هذه،

146
00:10:48,000 --> 00:10:52,540
نطلب من الخادم الاحتفاظ بصفحة index.html

147
00:10:52,540 --> 00:10:55,150
من جانب الخادم إلى جانب العميل بحيث

148
00:10:55,150 --> 00:10:58,100
يمكن عرضها في المتصفح على جانب العميل.

149
00:10:58,100 --> 00:11:03,790
عادةً ما يحتوي طلب مثل هذا على نص فارغ في رسالة الطلب.

150
00:11:03,790 --> 00:11:06,460
سيتم ترميز معظم المعلومات في

151
00:11:06,460 --> 00:11:11,755
سطر الطلب بالإضافة إلى رؤوس رسالة الطلب.

152
00:11:11,755 --> 00:11:15,935
عندما يرسل العميل الطلب إلى الخادم.

153
00:11:15,935 --> 00:11:22,120
سيقوم الخادم بمعالجة الطلب ثم إرسال رد إلى جانب العميل.

154
00:11:22,120 --> 00:11:26,150
يتم تنظيم رسالة الرد مرة أخرى، ثلاثة أجزاء،

155
00:11:26,150 --> 00:11:30,850
سطر حالة حيث يتم

156
00:11:30,850 --> 00:11:35,648
تخزين بعض المعلومات حول كيفية معالجة الطلب وما يتم إرساله مرة أخرى إلى العميل،

157
00:11:35,648 --> 00:11:40,270
وسوف تحتوي الرؤوس على تفاصيل إضافية لما هو

158
00:11:40,270 --> 00:11:45,145
موجود في رسالة الاستجابة ثم متبوعًا بخط فارغ،

159
00:11:45,145 --> 00:11:49,355
ثم النص الفعلي للرسالة.

160
00:11:49,355 --> 00:11:55,405
مثال على ما يمكن أن يتم تضمينه عادة

161
00:11:55,405 --> 00:11:59,875
في رسالة استجابة HTTP، في هذه الحالة، رسالة الاستجابة هذه تعود مع 200،

162
00:11:59,875 --> 00:12:03,260
وهو رمز حالة للرسالة.

163
00:12:03,260 --> 00:12:07,420
إذا رأيت 200 في سطر الطلب كرمز حالة،

164
00:12:07,420 --> 00:12:11,770
فهذا يعني أن طلبك كان ناجحًا وأن الخادم قادر

165
00:12:11,770 --> 00:12:16,920
على إرجاع البيانات التي طلبتها من جانب الخادم.

166
00:12:16,920 --> 00:12:22,180
ثم سيحتوي الرأس على توجيهات إضافية

167
00:12:22,180 --> 00:12:25,165
إلى جانب العميل بما

168
00:12:25,165 --> 00:12:29,425
في ذلك معلومات حول كيفية ترميز النص الفعلي للرسالة.

169
00:12:29,425 --> 00:12:31,705
ثم قد يحتوي النص الأساسي،

170
00:12:31,705 --> 00:12:34,565
إذا كنت قد طلبت صفحة index.html،

171
00:12:34,565 --> 00:12:39,670
سيحتوي نص الرسالة على رمز HTML

172
00:12:39,670 --> 00:12:45,515
لصفحة index.html كما ترى في هذا المثال هنا.

173
00:12:45,515 --> 00:12:53,955
واحدة من أجزاء من المعلومات في سطر الحالة التي أشير إليها باسم رمز الحالة.

174
00:12:53,955 --> 00:12:58,080
إذا كان الخادم قادرًا على معالجة طلبك بشكل

175
00:12:58,080 --> 00:13:01,852
صحيح، فسيرسل ردًا برمز حالة 200،

176
00:13:01,852 --> 00:13:04,330
مما يعني أن كل شيء على ما يرام على جانب الخادم

177
00:13:04,330 --> 00:13:07,685
ويقوم جانب الخادم بإرجاع البيانات بشكل صحيح.

178
00:13:07,685 --> 00:13:12,055
إذا كان الخادم غير قادر على معالجة الطلب لأي سبب من الأسباب،

179
00:13:12,055 --> 00:13:14,800
فسيتم ترميز هذه المعلومات في

180
00:13:14,800 --> 00:13:24,160
رمز الحالة في سطر الحالة الخاص برسالة الرد.

181
00:13:24,160 --> 00:13:28,355
تتضمن رموز الحالة المختلفة عادةً التي ستواجهها عند تلقي رد من جانب الخادم 201،

182
00:13:28,355 --> 00:13:30,985
مما يعني أنه عند محاولة إنشاء

183
00:13:30,985 --> 00:13:34,540
كائن على جانب الخادم، تم إنشاؤه بنجاح،

184
00:13:34,540 --> 00:13:39,100
أو 301 مما يعني أن كل ما تطلبه قد نقل بشكل

185
00:13:39,100 --> 00:13:42,365
دائم إلى موقع جديد

186
00:13:42,365 --> 00:13:46,965
وسيتم إرجاع عنوان URL للموقع الجديد لهذا المورد إلى جانب العميل الخاص بك.

187
00:13:46,965 --> 00:13:52,775
400s و 500s عادة ما تشير إلى أن هناك بعض المشاكل على جانب الملقم.

188
00:13:52,775 --> 00:13:57,310
404 هو شيء غالباً ما

189
00:13:57,310 --> 00:14:02,260
تصادفه عند طلب شيء غير موجود على جانب الخادم.

190
00:14:02,260 --> 00:14:05,620
وبالمثل، يعني 500 أن الخادم هو مجرد التخلي،

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

192
00:14:10,390 --> 00:14:14,445
هذه هي اثنين من رموز الخطأ الشائعة التي سوف تواجهها.

193
00:14:14,445 --> 00:14:20,355
الباقية لها معنى محدد كما هو مذكور في هذا الجدول هنا.

194
00:14:20,355 --> 00:14:24,483
هناك أكثر من رموز الحالة التي أعطيتها لك في هذا الجدول،

195
00:14:24,483 --> 00:14:27,963
ولكن هذه بعض من رموز الحالة الأكثر شيوعًا التي

196
00:14:27,963 --> 00:14:32,835
ستواجهها في رسالة رد قادمة من جانب الخادم.

197
00:14:32,835 --> 00:14:37,420
نقطة أخرى ذكرتها هي حقيقة أن الخادم قد ترميز

198
00:14:37,420 --> 00:14:46,880
البيانات بتنسيق معين مثل XML أو لغة الترميز الموسعة أو JSON،

199
00:14:46,880 --> 00:14:50,845
تنسيق ترميز كائن JavaScript.

200
00:14:50,845 --> 00:14:53,950
الآن عادة، في هذه الدورة بالذات،

201
00:14:53,950 --> 00:15:02,875
سنتعامل مع البيانات التي يتم ترميزها بشكل رئيسي في JSON.

202
00:15:02,875 --> 00:15:06,680
تتصل معظم التطبيقات من جانب العميل بما في ذلك تطبيقات الجوال هذه الأيام عادةً

203
00:15:06,680 --> 00:15:16,515
بالخادم ويكون تنسيق تبادل البيانات هو JSON افتراضيًا في معظم الحالات.

204
00:15:16,515 --> 00:15:22,125
هذا هو السبب في أنني سأقضي بضع دقائق في شرح لك حول JSON.

205
00:15:22,125 --> 00:15:27,785
إن تدوين كائن JavaScript أو JSON هو تنسيق تبادل بيانات خفيف الوزن.

206
00:15:27,785 --> 00:15:33,100
السبب في تنسيق بيانات JSON هو على وجه التحديد من

207
00:15:33,100 --> 00:15:38,685
اهتمامنا في هذه الدورة هو أن تدوين كائن جافا سكريبت،

208
00:15:38,685 --> 00:15:40,710
كما يوحي الاسم،

209
00:15:40,710 --> 00:15:46,840
خرائط بسهولة جدا إلى كائن جافا سكريبت الذي تستخدمه مع أي شفرة جافا سكريبت.

210
00:15:46,840 --> 00:15:50,430
لذا فإن

211
00:15:50,430 --> 00:15:53,725
تحويل كائن JavaScript إلى تدوين JSON والعكسي واضح للغاية.

212
00:15:53,725 --> 00:15:57,420
تدوين JSON هو ما نسميه بأنه

213
00:15:57,420 --> 00:16:01,815
وصف ذاتي ويسهل فهمه تدوين.

214
00:16:01,815 --> 00:16:05,103
في تنسيق ترميز كائن JavaScript،

215
00:16:05,103 --> 00:16:11,040
يتم تنظيم البيانات بطريقة نظيفة ومحددة للغاية.

216
00:16:11,040 --> 00:16:14,693
يتم تنظيم هذا كمجموعة من الأسماء

217
00:16:14,693 --> 00:16:19,610
وأزواج القيم، وهذا منظم كقائمة مرتبة من القيم.

218
00:16:19,610 --> 00:16:23,375
يمكنك أن ترى مثالا على ذلك على الجانب الأيمن هنا.

219
00:16:23,375 --> 00:16:30,750
لقد استخدمنا بالفعل بيانات JSON هذه داخل تطبيقنا الزاوي بالفعل في وقت سابق.

220
00:16:30,750 --> 00:16:35,570
لذلك، الآن ترى لماذا يتم تنظيم البيانات بهذه الطريقة.

221
00:16:35,570 --> 00:16:41,220
وأنت تدرك أيضًا أنه من السهل جدًا التعامل مع

222
00:16:41,220 --> 00:16:47,850
هذه البيانات داخل JavaScript أو رمز TypeScript الخاص بك في تطبيق Angular الخاص بك.

223
00:16:47,850 --> 00:16:55,000
بهذا، أكمل نظرة عامة سريعة على أساسيات الشبكات.