1
00:00:03,200 --> 00:00:09,035
اسمحوا لي أن أعطيك راحة قصيرة. حصلت لك هناك.

2
00:00:09,035 --> 00:00:11,535
ما قصدت قوله هو دعوني أقدم لكم

3
00:00:11,535 --> 00:00:16,420
لمحة موجزة عن نقل الدولة التمثيلية

4
00:00:16,420 --> 00:00:18,460
ما هو بالضبط ريست؟

5
00:00:18,460 --> 00:00:22,670
كيف يمكننا الاستفادة منه في تطبيق React الخاص بنا،

6
00:00:22,670 --> 00:00:26,130
وكيف يمكننا الاستفادة من هذا للتواصل مع الخادم؟

7
00:00:26,130 --> 00:00:29,455
كيف يدعم الخادم واجهة برمجة تطبيقات REST،

8
00:00:29,455 --> 00:00:34,615
وكيف يمكننا الوصول إلى واجهة برمجة تطبيقات REST من تطبيق React الخاص بنا؟

9
00:00:34,615 --> 00:00:39,230
دعونا نتحدث عن ذلك أكثر قليلا في هذا الدرس.

10
00:00:39,230 --> 00:00:47,680
أنا متأكد من أنك سمعت مصطلح خدمات الويب المذكورة في عالم تكنولوجيا المعلومات في كثير من الأحيان.

11
00:00:47,680 --> 00:00:49,895
ما هي خدمات الويب بالضبط؟

12
00:00:49,895 --> 00:00:55,520
خدمات الويب هي طريقة لتصميم أنظمة لدعم التشغيل البيني

13
00:00:55,520 --> 00:01:01,745
بين الأنظمة المتصلة عبر شبكة مثل الإنترنت كما نراه اليوم.

14
00:01:01,745 --> 00:01:05,504
هذا ما نشير إليه على أنه بنية موجهة نحو الخدمات.

15
00:01:05,504 --> 00:01:09,170
الآن، ما يعنيه هذا هو أنك توفر

16
00:01:09,170 --> 00:01:14,870
طريقة موحدة لجهازين متصلين بالإنترنت لتكون قادرة على

17
00:01:14,870 --> 00:01:17,720
التواصل مع بعضها البعض على

18
00:01:17,720 --> 00:01:24,660
مستوى طبقة التطبيقات للتطبيقات المستندة إلى الويب باستخدام معايير مفتوحة.

19
00:01:24,660 --> 00:01:29,175
الآن، لقد استخدمت الكثير من المصطلحات هناك

20
00:01:29,175 --> 00:01:32,000
دعونا نحاول كسرها وفهم

21
00:01:32,000 --> 00:01:36,195
قليلا عن كل من ذلك في هذه المحاضرة.

22
00:01:36,195 --> 00:01:43,390
نهجان شائعان يستخدمان لدعم خدمات الويب هما SOAP.

23
00:01:43,390 --> 00:01:49,550
خدمات الويب المستندة إلى بروتوكول الوصول إلى الكائنات البسيطة

24
00:01:49,550 --> 00:01:52,805
التي تستخدم لغة وصف خدمات الويب

25
00:01:52,805 --> 00:01:57,080
لتحديد كيفية اتصال نقطتي النهاية مع بعضها البعض.

26
00:01:57,080 --> 00:02:01,700
عادة ما يعتمد SOAP على استخدام XML

27
00:02:01,700 --> 00:02:07,340
كتنسيق للرسائل التي يتم تبادلها بين نقطتي النهاية.

28
00:02:07,340 --> 00:02:12,975
يستخدم نقل الحالة التمثيلية أو REST أيضًا معايير الويب،

29
00:02:12,975 --> 00:02:17,240
ولكن يمكن أن يكون تبادل البيانات بين نقطتي النهاية إما XML أو

30
00:02:17,240 --> 00:02:22,385
باستخدام JSON بشكل متزايد كتنسيق.

31
00:02:22,385 --> 00:02:29,705
طريقة REST للتشغيل البيني أبسط مقارنة بـ SOAP، وبالتالي،

32
00:02:29,705 --> 00:02:37,650
وجدت REST نشرًا أوسع كثيرًا في عالم خدمات الويب.

33
00:02:37,650 --> 00:02:41,215
عادة، يتم

34
00:02:41,215 --> 00:02:45,830
تسهيل اتصال العميل والخادم باستخدام REST حيث يدعم الخادم واجهة برمجة تطبيقات REST

35
00:02:45,830 --> 00:02:49,960
ويمكن للعميل بعد ذلك استدعاء نقاط النهاية REST API

36
00:02:49,960 --> 00:02:54,595
للحصول على معلومات أو لتحميل المعلومات إلى الخادم.

37
00:02:54,595 --> 00:02:59,885
مرة أخرى، لقد ذكرت الكلمة استدعاء نقاط نهاية أبي ريست،

38
00:02:59,885 --> 00:03:03,210
لذلك هذه هي بعض المصطلحات التي استخدمتها.

39
00:03:03,210 --> 00:03:07,385
دعونا توضيح بعض هذه في الشرائح القليلة القادمة.

40
00:03:07,385 --> 00:03:12,590
نقل الدولة التمثيلية هو نمط من بنية البرمجيات

41
00:03:12,590 --> 00:03:18,200
التي تم تصميمها خصيصا للوسائط التشعبية الموزعة عبر الشبكة العالمية.

42
00:03:18,200 --> 00:03:24,604
الآن تم تقديم هذا لأول مرة من قبل روي فيلدنغ في أطروحة الدكتوراه.

43
00:03:24,604 --> 00:03:26,990
الآن هذه إحدى أطروحات الدكتوراه

44
00:03:26,990 --> 00:03:29,660
التي أنتجت شيئًا مفيدًا للعالم.

45
00:03:29,660 --> 00:03:38,690
لذلك وجد هذا مرة أخرى الكثير من الجر في عالم خدمات الويب.

46
00:03:38,690 --> 00:03:42,800
هذه مجموعة من مبادئ الشبكة التي توضح كيفية

47
00:03:42,800 --> 00:03:47,300
توفير الموارد على الخوادم

48
00:03:47,300 --> 00:03:50,950
ويمكن الوصول إلى هذه الموارد من العملاء

49
00:03:50,950 --> 00:03:56,285
عن طريق تحديد الموارد باستخدام نقاط نهاية API.

50
00:03:56,285 --> 00:03:58,855
وفي إطار نقل الدولة التمثيلية،

51
00:03:58,855 --> 00:04:01,050
هناك أربعة مبادئ أساسية للتصميم.

52
00:04:01,050 --> 00:04:05,375
أولاً وقبل كل شيء، تم إنشاء REST على بروتوكول HTTP،

53
00:04:05,375 --> 00:04:11,365
لذلك يستخدم جميع أساليب HTTP التي رأيناها بالفعل في الدرس السابق.

54
00:04:11,365 --> 00:04:15,045
ثانيًا، تم تصميم REST لتكون عديمة الجنسية،

55
00:04:15,045 --> 00:04:17,930
مما يعني أن الخادم لا يخزن أي معلومات حول

56
00:04:17,930 --> 00:04:21,450
الحالة بعد اكتمال الاتصال.

57
00:04:21,450 --> 00:04:25,615
لذلك عندما يتلقى الخادم الطلب، يستجيب الخادم،

58
00:04:25,615 --> 00:04:29,110
وبعد ذلك لا يتذكر

59
00:04:29,110 --> 00:04:33,340
أي شيء أكثر عن المحادثة بين العميل والخادم.

60
00:04:33,340 --> 00:04:38,635
ثالثًا، تتمثل طريقة REST لتوفير الموارد

61
00:04:38,635 --> 00:04:44,945
في عرض بنية دليل مثل عناوين URL (محددات الموارد الموحدة - عناوين URL).

62
00:04:44,945 --> 00:04:50,230
رابعًا، يكون تنسيق تبادل البيانات عادةً JSON

63
00:04:50,230 --> 00:04:56,145
أو XML أو يمكن دعم كليهما باستخدام REST.

64
00:04:56,145 --> 00:05:03,350
أحد دوافع روي التي تقترح ريست كوسيلة لدعم خدمات الويب هو

65
00:05:03,350 --> 00:05:06,620
أنه يلتقط كل الأشياء الجيدة حول

66
00:05:06,620 --> 00:05:10,880
الشبكة العالمية والتي جعلت الشبكة العالمية ناجحة.

67
00:05:10,880 --> 00:05:14,040
استخدام مؤشرات الموارد

68
00:05:14,040 --> 00:05:18,320
الموحدة أو

69
00:05:18,320 --> 00:05:23,170
محددات مواقع الموارد الموحدة (URL) التي تسمح لك بمعالجة الموارد من خلال تحديدها كعنوان URL.

70
00:05:23,170 --> 00:05:29,390
والثاني، كونه بروتوكول يعيش على رأس بروتوكول HTTP.

71
00:05:29,390 --> 00:05:34,600
لقد عثر HTTP بالفعل على نشر واسع في الإنترنت.

72
00:05:34,600 --> 00:05:40,135
ثالثًا، دورة استجابة الطلب التي يعرف بها HTTP.

73
00:05:40,135 --> 00:05:42,420
لذلك تقوم بإرسال طلب،

74
00:05:42,420 --> 00:05:45,775
يتلقى الخادم طلبك، يعالج الطلب،

75
00:05:45,775 --> 00:05:49,530
يرسل الاستجابة للطلب،

76
00:05:49,530 --> 00:05:51,830
ويتلقى العميل الاستجابة،

77
00:05:51,830 --> 00:05:54,765
ويعمل بناءً على ذلك، وقد ينشئ طلبات أخرى.

78
00:05:54,765 --> 00:05:58,580
لذا، فإن هذا النهج لدورة استجابة الطلب

79
00:05:58,580 --> 00:06:03,115
راسخ بشكل جيد للغاية مع HTTP وشبكة الويب العالمية.

80
00:06:03,115 --> 00:06:08,505
الآن، بروتوكول HTTP كما رأينا في وقت سابق،

81
00:06:08,505 --> 00:06:13,650
وسوف نستخدم جميع الأفعال المختلفة التي يوفر HTTP.

82
00:06:13,650 --> 00:06:15,520
على وجه التحديد، GET و

83
00:06:15,520 --> 00:06:18,635
PUT و POST و DELETE

84
00:06:18,635 --> 00:06:23,480
لتتمكن من تحديد العمليات التي يجب القيام بها على الموارد المخزنة على جانب الخادم.

85
00:06:23,480 --> 00:06:27,470
على سبيل المثال، إذا قمت بإجراء طلب HTTP GET،

86
00:06:27,470 --> 00:06:30,125
فأنت تطلب من الخادم إرجاع المورد.

87
00:06:30,125 --> 00:06:32,415
إذا قمت بإجراء طلب POST،

88
00:06:32,415 --> 00:06:35,415
فأنت تطلب من الخادم إنشاء مورد جديد.

89
00:06:35,415 --> 00:06:36,670
إذا قمت بإجراء طلب PUT،

90
00:06:36,670 --> 00:06:39,650
فأنت تطلب من الخادم تحديث مورد موجود.

91
00:06:39,650 --> 00:06:42,170
وإذا قمت بإصدار طلب DELETE،

92
00:06:42,170 --> 00:06:45,020
فأنت تطلب من الخادم حذف المورد

93
00:06:45,020 --> 00:06:48,070
الذي تم تعريفه بواسطة عنوان URL معين.

94
00:06:48,070 --> 00:06:51,735
أيضا، فإنه يحاول الحفاظ على إديمبوتنس.

95
00:06:51,735 --> 00:06:56,165
بعض العمليات، عندما يتم تنفيذها بشكل متكرر،

96
00:06:56,165 --> 00:06:58,225
لن يسبب أي تغيير في الحالة.

97
00:06:58,225 --> 00:07:02,085
بعض العمليات الأخرى، إذا قمت بها على التوالي،

98
00:07:02,085 --> 00:07:05,170
فإنها قد تتسبب في تغيير الحالة.

99
00:07:05,170 --> 00:07:08,780
لذلك عليك أن تكون حذرا حول العمليات التي يمكن أن تتكرر دون

100
00:07:08,780 --> 00:07:14,395
أي عواقب ضارة والتي يجب القيام بها بعناية فائقة.

101
00:07:14,395 --> 00:07:21,864
في عالم REST، غالبًا ما تسمع أشخاصًا يتحدثون عن الأسماء والأفعال والتمثيلات.

102
00:07:21,864 --> 00:07:27,875
الآن، سنقوم بتوضيح كل واحدة من هذه بمزيد من التفصيل في الشرائح القليلة القادمة.

103
00:07:27,875 --> 00:07:31,760
تشير الأسماء على وجه التحديد إلى الموارد

104
00:07:31,760 --> 00:07:36,320
وعادة ما يتم تحديد هذه الموارد من خلال عناوين URL الخاصة بها وهذه غير مقيدة.

105
00:07:36,320 --> 00:07:40,700
الأفعال هي القيد وهذه تحدد الإجراءات التي يتعين

106
00:07:40,700 --> 00:07:45,010
القيام بها على الموارد والتمثيلات كما نرى.

107
00:07:45,010 --> 00:07:47,285
عندما تحتاج المعلومات إلى نقلها

108
00:07:47,285 --> 00:07:49,910
من الخادم إلى العميل أو من العميل إلى الخادم،

109
00:07:49,910 --> 00:07:51,855
كيف يمكنك ترميز المعلومات.

110
00:07:51,855 --> 00:07:56,520
عادة، إما باستخدام JSON أو باستخدام XML.

111
00:07:56,520 --> 00:08:01,895
المورد هو التجريد الرئيسي الذي يعمل REST حولها.

112
00:08:01,895 --> 00:08:06,810
لذلك، يتم استخراج المعلومات في شكل مورد

113
00:08:06,810 --> 00:08:12,475
ويتم تحديد المورد عن طريق تحديده باستخدام عنوان URL.

114
00:08:12,475 --> 00:08:18,395
لذا، يمكن

115
00:08:18,395 --> 00:08:20,720
تحديد أي معلومات يمكن تضمينها وإتاحتها كمورد.

116
00:08:20,720 --> 00:08:26,980
قطعة من المعلومات مثل الطقس الحالي في هونغ كونغ يمكن أن يكون موردًا،

117
00:08:26,980 --> 00:08:29,345
يمكن أن تكون صورة

118
00:08:29,345 --> 00:08:33,985
موردًا، يمكن أن تكون معلومات أسعار الأسهم موردًا وما إلى ذلك.

119
00:08:33,985 --> 00:08:38,920
لذا، مهما كان ما تعرفه كجزء من المعلومات التي قد يهتم بها العميل،

120
00:08:38,920 --> 00:08:41,430
يمكن تحديده كمورد.

121
00:08:41,430 --> 00:08:44,045
يمكنك حتى التعامل مع الموارد كمجموعة من

122
00:08:44,045 --> 00:08:48,740
الموارد التي قد يرسلها الخادم إلى العميل.

123
00:08:48,740 --> 00:08:54,145
يتم توضيح مثال على كيفية تسمية الموارد هنا.

124
00:08:54,145 --> 00:09:03,355
لذلك نستخدم عناوين URI لتحديد المصدر.

125
00:09:03,355 --> 00:09:10,460
ستتيح لك القراءة السريعة لهذه المواصفات أو عناوين URI هنا بسهولة فهم ما نشير إليه باستخدام عناوين URI هذه.

126
00:09:10,460 --> 00:09:14,420
لذلك، على سبيل المثال، شيء ينتهي بأطباق/،

127
00:09:14,420 --> 00:09:19,315
تفترض تلقائيًا أن هذا يشير إلى مجموعة من الأطباق.

128
00:09:19,315 --> 00:09:22,795
ولكن أطباق/123 على سبيل المثال،

129
00:09:22,795 --> 00:09:28,250
قد يعني الطبق رقم 123 في هذه الحالة وهلم جرا.

130
00:09:28,250 --> 00:09:31,320
لذلك، فمن السهل جدا لحفظ ويمكنك تحديد

131
00:09:31,320 --> 00:09:34,650
مجموعة من الموارد وتكون قادرة على التعرف

132
00:09:34,650 --> 00:09:38,815
عليها كمجموعة ومن ثم تحميلها كمجموعة أو يمكنك

133
00:09:38,815 --> 00:09:43,965
تحديد مورد فردي ويقول أنك تريد هذا المورد معين.

134
00:09:43,965 --> 00:09:50,395
الآن، يمكن تنظيم هذه الموارد في تسلسل هرمي لمواصفات URI هذا.

135
00:09:50,395 --> 00:09:52,740
لذلك، أثناء اجتياز المسار،

136
00:09:52,740 --> 00:09:58,325
تذهب من أكثر عمومية إلى أكثر تحديدا من المورد.

137
00:09:58,325 --> 00:10:02,110
تمكنك بنية الدليل هذه من تحديد الموارد

138
00:10:02,110 --> 00:10:07,780
التي تستخدمها أو توفرها من جانب الخادم الخاص بك بسهولة بالغة.

139
00:10:07,780 --> 00:10:11,585
الجزء الثاني من واجهة برمجة تطبيقات REST هي الأفعال. على

140
00:10:11,585 --> 00:10:16,760
وجه الخصوص، نحن مهتمون في الأفعال الأربعة من HTTP GET، PUT

141
00:10:16,760 --> 00:10:19,140
، POST و DELETE.

142
00:10:19,140 --> 00:10:24,410
في هذه الحالة، سيتم تعيين هذه الأفعال إلى الإجراءات التي

143
00:10:24,410 --> 00:10:29,755
نريد أن يتم تنفيذها على المورد، على جانب الخادم.

144
00:10:29,755 --> 00:10:34,170
يعني GET أنك تريد إجراء عملية قراءة على المورد.

145
00:10:34,170 --> 00:10:39,980
لذا، مما يعني أن العميل الذي يرسل طلب GET يشير

146
00:10:39,980 --> 00:10:43,480
إلى الخادم أنه يريد الحصول على تمثيل

147
00:10:43,480 --> 00:10:46,380
لهذا المورد من جانب الخادم إلى جانب العميل.

148
00:10:46,380 --> 00:10:48,960
تعني POST أنك تريد إنشاء

149
00:10:48,960 --> 00:10:52,755
مورد جديد ثم ستقوم بتحديد تفاصيل المورد

150
00:10:52,755 --> 00:10:55,795
في التمثيل المستخدم

151
00:10:55,795 --> 00:10:59,799
لتحديد المورد ثم إرسال هذه المعلومات إلى جانب الخادم،

152
00:10:59,799 --> 00:11:03,285
بحيث يقوم الخادم بإنشاء هذا المورد نيابة عنك.

153
00:11:03,285 --> 00:11:06,370
سيكون PUT تعديل الموارد و

154
00:11:06,370 --> 00:11:09,955
DELETE كما تتوقع هو حذف الموارد.

155
00:11:09,955 --> 00:11:15,110
لذلك، كما ترون،

156
00:11:15,110 --> 00:11:19,180
يتم تعيين الأفعال الأربعة؛ GET، POST، PUT و DELETE، في عمليات CRUD الأربعة التي يمكنك

157
00:11:19,180 --> 00:11:24,035
تنفيذها على قاعدة بيانات تخزن هذه الموارد على جانب الخادم،

158
00:11:24,035 --> 00:11:27,815
وعمليات القراءة، CREATE، UPDATE، و DELETE.

159
00:11:27,815 --> 00:11:33,760
بمزيد من التفصيل، فإن HTTP GET هي طريقة لتحديد أنك

160
00:11:33,760 --> 00:11:36,950
تريد

161
00:11:36,950 --> 00:11:40,235
إرجاع المعلومات أو تمثيل المورد إلى العميل من جانب الخادم.

162
00:11:40,235 --> 00:11:43,890
لذلك، عند إصدار طلب GET إلى نقطة نهاية REST API،

163
00:11:43,890 --> 00:11:49,130
فأنت تطلب إما مجموعة من الموارد التي يمثلها

164
00:11:49,130 --> 00:11:57,530
URI أو مورد معين يتم تعريفه بواسطة معرف هذا المورد

165
00:11:57,530 --> 00:11:59,490
المعين، المحدد داخل عنوان URL.

166
00:11:59,490 --> 00:12:01,000
لذا، كما ترى في هذا المثال،

167
00:12:01,000 --> 00:12:03,800
إذا قلت، أطباق/452،

168
00:12:03,800 --> 00:12:08,320
فأنت تعني أن تقول أن الطبق رقم 452 مع

169
00:12:08,320 --> 00:12:13,075
معرف 452 يجب أن تعاد إلى جانب العميل.

170
00:12:13,075 --> 00:12:18,175
وبالمثل، يتم استخدام عملية POST كما رأينا لإنشاء المورد.

171
00:12:18,175 --> 00:12:20,065
لذلك، عند إنشاء المورد،

172
00:12:20,065 --> 00:12:26,920
سيكون محتوى وصف المورد في شكل تمثيل JSON أو

173
00:12:26,920 --> 00:12:29,790
تمثيل XML وسيتم تضمينه

174
00:12:29,790 --> 00:12:34,075
في نص رسالة الطلب التي يتم إرسالها إلى جانب الخادم.

175
00:12:34,075 --> 00:12:38,095
لذا، تتوقع عملية POST تمثيلاً

176
00:12:38,095 --> 00:12:42,870
للمورد بتنسيق JSON أو XML في نص رسالة الطلب.

177
00:12:42,870 --> 00:12:44,890
عندما يتلقى الملقم رسالة الطلب،

178
00:12:44,890 --> 00:12:49,960
يقوم الملقم بإنشاء هذا المورد على جانب الخادم ثم يقوم

179
00:12:49,960 --> 00:12:58,030
بإرجاع أو خطأ للإشارة إلى فشل إنشاء المورد.

180
00:12:58,030 --> 00:13:02,725
وبالمثل، يتم استخدام عملية PUT لتحديث مورد.

181
00:13:02,725 --> 00:13:06,315
عند القيام بعملية PUT على مورد على جانب الخادم،

182
00:13:06,315 --> 00:13:10,200
يمكنك إرسال التعديل مرة أخرى

183
00:13:10,200 --> 00:13:15,470
إما عن طريق تحديد التعديل الجزئي الذي تريد التأثير على

184
00:13:15,470 --> 00:13:20,200
مورد معين في نص رسالة الرد أو يمكنك إرسال

185
00:13:20,200 --> 00:13:25,345
التمثيل الكامل في نص الرسالة.

186
00:13:25,345 --> 00:13:28,705
اعتمادا على الترتيب بين العميل والخادم،

187
00:13:28,705 --> 00:13:37,195
يتوقع الملقم المعلومات التي سيتم تمريرها في نص رسالة الطلب.

188
00:13:37,195 --> 00:13:42,600
تقوم عملية DELETE كما تتوقع بحذف المورد الموجود.

189
00:13:42,600 --> 00:13:45,460
الآن، في هذه الحالة بالذات،

190
00:13:45,460 --> 00:13:49,670
بالطبع عملية DELETE ستكون idempotent لأنه إذا

191
00:13:49,670 --> 00:13:54,145
حاولت حذف مورد وكان المورد موجودًا، فسيتم حذفه.

192
00:13:54,145 --> 00:13:56,445
إذا كنت تحاول حذف مورد غير موجود،

193
00:13:56,445 --> 00:14:01,220
فلن يتسبب ذلك في أي تعديل آخر على جانب الخادم،

194
00:14:01,220 --> 00:14:06,165
باستثناء أن الخادم سيرد بخطأ يقول أن المورد غير موجود.

195
00:14:06,165 --> 00:14:12,530
ولكن، مع ذلك، DELETE هو مثال على عملية idempotent في هذه الحالة.

196
00:14:12,530 --> 00:14:16,510
وبالمثل، فإن عملية GET هي أيضًا عملية idempotent لأنها

197
00:14:16,510 --> 00:14:20,885
لا تجري أي تعديلات على المورد على جانب الخادم.

198
00:14:20,885 --> 00:14:26,925
ستقوم POST و PUT بالطبع بتعديل المورد على جانب الخادم،

199
00:14:26,925 --> 00:14:31,940
إما إنشاء مورد جديد أو تعديل مورد موجود على جانب الخادم.

200
00:14:31,940 --> 00:14:34,060
وبطبيعة الحال، فإن التمثيلات،

201
00:14:34,060 --> 00:14:36,730
كما كنت أؤكد،

202
00:14:36,730 --> 00:14:43,980
فإن التنسيقين الشائعين للتمثيل هما إما JSON أو XML.

203
00:14:43,980 --> 00:14:47,105
الجزء الأخير الذي نحتاج إلى التأكيد عليه هو

204
00:14:47,105 --> 00:14:51,060
أن جانب الخادم يجب أن يكون عديم الجنسية تمامًا،

205
00:14:51,060 --> 00:14:53,640
مما يعني أن جانب الخادم لا يتتبع

206
00:14:53,640 --> 00:14:59,145
حالة العميل لأنه إذا كان الخادم يحتاج إلى تتبع حالة العملاء،

207
00:14:59,145 --> 00:15:00,935
فلن يكون قابلاً للتطوير.

208
00:15:00,935 --> 00:15:05,160
لذلك، لتنفيذ قابل للتحجيم من جانب الخادم،

209
00:15:05,160 --> 00:15:09,620
عادة ما تستخدم خادم عديم الحالة على جانب الخادم.

210
00:15:09,620 --> 00:15:12,910
لذلك، سيتم

211
00:15:12,910 --> 00:15:16,490
التعامل مع كل طلب يرسله العميل إلى الخادم كطلب مستقل

212
00:15:16,490 --> 00:15:20,330
ولن ينعكس على الطلبات السابقة

213
00:15:20,330 --> 00:15:24,685
التي تم التعامل معها بالفعل من قبل الخادم من هذا العميل المحدد.

214
00:15:24,685 --> 00:15:29,605
لذلك، من مسؤولية العميل تتبع حالته الخاصة،

215
00:15:29,605 --> 00:15:34,635
إما في شكل استخدام ملفات تعريف الارتباط أو استخدام قاعدة بيانات من جانب العميل،

216
00:15:34,635 --> 00:15:37,435
مهما كانت الوسائل المناسبة.

217
00:15:37,435 --> 00:15:41,790
الآن، هذا النهج حيث يتتبع العميل حالته الخاصة

218
00:15:41,790 --> 00:15:44,815
هو أكثر قابلية للتطوير لأن كل عميل فردي

219
00:15:44,815 --> 00:15:48,240
سيكون مسؤولاً عن تتبع حالته الخاصة.

220
00:15:48,240 --> 00:15:53,840
هذا هو المكان الذي يساعدنا فيه إعداد MVC من جانب العميل في هذا الصدد.

221
00:15:53,840 --> 00:15:57,440
وأخيرًا، لم ننتهي بعد من REST.

222
00:15:57,440 --> 00:16:04,145
سنرى المزيد من REST في التدريبات التي تتبع في هذا الدرس بالذات،

223
00:16:04,145 --> 00:16:12,310
ثم سنرى المزيد من التفاصيل حول استخدام REST في بقية هذه الدورة.