1
00:00:03,979 --> 00:00:06,750
اسمحوا لي أن أعطيك راحة قصيرة.

2
00:00:08,010 --> 00:00:09,480
حصلت لك هناك!

3
00:00:09,480 --> 00:00:10,800
ما قصدت قوله هو،

4
00:00:10,800 --> 00:00:16,860
اسمحوا لي أن أقدم لكم لمحة موجزة عن نقل الدولة التمثيلية.

5
00:00:16,860 --> 00:00:18,670
ما هو الراحة بالضبط؟

6
00:00:18,670 --> 00:00:22,900
كيف يمكننا الاستفادة منه في تطبيقنا الزاوي

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

8
00:00:26,450 --> 00:00:30,050
كيف يدعم الخادم واجهة برمجة تطبيقات REST

9
00:00:30,050 --> 00:00:35,060
وكيف يمكننا الوصول إلى واجهة برمجة تطبيقات REST من تطبيق Angular الخاص بنا؟

10
00:00:35,060 --> 00:00:39,170
دعونا نتحدث عن ذلك أكثر قليلا في هذا الدرس.

11
00:00:39,170 --> 00:00:43,880
في هذه المحاضرة بالذات، سأقدم لك لمحة موجزة عن REST.

12
00:00:46,010 --> 00:00:50,620
أنا متأكد من أنك سمعت مصطلح خدمات الويب المذكورة

13
00:00:50,620 --> 00:00:53,990
في عالم تكنولوجيا المعلومات في كثير من الأحيان.

14
00:00:53,990 --> 00:00:56,160
ما هي خدمات الويب بالضبط؟

15
00:00:56,160 --> 00:01:01,980
خدمات الويب هي طريقة لتصميم الأنظمة لدعم التشغيل البيني بين

16
00:01:01,980 --> 00:01:07,920
الأنظمة المتصلة عبر الشبكة، مثل الإنترنت كما نراه اليوم.

17
00:01:07,920 --> 00:01:11,830
هذا ما نشير إليه على أنه بنية موجهة نحو الخدمات.

18
00:01:11,830 --> 00:01:18,100
الآن، ما يعنيه هذا هو أنك توفر طريقة موحدة لجهازين

19
00:01:18,100 --> 00:01:22,190
متصلين بالإنترنت لتكون قادرة على التواصل مع بعضها البعض.

20
00:01:23,670 --> 00:01:26,970
مستوى تخطيط التطبيق

21
00:01:26,970 --> 00:01:30,920
لتطبيقات قاعدة البيانات باستخدام المعايير المفتوحة.

22
00:01:30,920 --> 00:01:34,660
الآن، لقد استخدمت الكثير من المصطلحات هناك.

23
00:01:35,710 --> 00:01:37,420
دعونا نحاول كسرها

24
00:01:37,420 --> 00:01:41,640
وفهم قليلا عن كل من ذلك في هذه المحاضرة.

25
00:01:42,640 --> 00:01:49,570
طريقتان شائعتان يتم استخدامهما لدعم خدمات الويب هما SOAP، وهي

26
00:01:49,570 --> 00:01:54,720
خدمات الويب المستندة إلى بروتوكول الوصول البسيط إلى الكائنات،

27
00:01:54,720 --> 00:01:58,820
والتي تستخدم لغة وصف خدمات الويب

28
00:01:58,820 --> 00:02:03,150
لتحديد كيفية اتصال نقطتي النهاية مع بعضهما البعض.

29
00:02:03,150 --> 00:02:07,667
وعادة ما يعتمد الصابون على استخدام XML

30
00:02:07,667 --> 00:02:12,240
كتنسيق للرسائل التي يتم تبادلها بين نقطتي النهاية.

31
00:02:13,990 --> 00:02:19,910
يستخدم نقل الحالة التقديمية أو الراحة أيضًا معايير الويب، ولكن تبادل

32
00:02:19,910 --> 00:02:24,020
البيانات بين نقطتي النهاية يمكن أن يكون إما XML أو بشكل متزايد.

33
00:02:25,150 --> 00:02:28,960
باستخدام JSON كتنسيق.

34
00:02:28,960 --> 00:02:34,960
تعتبر طريقة REST للتشغيل البيني أبسط مقارنة بـ SOAP،

35
00:02:34,960 --> 00:02:42,940
وبالتالي وجدت REST نشرًا أوسع كثيرًا في خدمات الويب المتبقية.

36
00:02:43,950 --> 00:02:49,230
عادة، يتم تسهيل اتصال خادم العميل باستخدام REST

37
00:02:49,230 --> 00:02:54,830
حيث يدعم الخادم واجهة برمجة تطبيقات REST ويمكن للعميل بعد ذلك استدعاء

38
00:02:54,830 --> 00:03:01,000
نقاط النهاية REST API الخاصة بهم للحصول على معلومات أو لتحميل المعلومات إلى الخادم.

39
00:03:01,000 --> 00:03:05,910
مرة أخرى، لقد ذكرت الكلمة، استدعاء نقطة نهاية أبي ريست.

40
00:03:05,910 --> 00:03:09,290
إذن هذه بعض المصطلحات التي استخدمتها.

41
00:03:09,290 --> 00:03:12,460
دعونا توضيح بعض هذه في الشرائح القليلة القادمة.

42
00:03:13,790 --> 00:03:18,710
نقل الحالة التمثيلية هو نمط من بنية البرمجيات التي

43
00:03:18,710 --> 00:03:23,360
تم تصميمها خصيصا للوسائط التشعبية الموزعة عبر الشبكة العالمية.

44
00:03:24,770 --> 00:03:30,810
الآن تم تقديم هذا لأول مرة من قبل روي فيلدنغ في أطروحة الدكتوراه.

45
00:03:30,810 --> 00:03:33,750
الآن، هذه إحدى أطروحات الدكتوراه التي أنتجت

46
00:03:33,750 --> 00:03:35,970
شيئًا مفيدًا للعالم.

47
00:03:35,970 --> 00:03:44,250
لذلك وجد هذا مرة أخرى الكثير من الجر في عالم خدمات الويب.

48
00:03:44,250 --> 00:03:50,410
هذه مجموعة من مبادئ الشبكة التي توضح كيفية توفير الموارد

49
00:03:51,630 --> 00:03:57,060
على الخوادم، ويمكن الوصول إلى هذه الموارد من العملاء عن

50
00:03:57,060 --> 00:04:02,520
طريق تحديد الموارد باستخدام نقاط النهاية REST API.

51
00:04:02,520 --> 00:04:07,150
في إطار نقل الدولة التمثيلية هناك أربعة مبادئ تصميم أساسية.

52
00:04:07,150 --> 00:04:11,310
أولاً وقبل كل شيء، تم إنشاء REST على بروتوكول HTTP.

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

54
00:04:17,800 --> 00:04:22,750
ثانيًا، تم تصميم REST لتكون عديمة الجنسية، مما يعني أن الخادم لا يخزن

55
00:04:22,750 --> 00:04:27,350
أي معلومات حول الحالة بعد اكتمال الاتصال.

56
00:04:27,350 --> 00:04:31,850
لذلك عندما يتلقى الخادم الطلب، يستجيب الخادم

57
00:04:31,850 --> 00:04:37,020
وبعد ذلك، فإنه لا يتذكر أي شيء أكثر عن تلك

58
00:04:37,020 --> 00:04:39,730
المحادثة بين العميل والخادم.

59
00:04:39,730 --> 00:04:44,620
ثالثًا، تتمثل طريقة REST لتوفير الموارد

60
00:04:44,620 --> 00:04:49,990
في عرض بنية دليل مثل عناوين URL الموحدة لتحديد مواقع الموارد.

61
00:04:51,090 --> 00:04:57,210
ورابع تنسيقها لتبادل البيانات هو عادة JSON أو

62
00:04:57,210 --> 00:05:02,360
XML، أو كلاهما يمكن دعمه باستخدام REST.

63
00:05:02,360 --> 00:05:07,940
أحد دوافع الارتفاع التي تشير إلى REST كوسيلة لدعم

64
00:05:07,940 --> 00:05:14,060
خدمات الويب هو أنه يلتقط كل شيء جيد من جميع الشبكة العالمية.

65
00:05:14,060 --> 00:05:17,130
وهذا جعل كلمة ويب ناجحة.

66
00:05:17,130 --> 00:05:23,240
استخدام مؤشرات الموارد الموحدة أو محددات الموارد الموحدة، عناوين URL،

67
00:05:23,240 --> 00:05:28,660
والتي تسمح لك بمعالجة الموارد عن طريق تحديدها كعنوان URL،

68
00:05:28,660 --> 00:05:35,370
والثاني هو بروتوكول يركب فوق بروتوكول HTTP.

69
00:05:35,370 --> 00:05:40,820
لقد عثر HTTP بالفعل على نشر واسع في الإنترنت.

70
00:05:40,820 --> 00:05:46,370
ثالثًا، دورة استجابة الطلب التي تعرف HTTP بها.

71
00:05:46,370 --> 00:05:51,850
لذلك تقوم بإرسال طلب، يتلقى الخادم طلبك، يعالج الطلب،

72
00:05:51,850 --> 00:05:57,835
يرسل الاستجابة للطلب، ويتلقى هذا العميل الاستجابة،

73
00:05:57,835 --> 00:06:00,845
يتصرف بناءً على ذلك، وقد ينشئ طلبات أخرى.

74
00:06:00,845 --> 00:06:06,815
لذلك، هذا النهج من دورة استجابة الطلب هو راسخ جدا مع HTTP

75
00:06:06,815 --> 00:06:14,740
وويب في جميع أنحاء العالم بروتوكول HTTP كما رأينا في وقت سابق،

76
00:06:14,740 --> 00:06:19,670
وسوف نستخدم جميع الأفعال المختلفة التي يوفر HTTP.

77
00:06:19,670 --> 00:06:23,120
على وجه التحديد، وضعت بوابة آخر حذف.

78
00:06:23,120 --> 00:06:26,730
لكونها قادرة على تحديد العمليات التي يتعين القيام بها

79
00:06:26,730 --> 00:06:29,680
على الموارد التي يتم تخزينها على جانب الخادم.

80
00:06:29,680 --> 00:06:34,320
على سبيل المثال، إذا قمت بإجراء طلب HTTP GET، فأنت تطلب

81
00:06:34,320 --> 00:06:36,180
من الخادم إرجاع المصدر.

82
00:06:36,180 --> 00:06:41,410
إذا قمت بإجراء طلب POST، فأنت تطلب من الخادم إنشاء مورد جديد.

83
00:06:41,410 --> 00:06:44,330
إذا قمت بإجراء طلب PUT، فأنت تطلب من الخادم تحديث

84
00:06:44,330 --> 00:06:48,780
مورد موجود وإذا قمت بإصدار طلب حذف فأنت تطلب من

85
00:06:48,780 --> 00:06:54,210
الخادم حذف المورد الذي تم تعريفه بواسطة عنوان URL المحدد هذا.

86
00:06:54,210 --> 00:06:57,890
أيضا، فإنه يحاول الحفاظ على إديمبتنس.

87
00:06:57,890 --> 00:07:00,970
بعض العمليات عندما يتم تنفيذها

88
00:07:00,970 --> 00:07:04,370
حتى مرارا وتكرارا لن يسبب أي تغيير في الدولة.

89
00:07:04,370 --> 00:07:08,160
بعض العمليات الأخرى، إذا قمت بها على التوالي،

90
00:07:08,160 --> 00:07:11,170
فإنها قد تتسبب في تغيير الحالة.

91
00:07:11,170 --> 00:07:14,780
لذلك عليك أن تكون حذرا حول العمليات التي يمكن أن تتكرر دون

92
00:07:14,780 --> 00:07:16,660
أي عواقب ضارة.

93
00:07:16,660 --> 00:07:19,570
والتي يجب أن يتم بعناية فائقة.

94
00:07:21,070 --> 00:07:25,530
في عالم REST، غالبًا ما تسمع أشخاصًا يتحدثون عن الأسماء

95
00:07:25,530 --> 00:07:28,230
والأفعال والتمثيلات.

96
00:07:28,230 --> 00:07:34,120
الآن سنقوم بتوضيح كل واحد من هذه بمزيد من التفصيل في الشرائح القليلة القادمة.

97
00:07:34,120 --> 00:07:36,720
الأسماء، على وجه التحديد، مليئة بالموارد

98
00:07:36,720 --> 00:07:42,580
وعادة ما يتم تحديد هذه الموارد من خلال عنوان URL الخاص بها وهذه غير مقيدة.

99
00:07:42,580 --> 00:07:48,890
الأفعال مقيدة وهذه الإجراءات المحددة التي يتعين القيام بها على الموارد.

100
00:07:48,890 --> 00:07:53,200
والعروض التقديمية كما نرى عندما تحتاج المعلومات إلى نقلها

101
00:07:53,200 --> 00:07:54,560
من الخادم إلى العميل أو

102
00:07:54,560 --> 00:07:58,150
من العميل إلى الخادم، وكيفية ترميز المعلومات.

103
00:07:58,150 --> 00:08:02,840
عادة إما باستخدام JSON أو استخدام XML.

104
00:08:02,840 --> 00:08:08,150
المورد هو التجريد الرئيسي الذي يعمل REST حولها

105
00:08:08,150 --> 00:08:11,787
بحيث يتم استخراج المعلومات في المورد.

106
00:08:11,787 --> 00:08:18,690
ويتم تحديد المورد عن طريق تحديده باستخدام URI.

107
00:08:18,690 --> 00:08:23,040
لذلك يمكن

108
00:08:23,040 --> 00:08:26,980
تحديد أي معلومات يمكن تغليفها وإتاحتها كمورد.

109
00:08:26,980 --> 00:08:33,145
قطعة من المعلومات مثل هذا الطقس الحالي في هونغ كونغ يمكن أن تكون مصدرا،

110
00:08:33,145 --> 00:08:35,465
صورة يمكن أن تكون مصدرا.

111
00:08:35,465 --> 00:08:39,915
يمكن أن تكون معلومات سعر السهم موردًا، وما إلى ذلك.

112
00:08:39,915 --> 00:08:43,905
لذا، مهما كان ما تعرفه كجزء من المعلومات التي قد

113
00:08:43,905 --> 00:08:47,515
يهتم بها العميل، يمكن تحديده كمورد.

114
00:08:47,515 --> 00:08:50,965
يمكنك حتى التعامل مع الموارد كمجموعة من الموارد

115
00:08:50,965 --> 00:08:55,070
التي قد يرسلها هذا الخادم إلى هذا العميل.

116
00:08:55,070 --> 00:09:00,380
يتم توضيح مثال على كيفية تسمية الموارد هنا.

117
00:09:00,380 --> 00:09:03,898
لذلك نستخدم عناوين URI لتحديد المصدر. إن

118
00:09:03,898 --> 00:09:09,575
القراءة السريعة للمواصفات أو عناوين URL هنا

119
00:09:09,575 --> 00:09:16,525
ستتيح لك بسهولة فهم ما نشير إليه باستخدام عناوين URL هذه.

120
00:09:16,525 --> 00:09:19,675
على سبيل المثال، شيء ينتهي بالأطباق/،

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

122
00:09:25,495 --> 00:09:28,909
مثل الصحون/123 على سبيل المثال،

123
00:09:28,909 --> 00:09:34,150
قد يعني الطبق رقم 123، في هذه الحالة وهلم جرا.

124
00:09:34,150 --> 00:09:39,530
لذلك من السهل جدًا القول أنه يمكنك تحديد مجموعة من الموارد،

125
00:09:39,530 --> 00:09:43,800
وتكون قادرًا على تحديدها كمجموعة، ثم تنزيلها كمجموعة.

126
00:09:43,800 --> 00:09:46,960
أو، يمكنك تحديد مورد فردي،

127
00:09:46,960 --> 00:09:50,070
وتقول أنك تريد هذا المورد معين.

128
00:09:50,070 --> 00:09:53,378
الآن يمكن تنظيم هذه الموارد في التسلسل الهرمي

129
00:09:53,378 --> 00:09:56,500
الذي مواصفات URI هذا.

130
00:09:56,500 --> 00:09:58,860
حتى عندما كنت اجتياز المسار،

131
00:09:58,860 --> 00:10:04,460
تذهب من أكثر عمومية إلى أكثر تحديدا من هذا المورد.

132
00:10:04,460 --> 00:10:08,260
تمكنك بنية الدليل هذه من تحديد الموارد التي

133
00:10:09,320 --> 00:10:14,170
توفرها من موقع الخدمة الخاص بك بسهولة بالغة.

134
00:10:14,170 --> 00:10:17,970
الجزء الثاني من واجهة برمجة تطبيقات REST هي الكلمات. على

135
00:10:17,970 --> 00:10:22,150
وجه الخصوص نحن مهتمون في 4 الأفعال من HTTP للحصول على،

136
00:10:22,150 --> 00:10:25,320
وضع، نشر، وحذف.

137
00:10:25,320 --> 00:10:30,310
في هذه الحالة سوف تكون هذه الأفعال قيلولة في الإجراءات التي

138
00:10:30,310 --> 00:10:36,165
نريد أن يتم تنفيذها على المورد على جانب الخادم.

139
00:10:36,165 --> 00:10:40,760
يعني GETT أنك تريد إجراء عملية قراءة على المورد، مما يعني

140
00:10:40,760 --> 00:10:46,550
أن العميل الذي يرسل طلب get يشير إلى الخادم أنه يريد

141
00:10:46,550 --> 00:10:52,710
الحصول على هذا العرض التقديمي لمصدر البيانات من موقع الخادم إلى موقع العميل.

142
00:10:52,710 --> 00:10:56,770
تعني POST أنك تريد إنشاء مورد جديد ثم ستفعل.

143
00:10:56,770 --> 00:11:01,700
حدد تفاصيل المورد في التمثيل، ولكن يتم استخدامه

144
00:11:01,700 --> 00:11:02,850
لتحديد المورد.

145
00:11:02,850 --> 00:11:05,900
ثم أرسل المعلومات إلى جانب الخادم،

146
00:11:05,900 --> 00:11:09,590
بحيث يقوم الخادم بإنشاء المورد نيابة عنك.

147
00:11:09,590 --> 00:11:12,310
سيكون PUT تعديل الموارد،

148
00:11:12,310 --> 00:11:16,030
وحذف، كما تتوقع، هو حذف المصادر.

149
00:11:16,030 --> 00:11:20,550
لذلك، كما ترون

150
00:11:20,550 --> 00:11:25,670
يتم تعيين الأفعال الأربعة، بعد، وضع وحذف في عمليات CRUD الأربعة التي يمكنك تنفيذها

151
00:11:25,670 --> 00:11:30,140
على قاعدة بيانات تخزن هذه الموارد على جانب الخادم.

152
00:11:30,140 --> 00:11:34,130
قراءة، إنشاء، تحديث وحذف العمليات.

153
00:11:34,130 --> 00:11:39,140
بمزيد من التفصيل، فإن HTTP GET هو طريقة للتحديد.

154
00:11:39,140 --> 00:11:43,560
أن تريد المعلومات أو العرض التقديمي للمورد ليتم

155
00:11:43,560 --> 00:11:46,280
إرجاعها إلى العميل من موقع الملقم.

156
00:11:46,280 --> 00:11:49,980
لذلك عند إصدار طلب GET إلى نقطة نهاية REST API.

157
00:11:49,980 --> 00:11:54,370
أنت تسأل إما عن مجموعة من الموارد التي يتم تقديمها بواسطة

158
00:11:55,890 --> 00:12:01,790
Uri أو مورد معين يتم تحديده بواسطة معرف

159
00:12:01,790 --> 00:12:06,950
تلك الموارد المعينة المحددة داخل عنوان URL كما ترى في هذا المثال،

160
00:12:06,950 --> 00:12:13,090
إذا قمت بأطباق/452، فأنت تعني أن تقول أن الطبق رقم 452،

161
00:12:13,090 --> 00:12:16,950
مع يجب إرجاع معرف 452 إلى جانب العميل.

162
00:12:19,370 --> 00:12:24,210
وبالمثل، يتم استخدام عملية ما بعد، كما رأينا، لإنشاء المورد.

163
00:12:24,210 --> 00:12:29,940
لذلك عند إنشاء المورد،

164
00:12:29,940 --> 00:12:34,830
سيكون محتوى وصف المورد في شكل تمثيل JSON أو تمثيل XML، وسيتم

165
00:12:34,830 --> 00:12:40,220
تضمينه في نص رسالة الطلب التي يتم إرسالها إلى جانب الخادم.

166
00:12:40,220 --> 00:12:43,900
لذلك تتوقع عملية النشر تمثيلاً

167
00:12:43,900 --> 00:12:49,040
للمورد بتنسيق JSON أو XML في نص رسالة الطلب.

168
00:12:49,040 --> 00:12:53,250
ويتلقى الخادم رسالة الطلب هذه، يقوم الخادم بإنشاء هذا

169
00:12:53,250 --> 00:12:58,440
المورد على جانب الخادم ثم يقوم بإرجاع تأكيد أو

170
00:12:58,440 --> 00:13:04,390
خطأ للإشارة إلى فشل إنشاء المورد.

171
00:13:04,390 --> 00:13:08,820
وبالمثل فإنه يضع عملية سهلة الاستخدام لتحديث مورد.

172
00:13:08,820 --> 00:13:14,630
عند القيام بعملية PUT على مورد على جانب الخادم، يمكنك إرسال

173
00:13:14,630 --> 00:13:19,630
التعديل مرة أخرى إما عن طريق تحديد التعديل الجزئي

174
00:13:19,630 --> 00:13:25,450
الذي تريد التأثير على مورد معين في نص رسالة الرد فقط.

175
00:13:25,450 --> 00:13:29,370
أو يمكنك إرسال التمثيل الكامل للمورد

176
00:13:29,370 --> 00:13:33,890
في نص الرسالة، اعتمادًا على الترتيب بين العميل

177
00:13:33,890 --> 00:13:38,760
والخادم، يتوقع الخادم أن يتم

178
00:13:38,760 --> 00:13:43,320
تمرير المعلومات في نص رسالة الطلب.

179
00:13:43,320 --> 00:13:48,980
حذف العملية كما تتوقع حذف المورد الموجود.

180
00:13:48,980 --> 00:13:55,150
الآن في هذه الحالة بالذات، بالطبع، ستكون عملية الحذف لأنه

181
00:13:55,150 --> 00:14:00,220
إذا حاولت حذف مورد وكان المورد موجودًا، فسيتم حذفه.

182
00:14:00,220 --> 00:14:02,440
إذا كنت تحاول حذف مورد غير موجود،

183
00:14:02,440 --> 00:14:07,990
فلن يتسبب ذلك في أي تعديل آخر على جانب الخادم باستثناء

184
00:14:07,990 --> 00:14:11,808
أن الخادم سيرد بخطأ يقول أن المورد غير موجود.

185
00:14:11,808 --> 00:14:18,700
ولكن مع ذلك، هو مثال على عملية في هذه الحالة.

186
00:14:18,700 --> 00:14:22,810
وبالمثل، ستعمل عملية get أيضًا لأنها لا

187
00:14:22,810 --> 00:14:27,140
تقوم بأي تعديل على المورد على موقع الخادم.

188
00:14:27,140 --> 00:14:32,740
إدخال آخر بالطبع سوف لتعديل المورد على جانب الخادم.

189
00:14:32,740 --> 00:14:34,770
تحتاج إلى إنشاء مورد جديد أو

190
00:14:34,770 --> 00:14:40,050
تعديل مورد موجود على جانب الخادم، وبالطبع العروض التقديمية للبيانات.

191
00:14:40,050 --> 00:14:45,050
كما كنت أؤكد، فإن الفرعين الشائعين

192
00:14:45,050 --> 00:14:51,570
للتمثيل هما إما JSON XML، والجزء الأخير

193
00:14:51,570 --> 00:14:57,140
الذي نحتاج إلى التأكيد عليه هو أن جانب الخادم يجب أن يكون عديم الجنسية تمامًا.

194
00:14:57,140 --> 00:15:01,190
مما يعني أن جانب الخادم لا يتتبع حالة العميل.

195
00:15:01,190 --> 00:15:07,060
لأنه، إذا كان الخادم يحتاج إلى تتبع حالة العميل، فإنه لن يكون قابلاً للتطوير.

196
00:15:07,060 --> 00:15:11,140
لذا من أجل تنفيذ قابل للتطوير لجانب الخادم،

197
00:15:11,140 --> 00:15:15,650
فإنك تستخدم عادةً خادمًا عديم الحالة على جانب الخادم.

198
00:15:15,650 --> 00:15:19,580
لذلك إذا كان طلب العملاء المرسلة إلى الخادم سيتم التعامل معه

199
00:15:19,580 --> 00:15:25,460
كطلب مستقل، ولن ينعكس على

200
00:15:25,460 --> 00:15:30,790
الطلبات السابقة التي تم التعامل معها بالفعل من قبل الخادم من عميل معين.

201
00:15:30,790 --> 00:15:35,760
لذلك فمن مسؤولية العميل لتتبع حالته الخاصة.

202
00:15:35,760 --> 00:15:40,770
إما في شكل استخدام ملفات تعريف الارتباط أو استخدام قاعدة بيانات موقع العميل.

203
00:15:40,770 --> 00:15:43,780
مهما كان يعني أن هذا مناسب.

204
00:15:43,780 --> 00:15:48,760
الآن، هذا النهج حيث يتتبع العميل حالته الخاصة هو أكثر قابلية للتطوير،

205
00:15:48,760 --> 00:15:52,880
لأن عميلك سيكون مسؤولاً عن تتبع حالته الخاصة.

206
00:15:54,340 --> 00:15:58,880
وهذا هو المكان الذي يساعدنا إعداد MVC جانب العميل في هذا الصدد.

207
00:16:00,100 --> 00:16:04,920
وأخيرًا لم ننتهي بعد من REST، سنرى المزيد من

208
00:16:04,920 --> 00:16:10,280
REST في التمارين التي تلي هذا الدرس بالذات.

209
00:16:10,280 --> 00:16:11,563
وبعد ذلك أيضًا،

210
00:16:11,563 --> 00:16:17,206
سنرى المزيد من التفاصيل حول استخدام REST في بقية هذه الدورة.

211
00:16:17,206 --> 00:16:20,509
[ موسيقى]