1
00:00:03,920 --> 00:00:09,645
كما فهمنا من المحاضرة السابقة في هذا الدرس، فإن

2
00:00:09,645 --> 00:00:12,585
هدفنا في هذا الدرس هو

3
00:00:12,585 --> 00:00:16,590
دمج خادم REST API الذي قمنا بتطويره بالفعل،

4
00:00:16,590 --> 00:00:24,060
مع الوصول إلى قاعدة بيانات MongoDB.

5
00:00:24,060 --> 00:00:27,480
لذا، سنبدأ بخادم REST API

6
00:00:27,480 --> 00:00:31,770
الذي قمنا ببنائه في الدرس الأول في هذه الوحدة،

7
00:00:31,770 --> 00:00:37,220
ثم بعد أن تعلمنا كيفية التفاعل من

8
00:00:37,220 --> 00:00:43,865
تطبيق العقدة إلى خادم MongoDB باستخدام Mongoose،

9
00:00:43,865 --> 00:00:50,749
سنقوم بتطوير خادم REST API الخاص بنا بشكل أكبر لدمج بين طلب العميل الوارد إلى الخادم، على

10
00:00:50,749 --> 00:00:53,840
طول الطريق إلى عملية قاعدة البيانات المقابلة التي يتعين تنفيذها،

11
00:00:53,840 --> 00:01:00,880
ثم إنشاء وإرسال الرد إلى هذا العميل من موقع الخادم الخاص بنا.

12
00:01:00,880 --> 00:01:04,125
للبدء بالطبع، أولاً،

13
00:01:04,125 --> 00:01:08,300
انتقل إلى مجلد خادم الارتباك الذي أنشأه بالفعل في

14
00:01:08,300 --> 00:01:15,215
التمرين الأول لهذه الوحدة في درس REST API

15
00:01:15,215 --> 00:01:17,915
، ثم في مجلد الارتباك،

16
00:01:17,915 --> 00:01:22,310
قمنا بالفعل ببناء خادم REST API.

17
00:01:22,310 --> 00:01:26,630
الآن، ما كنا نفعله هو استعارة

18
00:01:26,630 --> 00:01:32,035
النماذج التي قمنا بتطويرها في التمرين السابق،

19
00:01:32,035 --> 00:01:36,050
ملف dishes.js الذي قمنا بتطويره في التمرين السابق،

20
00:01:36,050 --> 00:01:41,220
نسخه إلى مشروع خادم الارتباك،

21
00:01:41,220 --> 00:01:44,430
وكذلك تثبيت Bluebird Mongoose،

22
00:01:44,430 --> 00:01:51,225
ووحدة أخرى تسمى النمس العملة، لمشروعنا.

23
00:01:51,225 --> 00:01:54,275
لذلك، والذهاب إلى مجلد عقدة جس،

24
00:01:54,275 --> 00:01:57,050
نذهب أولا إلى مجلد عقدة النمس،

25
00:01:57,050 --> 00:02:01,970
ونحن نرى أنه في المجلد الفرعي نماذج من مجلد النمس عقدة،

26
00:02:01,970 --> 00:02:03,810
لدينا ملف dishes.js.

27
00:02:03,810 --> 00:02:07,354
أنا فقط ذاهب لنسخ مجلد النماذج،

28
00:02:07,354 --> 00:02:10,490
ومن ثم انتقل إلى مجلد خادم الارتباك،

29
00:02:10,490 --> 00:02:13,910
ومن ثم ببساطة اختراق مجلد النماذج هناك.

30
00:02:13,910 --> 00:02:15,690
لذلك، بمجرد القيام بذلك،

31
00:02:15,690 --> 00:02:22,540
يتم

32
00:02:22,540 --> 00:02:28,155
دمج ملف dishes.js الذي يحتوي على المخطط ونموذج مستند الأطباق، في خادم REST API الخاص بنا.

33
00:02:28,155 --> 00:02:30,890
بالطبع، من أجل الاستفادة من ذلك،

34
00:02:30,890 --> 00:02:34,400
نحن بحاجة إلى تثبيت وحدة عقدة النمس،

35
00:02:34,400 --> 00:02:40,990
ووحدة عقدة جديدة تسمى عملة النمس في مشروعنا.

36
00:02:40,990 --> 00:02:47,510
لذا، انتقل إلى المحطة الطرفية في مشروع خادم الارتباك،

37
00:02:47,510 --> 00:02:52,640
تأكد من أن المحطة الطرفية أو نافذة الأوامر موجودة

38
00:02:52,640 --> 00:02:57,480
في مشروع خادم الارتباك حيث تقوم بتطوير واجهة برمجة تطبيقات REST مسبقًا،

39
00:02:57,480 --> 00:03:01,070
وفي هذا المشروع، دعنا نثبّه.

40
00:03:01,070 --> 00:03:06,165
لذلك، سنقوم npm تثبيت Mongoose،

41
00:03:06,165 --> 00:03:13,110
وبعد ذلك، وحدة عقدة جديدة تسمى عملة Mongoose.

42
00:03:13,250 --> 00:03:16,630
وحدة عقدة العملة Mongoose،

43
00:03:16,630 --> 00:03:21,800
ونرى في نوع مخطط آخر إلى تطبيق Mongoose لدينا،

44
00:03:21,800 --> 00:03:23,770
وبالتالي فإن Mongoose نفسها،

45
00:03:23,770 --> 00:03:26,390
بالتأكيد المدمج في أنواع المخطط.

46
00:03:26,390 --> 00:03:29,505
لقد رأينا استخدام الرقم،

47
00:03:29,505 --> 00:03:35,550
السلسلة والمنطقية، والصفيف.

48
00:03:35,550 --> 00:03:39,760
الآن، تضيف عملة النمس دعمًا للعملة.

49
00:03:39,760 --> 00:03:42,385
الآن، لماذا نحتاج إلى دعم هذه العملة؟

50
00:03:42,385 --> 00:03:49,040
بحيث تضيف وحدة العملة Mongoose نوعًا جديدًا يسمى نوع العملة،

51
00:03:49,040 --> 00:03:53,140
مما يمكننا من تخزين قيمة العملة.

52
00:03:53,140 --> 00:03:56,650
منذ طبقنا سوف تحتوي على سعر،

53
00:03:56,650 --> 00:04:00,760
وهذا هو السبب في أنني ذاهب إلى استخدام وحدة العملة النمس هنا.

54
00:04:00,760 --> 00:04:04,590
الآن، وممارسة هنا،

55
00:04:04,590 --> 00:04:07,545
وسوف نوضح استخدام وحدة العملة النمس،

56
00:04:07,545 --> 00:04:11,880
يمكنك قراءة المزيد من التفاصيل حول وحدة عقدة العملة النمس أيضا،

57
00:04:11,880 --> 00:04:19,010
في وثائق أن الرابط الذي يتم توفيره في الموارد الإضافية.

58
00:04:19,010 --> 00:04:22,489
لذا، الآن بعد أن قمنا بتثبيت وحدات العقدة هذه،

59
00:04:22,489 --> 00:04:24,890
عملة Mongoose و Mongoose،

60
00:04:24,890 --> 00:04:33,920
دعنا نذهب إلى تطبيقنا وإعداده للتواصل مع خادم MongoDB.

61
00:04:33,920 --> 00:04:37,570
الآن، تأكد من أن خادم MongoDB الخاص بك قيد التشغيل.

62
00:04:37,570 --> 00:04:40,070
لذلك، هنا، ترى أن

63
00:04:40,070 --> 00:04:44,730
خادم MongoDB الخاص بي يعمل في علامة تبويب محطة أخرى على جهاز الكمبيوتر الخاص بي.

64
00:04:44,730 --> 00:04:46,670
إذا كنت تقوم بتشغيله على جهاز يعمل بنظام التشغيل Windows،

65
00:04:46,670 --> 00:04:54,005
فتأكد من أنه قيد التشغيل في أمر آخر نافذة من جهاز الكمبيوتر الذي يعمل بنظام التشغيل Windows.

66
00:04:54,005 --> 00:04:58,525
الذهاب إلى تطبيقنا في المحرر،

67
00:04:58,525 --> 00:05:01,685
سنبدأ أولا مع ملف app.js.

68
00:05:01,685 --> 00:05:03,460
الآن في ملف app.js،

69
00:05:03,460 --> 00:05:07,590
وهذا هو المكان الذي بنيت لدينا التطبيق السريع في وقت سابق.

70
00:05:07,590 --> 00:05:12,935
ولكن الآن، لا يتم توصيل هذا النفي الممتصة الإضافية بخادم MongoDB الخلفي.

71
00:05:12,935 --> 00:05:18,085
نحن في طريقنا إلى الاستفادة من وحدة النمس،

72
00:05:18,085 --> 00:05:20,430
من أجل إنشاء اتصال مع الخادم.

73
00:05:20,430 --> 00:05:22,385
لذلك، الذهاب هنا،

74
00:05:22,385 --> 00:05:29,540
وأنا ذاهب لإضافة في تتطلب وحدة النمس هنا.

75
00:05:29,540 --> 00:05:35,850
لذا، سنقول، «كونست النمس يتطلب النمس».

76
00:05:38,120 --> 00:05:43,280
وبعد ذلك أيضًا، نظرًا لأننا قمنا بنسخ مجلد النماذج،

77
00:05:43,280 --> 00:05:46,520
الذي يحتوي على ملف الأطباق،

78
00:05:46,520 --> 00:05:51,220
والذي يعلن مخطط الأطباق والنموذج.

79
00:05:51,220 --> 00:05:56,645
لذلك، اسمحوا لي أن استيراد الأطباق.

80
00:05:56,645 --> 00:06:04,930
لذلك، سنقول، «مطلوب. قطع نماذج الأطباق.»

81
00:06:04,930 --> 00:06:07,640
لذلك، بمجرد الانتهاء من ذلك، الآن بالطبع،

82
00:06:07,640 --> 00:06:11,000
نحن بحاجة إلى إنشاء اتصال مع الخادم.

83
00:06:11,000 --> 00:06:13,560
لذا، قم بإعداد

84
00:06:14,120 --> 00:06:24,960
عنوان URL mongodb//localhost7017/الارتباك،

85
00:06:27,340 --> 00:06:31,150
تمامًا كما فعلنا مع ممارسة Mongoose،

86
00:06:31,150 --> 00:06:33,140
وبعد ذلك سنقول،

87
00:06:33,140 --> 00:06:44,040
«Const connect، عنوان URL للاتصال Mongo».

88
00:06:44,040 --> 00:06:51,450
لذلك، هذا هو بالضبط نفس الرمز الذي استخدمناه في التمرين السابق.

89
00:06:51,450 --> 00:06:53,640
ثم، دعونا إنشاء الاتصال.

90
00:06:53,640 --> 00:07:01,695
لذلك، سوف نقول، «الاتصال» وبعد ذلك سنقول،

91
00:07:01,695 --> 00:07:11,610
«دب تفعل ذلك سجل وحدة التحكم.»

92
00:07:11,610 --> 00:07:19,030
يقول، «متصل بشكل صحيح بالخادم.»

93
00:07:21,020 --> 00:07:26,260
وسنتعامل أيضًا مع الخطأ هنا.

94
00:07:33,980 --> 00:07:40,855
سنقوم ببساطة بعمل سجل وحدة التحكم للخطأ هنا، هذا كل شيء.

95
00:07:40,855 --> 00:07:49,110
سيؤدي ذلك إلى إنشاء الاتصال بالخادم من ملف app.js الخاص بنا.

96
00:07:49,110 --> 00:07:52,375
لذلك، بمجرد أن أنشأنا الاتصال بالخادم،

97
00:07:52,375 --> 00:07:58,615
ثم، دعونا فتح ملف dishes.js من نماذجنا.

98
00:07:58,615 --> 00:08:00,995
الآن، في ملف dishes.js،

99
00:08:00,995 --> 00:08:02,970
للاستفادة من

100
00:08:02,970 --> 00:08:11,760
وحدة العقدة التي قمنا بتثبيتها للتو.

101
00:08:11,760 --> 00:08:18,990
لذلك، سوف نقول، «تتطلب عملة النمس،» ويقول،

102
00:08:18,990 --> 00:08:26,500
«تحميل النوع والنمس.»

103
00:08:26,500 --> 00:08:32,670
لذا، ما سيفعله هذا هو تحميل نوع العملة الجديد هذا إلى Mongoose.

104
00:08:32,670 --> 00:08:39,970
بعد ذلك، يمكننا أن نقول const،

105
00:08:39,970 --> 00:08:48,705
العملة النمس أنواع العملة.

106
00:08:48,705 --> 00:08:51,720
هذا كل شيء لذلك، هذا النوع الجديد،

107
00:08:51,720 --> 00:08:57,880
يتم إضافة نوع العملة إلى Mongoose والتي ستضيف في نوع جديد يسمى

108
00:08:57,880 --> 00:09:00,160
العملة ومن ثم سأعلن

109
00:09:00,160 --> 00:09:04,840
هذه العملة الثابتة كعملة أنواع Mongoose.

110
00:09:04,840 --> 00:09:11,630
حتى أتمكن من الاستفادة من هذا في تحديد المخطط في طلبي.

111
00:09:11,630 --> 00:09:14,270
الآن، في هذه الحالة،

112
00:09:14,270 --> 00:09:17,970
سيبقى المخطط المشترك كما كان من قبل ولكن

113
00:09:17,970 --> 00:09:24,060
مخطط الطبق كما تتذكر من ملف db.json.

114
00:09:24,060 --> 00:09:28,050
عندما تنظر إلى بنية وثيقة طبق،

115
00:09:28,050 --> 00:09:35,630
ترى أن وثيقة الطبق تحتوي على اسم وصورة كما ترون هنا هي

116
00:09:35,630 --> 00:09:38,570
سلسلة، فئة، تسمية،

117
00:09:38,570 --> 00:09:42,555
سعر، وهو نوع سلسلة هنا.

118
00:09:42,555 --> 00:09:46,865
لكننا سنعلن هذا كنوع عملة،

119
00:09:46,865 --> 00:09:51,495
وهي ميزة كما تتوقع هي متغير منطقي،

120
00:09:51,495 --> 00:09:55,015
ووصف عبارة عن سلسلة ثم تعليقات

121
00:09:55,015 --> 00:09:59,755
ليست سوى مجموعة من نوع التعليقات.

122
00:09:59,755 --> 00:10:05,790
الآن، ما سنفعله الآن هو توسيع مخطط الطبق

123
00:10:05,790 --> 00:10:12,865
لدعم كل هذه الخصائص المختلفة أو الحقول المختلفة في مستند json الخاص بي.

124
00:10:12,865 --> 00:10:15,225
لذلك لدينا الاسم بالفعل.

125
00:10:15,225 --> 00:10:18,505
لذلك لدينا بالفعل الوصف في المكان.

126
00:10:18,505 --> 00:10:23,730
لذلك نحن بحاجة إلى إضافة في القليلة القادمة هناك لدينا بالفعل التعليقات،

127
00:10:23,730 --> 00:10:27,185
ومجموعة من التعليقات من نوع مخطط التعليق هناك.

128
00:10:27,185 --> 00:10:30,075
لذلك سوف نضيف في القليلة القادمة.

129
00:10:30,075 --> 00:10:34,150
لذا فإن النوع التالي الذي سنضيفه هو نوع الصورة،

130
00:10:34,150 --> 00:10:37,640
والذي سيكون

131
00:10:37,640 --> 00:10:44,300
من سلسلة النوع

132
00:10:44,300 --> 00:10:49,140
وسنقول صحيح مطلوب.

133
00:10:49,200 --> 00:10:52,240
لذلك هذا يضيف نوع الصورة.

134
00:10:52,240 --> 00:11:00,460
التالي الذي سأضيفه هو الفئة،

135
00:11:00,460 --> 00:11:03,865
وهو أيضًا نوع السلسلة.

136
00:11:03,865 --> 00:11:07,990
التالي هو التسمية،

137
00:11:07,990 --> 00:11:10,720
وهو أيضا نوع السلسلة هذا.

138
00:11:10,720 --> 00:11:14,560
بما أن كل هذه من نفس النوع والمطلوب،

139
00:11:14,560 --> 00:11:16,625
فأنا أقوم بنسخها هنا فقط.

140
00:11:16,625 --> 00:11:18,464
ثم بالنسبة للتسمية،

141
00:11:18,464 --> 00:11:21,275
أود أن أقول أن هذا غير مطلوب ولكن

142
00:11:21,275 --> 00:11:26,945
بدلا من ذلك يمكنني أيضا تحديد قيمة افتراضية إذا أردت.

143
00:11:26,945 --> 00:11:29,465
حتى أتمكن من تحديد قيمة افتراضية من هذا القبيل.

144
00:11:29,465 --> 00:11:31,965
القيمة الافتراضية هي سلسلة فارغة.

145
00:11:31,965 --> 00:11:37,245
لذلك، إذا لم أكن تحديد المطلوبة يمكنني ببساطة تحديد قيمة افتراضية هنا.

146
00:11:37,245 --> 00:11:46,300
الآن، بالإضافة إلى ذلك، الحقل التالي الذي سأقوم بتقديمه هو حقل السعر.

147
00:11:47,070 --> 00:11:53,575
حقل السعر سأعلن النوع كعملة.

148
00:11:53,575 --> 00:11:57,085
أذكر أننا قد أعلنا نوع العملة في وقت سابق

149
00:11:57,085 --> 00:12:00,380
هنا من خلال المطالبة أولا

150
00:12:00,380 --> 00:12:03,960
وحدة العملة النمس ومن ثم الإعلان عن نوع العملة.

151
00:12:03,960 --> 00:12:09,435
لذا، هذه هي الطريقة التي ستستخدم بها نوع العملة في طلبنا.

152
00:12:09,435 --> 00:12:16,170
لذلك سنقول نوع سعر العملة

153
00:12:16,170 --> 00:12:24,610
والمطلوب هو صحيح وبعد ذلك يمكنني أيضا تحديد الحد الأدنى للقيمة التي من شأنها أن تكون صفر.

154
00:12:24,610 --> 00:12:29,590
ثم الحقل التالي هو

155
00:12:29,590 --> 00:12:35,830
الحقل المميز الذي سيكون من النوع Boolean

156
00:12:35,830 --> 00:12:40,900
، وستكون القيمة الافتراضية خاطئة.

157
00:12:40,900 --> 00:12:43,625
لذلك، إذا كان المستند الخاص بي مفقودًا،

158
00:12:43,625 --> 00:12:47,940
فسيتم إضافة القيمة الافتراضية إلى المستند هنا.

159
00:12:47,940 --> 00:12:50,470
لذلك لاحظ أنني قمت الآن بتوسيع

160
00:12:50,470 --> 00:12:56,825
مخطط الطبق بإضافة في نوع الصورة، والفئة،

161
00:12:56,825 --> 00:13:01,710
والتسمية، والسعر وميزة لتتناسب مع

162
00:13:01,710 --> 00:13:07,925
بنية مثال مستند الطبق الذي أظهرته لك في وقت سابق.

163
00:13:07,925 --> 00:13:13,795
حتى الآن، مخطط أطباقي جاهز للاستخدام.

164
00:13:13,795 --> 00:13:20,185
لذلك، دعونا نبدأ الآن العمل على جهاز التوجيه الخاص بي.

165
00:13:20,185 --> 00:13:21,915
إذن أين جهاز التوجيه؟

166
00:13:21,915 --> 00:13:29,530
تذكر أن جهاز التوجيه الذي يدعم نقاط النهاية REST API لأطباق الشرطة المائلة،

167
00:13:29,530 --> 00:13:32,110
ونقطة النهاية REST API والأطباق

168
00:13:32,110 --> 00:13:35,170
المائلة، ونقطة نهاية معرف طبق مائل في جهاز التوجيه الطبق.

169
00:13:35,170 --> 00:13:41,295
لذلك، سوف نذهب إلى طبق router.jsfile وبعد ذلك سنقوم بتوسيع ملف router.js الطبق.

170
00:13:41,295 --> 00:13:46,735
لذلك، في جهاز التوجيه الطبق جنبا إلى جنب مع Express و bodyParser،

171
00:13:46,735 --> 00:13:55,310
وأنا ذاهب لتشمل الآن Mongoose.

172
00:13:56,640 --> 00:14:03,370
لذلك سنقول تتطلب Mongoose

173
00:14:03,370 --> 00:14:10,944
وبعد ذلك سوف تتطلب نموذج الأطباق.

174
00:14:10,944 --> 00:14:12,400
أين هو نموذج الأطباق؟

175
00:14:12,400 --> 00:14:20,080
هو في. /نماذج/أطباق.

176
00:14:20,080 --> 00:14:22,405
لذلك هو في هناك.

177
00:14:22,405 --> 00:14:24,470
لذلك لاحظ أننا في مجلد جهاز التوجيه،

178
00:14:24,470 --> 00:14:27,610
لذلك تحتاج إلى الصعود مستوى واحد ثم انتقل إلى

179
00:14:27,610 --> 00:14:31,460
مجلد النموذج ثم ملف dishes.js هناك حق.

180
00:14:31,460 --> 00:14:34,010
لذلك هذا هو ما نستورده هنا.

181
00:14:34,010 --> 00:14:41,039
حتى الآن، يمكنني تحديث جهاز توجيه الطبق الخاص بي لتكون قادرة على التفاعل

182
00:14:41,039 --> 00:14:46,330
مع خادم MongoDB باستخدام

183
00:14:46,330 --> 00:14:52,175
Mongoose ولقد قمنا بالفعل باستيراد نموذج الأطباق في جهاز التوجيه الخاص بي.

184
00:14:52,175 --> 00:14:57,720
لذلك، لقد حان الوقت بالنسبة لي للذهاب وتحديث جميع الطرق هنا.

185
00:14:57,720 --> 00:14:59,465
حتى بالنسبة لجهاز التوجيه طبق،

186
00:14:59,465 --> 00:15:03,665
شرطة مائلة مما يعني أن أطباق مائلة نقطة النهاية.

187
00:15:03,665 --> 00:15:07,880
سأقوم بإزالة كل هذا من هنا، بدلاً من ذلك،

188
00:15:07,880 --> 00:15:12,040
سأقوم بالإعلان صراحة عن جميع نقاط النهاية المختلفة.

189
00:15:12,040 --> 00:15:16,995
للحصول على وظيفة وضع وحذف سأتعامل مع كل واحد منهم بشكل مستقل.

190
00:15:16,995 --> 00:15:19,135
حتى في طريقة الحصول على،

191
00:15:19,135 --> 00:15:24,360
وأنا ذاهب لقطع ذلك ومن ثم في طريقة الحصول على، ماذا أحتاج إلى القيام به؟

192
00:15:24,360 --> 00:15:32,760
أذكر أننا قد حددت طريقة من النمس الذي يسمح لنا للعثور على جميع الأطباق.

193
00:15:32,760 --> 00:15:36,365
لذلك عندما تقوم بعملية الحصول على نقطة نهاية الأطباق المائلة،

194
00:15:36,365 --> 00:15:39,600
فأنت تتوقع إرجاع جميع الأطباق

195
00:15:39,600 --> 00:15:44,005
إلى العميل استجابة لطلب الحصول على.

196
00:15:44,005 --> 00:15:49,890
لذلك، أنا ذاهب للذهاب إلى الأطباق ومن ثم تنفيذ عملية البحث.

197
00:15:49,890 --> 00:15:53,040
حتى الآن ترى أنه من خادم Express الخاص بي،

198
00:15:53,040 --> 00:15:58,585
أنا الوصول إلى بلدي MongoDB.

199
00:15:58,585 --> 00:16:06,520
لذلك، سوف تفعل العثور وفي العثور على أنا ذاهب الآن للتعامل مع الطلب.

200
00:16:06,520 --> 00:16:08,310
حتى أستطيع أن أقول أن الأطباق تجد،

201
00:16:08,310 --> 00:16:13,885
بما أن ذلك سيعود وعدا،

202
00:16:13,885 --> 00:16:16,765
ثم يمكنني التعامل مع ذلك في الداخل هنا.

203
00:16:16,765 --> 00:16:24,520
لذلك، سأقول طبق وحتى إذا كان الوعد يحل بشكل صحيح،

204
00:16:24,520 --> 00:16:33,529
وسوف تحصل عليه في ذلك الحين وهكذا سأقول طبق وبعد ذلك سوف نتعامل مع

205
00:16:33,960 --> 00:16:41,125
رمز الحالة الدقة هو 200 وبعد ذلك سنقول

206
00:16:41,125 --> 00:16:48,920
الدقة تعيين نوع محتوى رأس.

207
00:16:53,100 --> 00:16:57,830
نظرًا لأننا سنعيد القيمة كـ json،

208
00:16:57,830 --> 00:17:00,770
لذا سنقوم بتعيين ذلك على تطبيق json.

209
00:17:00,770 --> 00:17:03,580
حسناً، هذا سيعيد مجموعة من الأطباق

210
00:17:03,580 --> 00:17:07,955
حتى أستطيع أن أقول ببساطة الأطباق وبعد ذلك سنقول res.json.

211
00:17:07,955 --> 00:17:12,650
وبالتالي فإن res.json تأخذ كمدخل في سلسلة json

212
00:17:12,650 --> 00:17:17,680
ثم إرسالها مرة أخرى إلى موكلي.

213
00:17:17,680 --> 00:17:21,785
لذلك، عند استدعاء res.json وتوفير القيمة وبعد ذلك سوف

214
00:17:21,785 --> 00:17:27,650
تأخذ ببساطة المعلمة التي تعطيها هنا ومن ثم إرسالها مرة أخرى كرد json.

215
00:17:27,650 --> 00:17:30,365
فإنه سيتم وضع هذه الأطباق في الجسم

216
00:17:30,365 --> 00:17:33,835
من رسالة الرد ومن ثم إرسالها مرة أخرى إلى الخادم.

217
00:17:33,835 --> 00:17:39,560
الآن، يمكننا التعامل مع الخطأ

218
00:17:39,560 --> 00:17:47,370
هنا بقول الخطأ التالي.

219
00:17:48,100 --> 00:17:59,140
يمكننا أيضا أن نفعل خطأ الصيد فقط من أجل الاكتمال.

220
00:17:59,140 --> 00:18:03,290
أنا فقط ذاهب لوضع كل من هذه في مكان هنا،

221
00:18:03,290 --> 00:18:05,960
بحيث سيتم التعامل مع كليهما على هذا النحو.

222
00:18:05,960 --> 00:18:08,305
حتى إذا تم إرجاع خطأ،

223
00:18:08,305 --> 00:18:11,740
ثم ذلك سوف ببساطة تمرير الخطأ

224
00:18:11,740 --> 00:18:15,260
إلى معالج الخطأ العام للتطبيق الخاص بي

225
00:18:15,260 --> 00:18:18,985
والسماح أن تقلق حول كيفية التعامل مع الخطأ.

226
00:18:18,985 --> 00:18:21,490
لذا نحن سَنُرسلُه إلى ذلك.

227
00:18:21,490 --> 00:18:28,610
لذلك ترى كيف أستخدم عملية البحث ثم قم بتنفيذ الطلب هنا.

228
00:18:28,610 --> 00:18:30,595
الآن، لهذا المنصب،

229
00:18:30,595 --> 00:18:32,904
كما كنت تتوقع بالفعل،

230
00:18:32,904 --> 00:18:37,100
وأنا ذاهب إلى القيام dishes.create

231
00:18:38,790 --> 00:18:43,425
لأننا في طريقنا إلى إنشاء طبق جديد هنا.

232
00:18:43,425 --> 00:18:47,195
لذا، تذكر أننا نشاهد بالفعل الأطباق تخلق

233
00:18:47,195 --> 00:18:52,400
استخدام الطريقة في وقت سابق وتذكر أن محلل الجسم كان قد قام

234
00:18:52,400 --> 00:18:56,950
بالفعل بتحليل ما هو موجود في نص الرسالة وتحميله

235
00:18:56,950 --> 00:19:01,510
على خاصية الجسم للطلب.

236
00:19:01,510 --> 00:19:08,650
لذا، سأقوم فقط بأخذ نص الطلب ثم تحليله كمعلمة

237
00:19:08,650 --> 00:19:16,120
لطريقة dishes.create الخاصة بي والتعامل مع قيمة الإرجاع.

238
00:19:16,120 --> 00:19:21,325
لذا، سنقول حينها وهذا سيعيد

239
00:19:21,325 --> 00:19:26,755
طبق وسنتعامل مع ذلك هنا

240
00:19:26,755 --> 00:19:35,220
لذلك سنقول إذا كانت الأطباق تعود بشكل صحيح وإذا أطباق نشرت بشكل صحيح، وسوف يقول الدقة.

241
00:19:36,060 --> 00:19:43,045
حسنا دعونا نفعل console.log لاستخدامنا الخاص.

242
00:19:43,045 --> 00:19:52,330
على جانب الخادم سنفعل console.log قائلا «صحن خلق» طبق هنا.

243
00:19:52,330 --> 00:20:02,125
دعونا تسجيل هذا الطبق إلى وحدة التحكم وبعد ذلك سنقول هذين رمز حالة الراحة.

244
00:20:02,125 --> 00:20:09,820
سنقوم فقط بنسخ هذا الرمز ثم لصقه هناك وفي هذه الحالة،

245
00:20:09,820 --> 00:20:12,445
نحن نعيد الطبق هنا.

246
00:20:12,445 --> 00:20:16,480
الطبق الذي جاء كمعلمة هنا ثم دع

247
00:20:16,480 --> 00:20:22,825
العميل يتعامل مع هذه القيمة على جانب العميل،

248
00:20:22,825 --> 00:20:24,985
كل ما يتم إرجاعه في الطبق.

249
00:20:24,985 --> 00:20:27,745
الآن، كما أنها سوف تضيف في

250
00:20:27,745 --> 00:20:41,770
هذا هنا ومن ثم الصيد.

251
00:20:41,770 --> 00:20:44,860
إذن هذه هي الطريقة التي نتعامل بها مع هذا المنصب.

252
00:20:44,860 --> 00:20:47,830
ل PUT، لأن PUT غير مسموح به،

253
00:20:47,830 --> 00:20:50,365
لذلك نحن ذاهبون إلى ترك الأمر على هذا النحو.

254
00:20:50,365 --> 00:20:54,250
ل DELETE، ونحن في طريقنا إلى حذف جميع الأطباق.

255
00:20:54,250 --> 00:21:02,240
لذلك سوف نقول، «أطباق، إزالة.»

256
00:21:03,990 --> 00:21:08,185
هذه هي أساسا عملية خطيرة.

257
00:21:08,185 --> 00:21:11,080
لذلك كنت إزالة جميع الأطباق من

258
00:21:11,080 --> 00:21:18,610
الخادم وهكذا سوف نقول،

259
00:21:18,610 --> 00:21:25,600
«dishes.Remove ثم» و «ثم» سوف تحصل على بعض الاستجابة.

260
00:21:25,600 --> 00:21:32,200
لذلك سنقول فقط، «resp هنا» والطريقة

261
00:21:32,200 --> 00:21:40,550
التي سنتعامل بها مع هذا الرد هي ببساطة أخذ هذه القيمة ثم إعادتها إلى العميل.

262
00:21:40,620 --> 00:21:48,550
لذلك سنقول، «Res.StatusCode 200 نوع المحتوى json التطبيق،»

263
00:21:48,550 --> 00:21:56,660
وبعد ذلك سنقوم ببساطة بإرسال الاستجابة مرة أخرى إلى العميل وسوف نتعامل مع الخطأ

264
00:22:06,000 --> 00:22:08,830
تماما كما فعلنا في وقت سابق.

265
00:22:08,830 --> 00:22:10,390
هذه هي عملية DELETE.

266
00:22:10,390 --> 00:22:14,110
لذلك ترى أننا الآن نقوم بعمل GET و

267
00:22:14,110 --> 00:22:17,545
POST و PUT و عملية DELETE.

268
00:22:17,545 --> 00:22:26,425
الآن نحن ذاهبون إلى الاستمرار في نفس مع نقطة النهاية /dishid.

269
00:22:26,425 --> 00:22:28,270
حتى في هذه الحالة،

270
00:22:28,270 --> 00:22:34,040
ونحن على وجه التحديد عزر الحصول على طبق معين.

271
00:22:34,040 --> 00:22:39,480
نحن ذاهبون إلى إعادة تلك القيمة طبق محددة.

272
00:22:39,480 --> 00:22:41,445
حتى في جيت،

273
00:22:41,445 --> 00:22:51,275
ما نقوم به هو أننا سوف نقول «dusines.Findbyid.

274
00:22:51,275 --> 00:22:57,965
لذا فإن FindByID هي طريقة متوفرة من mongo بالإضافة إلى برنامج تشغيل MongoDB.

275
00:22:57,965 --> 00:23:02,020
لذلك سوف نقول، «Req.Params.dished».

276
00:23:03,600 --> 00:23:11,030
أذكر أننا نعرف بالفعل أن معرف الطبق موجود في خاصية params.

277
00:23:11,030 --> 00:23:14,140
لقد تعلمت بالفعل عن هذا في وقت سابق.

278
00:23:14,140 --> 00:23:20,260
لذلك سأقول، «فيندبيد (Req.params.dished)»

279
00:23:20,260 --> 00:23:24,565
وبعد ذلك والآخر.

280
00:23:24,565 --> 00:23:30,520
لذلك أنا فقط ذاهب لنسخ ذلك ثم آخر من

281
00:23:30,520 --> 00:23:38,170
هناك ومن ثم النزول إلى DishRouter

282
00:23:38,170 --> 00:23:46,150
ثم ببساطة لصق ذلك هنا.

283
00:23:46,150 --> 00:23:49,190
لذلك سنقول، "res.statuscode200

284
00:23:49,440 --> 00:23:55,585
تطبيق json.res.jsondish ثم معالجة الخطأ.

285
00:23:55,585 --> 00:24:05,350
بالنسبة لـ POST، من الواضح أننا لن نتعامل مع المشاركة لنقطة نهاية /DISHID.

286
00:24:05,350 --> 00:24:07,635
لذا نحن سَنَتْركُه على هذا النحو.

287
00:24:07,635 --> 00:24:12,740
بالنسبة لـ PUT، سنقوم بتحديث

288
00:24:12,740 --> 00:24:17,975
طبق معين يتم تحديده بواسطة معرف الطبق الخاص به.

289
00:24:17,975 --> 00:24:25,270
لذلك هذا هو المكان الذي سوف نستخدم الأطباق. findbyidandupdate.

290
00:24:25,270 --> 00:24:27,690
لذلك هذه هي الطريقة التي سنستخدمها،

291
00:24:27,690 --> 00:24:35,539
findbyidandupdate وهذا يأخذ المعلمة الأولى

292
00:24:37,410 --> 00:24:44,410
req.params.Dished والقيمة الثانية هي

293
00:24:44,410 --> 00:24:53,290
المجموعة

294
00:24:53,290 --> 00:24:55,150
وسيكون التحديث في نص الرسالة.

295
00:24:55,150 --> 00:24:57,580
لذلك أنا فقط ذاهب لاسترداد ذلك من

296
00:24:57,580 --> 00:25:05,410
الجسم ريك وبعد ذلك أيضا العلم الآخر الذي أنا ذاهب إلى الحصول عليه.

297
00:25:05,410 --> 00:25:10,840
لذلك سوف نقول، «جديد: صحيح»، بحيث هذه الطريقة فيندبيد ستعيد

298
00:25:10,840 --> 00:25:18,730
الطبق المحدث كسلسلة جسون في الرد.

299
00:25:18,730 --> 00:25:23,650
لذلك هذا هو ما سأحصل عليه هنا وبعد ذلك عندما تأتي هذه القيمة،

300
00:25:23,650 --> 00:25:26,230
أنا ذاهب فقط لاتخاذ الطبق

301
00:25:26,230 --> 00:25:39,040
وبعد ذلك ببساطة إعادة الطبق إلى جانب العميل.

302
00:25:39,040 --> 00:25:47,095
لذلك سأقول res.jason (طبق) وبعد ذلك سوف نتعامل مع الخطأ في المقابل.

303
00:25:47,095 --> 00:25:49,090
وأخيرا لحذف.

304
00:25:49,090 --> 00:25:50,695
بالنسبة إلى DELETE مرة أخرى،

305
00:25:50,695 --> 00:25:54,880
فإن الطريقة المقابلة التي

306
00:25:54,880 --> 00:26:01,165
سنستخدمها هي طريقة Mongo المسماة FindByidAndRemove.

307
00:26:01,165 --> 00:26:03,760
لذلك يمكنك أن ترى أن لدينا هذه الطريقة تسمى

308
00:26:03,760 --> 00:26:08,080
findbyidandRemove وهذا findbyidandRemove،

309
00:26:08,080 --> 00:26:18,355
سوف تأخذ req.Params.Dished لأن هذا هو الطبق الذي نحاول إزالته.

310
00:26:18,355 --> 00:26:20,970
ثم عندما يتم حذف هذا،

311
00:26:20,970 --> 00:26:23,940
لذلك تماما مثل تعاملنا مع هذا هنا،

312
00:26:23,940 --> 00:26:30,830
لذلك أنا مجرد الذهاب لنسخ هذا الرمز من dishes.Remove.

313
00:26:30,830 --> 00:26:34,350
هو نفس الشيء الذي سأفعله هنا أيضاً

314
00:26:34,350 --> 00:26:38,750
لذلك فيندبيداندريفورم وأيا كان الرد أحصل عليه،

315
00:26:38,750 --> 00:26:41,970
وأنا ذاهب لإعادته إلى موكلي.

316
00:26:41,970 --> 00:26:45,490
مع هذا قمنا بتحديث ديشروتر.

317
00:26:45,490 --> 00:26:49,960
دعونا حفظ جميع التغييرات التي قمنا بها حتى

318
00:26:49,960 --> 00:26:57,185
الآن وبعد ذلك سنذهب وبدء الخادم لدينا ومن ثم نرى ما يفعل.

319
00:26:57,185 --> 00:27:01,370
حتى الذهاب إلى المحطة أو نافذة الأوامر، بدء تشغيل الخادم.

320
00:27:01,370 --> 00:27:06,045
لذلك سأقول «npm start» والخادم الآن قيد التشغيل.

321
00:27:06,045 --> 00:27:12,030
سنستخدم ساعي البريد للتواصل مع هذا الخادم

322
00:27:12,030 --> 00:27:15,700
لذلك دعونا نذهب إلى ساعي البريد ومن ثم تنفيذ عمليات معينة.

323
00:27:15,700 --> 00:27:19,030
لذا هنا ترى ساعي البريد الخاص بي يركض هنا

324
00:27:19,030 --> 00:27:26,450
لذلك اسمحوا لي أن أفعل عملية GET على المضيف المحلي: 3000/أطباق.

325
00:27:28,300 --> 00:27:31,875
لذلك عندما تقوم بعملية GET كما ترى،

326
00:27:31,875 --> 00:27:33,205
ستعود سلسلة فارغة.

327
00:27:33,205 --> 00:27:36,715
قاعدة البيانات الخاصة بي فارغة الآن لذلك ليس لدي أي شيء هناك.

328
00:27:36,715 --> 00:27:40,205
لذلك أنا ذاهب فقط ليتم إرجاع سلسلة فارغة.

329
00:27:40,205 --> 00:27:45,600
دعونا نشر طبق.

330
00:27:46,020 --> 00:27:48,340
لذلك عند نشر طبق،

331
00:27:48,340 --> 00:27:50,254
من الواضح في الجسم،

332
00:27:50,254 --> 00:27:58,175
سوف تكون أرفق طبق وسيتم تعيين الجسم ليكون نوع json التطبيق.

333
00:27:58,175 --> 00:28:00,785
الآن، لنشر طبق،

334
00:28:00,785 --> 00:28:06,770
لقد أعطيتك بالفعل ملف db.json في موارد التمرين.

335
00:28:06,770 --> 00:28:10,880
حتى مجرد فتح ملف db.json ثم نسخ الطبق الأول جدا من

336
00:28:10,880 --> 00:28:15,390
هناك ومن ثم سنقوم لصقه هنا ثم نشر هذا الطبق.

337
00:28:15,390 --> 00:28:18,735
لذلك، اسمحوا لي أن أذهب إلى ملف db.jason.

338
00:28:18,735 --> 00:28:21,550
دعني أنسخ الطبق الأول من هنا

339
00:28:21,550 --> 00:28:22,810
لذلك أنا فقط ذاهب لنسخ

340
00:28:22,810 --> 00:28:32,765
الطبق بأكمله على طول الطريق إلى هناك وبعد ذلك أنا ذاهب لنشر هذا الطبق.

341
00:28:32,765 --> 00:28:36,610
هذا يحتوي على الكثير من الحقول التي لدينا هنا بالفعل.

342
00:28:36,610 --> 00:28:39,895
دعونا نشر هذا الطبق إلى الخادم ونرى ما يحدث.

343
00:28:39,895 --> 00:28:44,605
لذا سأعود إلى ساعي البريد

344
00:28:44,605 --> 00:28:47,620
هنا، في بيانات النموذج،

345
00:28:47,620 --> 00:28:51,535
في الجسم، اسمحوا لي لصق الطبق في مكانه.

346
00:28:51,535 --> 00:28:54,760
لذلك، لدينا التفاصيل الكاملة للطبق هناك.

347
00:28:54,760 --> 00:28:58,010
دعونا POST هذا الطبق إلى الخادم.

348
00:28:58,320 --> 00:29:01,780
ثم، بمجرد نشر الطبق إلى الخادم،

349
00:29:01,780 --> 00:29:06,580
ترى أن ساعي البريد لديه،

350
00:29:06,580 --> 00:29:09,700
اسمحوا لي فقط تقليص هذا،

351
00:29:09,700 --> 00:29:18,370
ثم ترى في الجزء السفلي أن هذا الطبق معين قد تم نشره إلى قاعدة البيانات،

352
00:29:18,370 --> 00:29:20,290
إلى قاعدة بيانات MongoDB بواسطة الخادم الخاص بي.

353
00:29:20,290 --> 00:29:23,560
لذلك، ترى أن القيمة التي تم إرجاعها

354
00:29:23,560 --> 00:29:30,760
هنا تظهر عندما تم إدخال الطبق في هذا الخادم.

355
00:29:30,760 --> 00:29:35,020
لذلك، لديك كريتيدات و أوبداتيدات وأضاف هناك.

356
00:29:35,020 --> 00:29:39,880
ترى أن الحقول المتبقية كلها مخزنة هناك.

357
00:29:39,880 --> 00:29:45,865
لاحظ بشكل خاص كيف يتم تخزين قيمة السعر هناك.

358
00:29:45,865 --> 00:29:49,820
هذه هي الطريقة التي تخزن بها العملة قيمة السعر.

359
00:29:50,630 --> 00:29:53,825
لذلك، عندما تحصل على قيمة الإرجاع،

360
00:29:53,825 --> 00:29:59,370
تحتاج إلى تفسير هذا بشكل مناسب على جانب العميل الخاص بك ما يعنيه ذلك.

361
00:29:59,370 --> 00:30:08,510
لاحظ أيضًا أنه تمت إضافة المعرف إلى طبقي ولكل تعليق نفسه،

362
00:30:08,510 --> 00:30:11,445
لأن كل تعليق من التعليقات هو نفسه مستند فرعي.

363
00:30:11,445 --> 00:30:14,370
سيكون لديك UpdateDat و CreateDat إضافة،

364
00:30:14,370 --> 00:30:21,115
والمعرف لكل من التعليقات إضافة أيضا في هناك تلقائيا من قبل قاعدة البيانات الخاصة بي.

365
00:30:21,115 --> 00:30:23,080
ها أنت ذا حتى الآن،

366
00:30:23,080 --> 00:30:26,875
تم إضافة هذا الطبق إلى قاعدة البيانات الخاصة بي.

367
00:30:26,875 --> 00:30:29,589
دعونا مرة أخرى تنفيذ عملية جيت،

368
00:30:29,589 --> 00:30:32,244
ومن الواضح في هذه المرحلة،

369
00:30:32,244 --> 00:30:37,135
يجب على الخادم إرجاع طبق معين واحد تمت إضافته في.

370
00:30:37,135 --> 00:30:39,775
لذلك، فإنه سيعود مجموعة من الأطباق هنا،

371
00:30:39,775 --> 00:30:42,190
وذلك كما ترون، فإنه يعود مجموعة من الأطباق.

372
00:30:42,190 --> 00:30:44,050
وبطبيعة الحال، تحتوي هذه المجموعة على طبق واحد فقط

373
00:30:44,050 --> 00:30:47,245
أو أن طبق معين قد عاد هنا.

374
00:30:47,245 --> 00:30:49,585
حتى الآن، جيد جدا.

375
00:30:49,585 --> 00:30:54,895
لذلك، دعونا نفعل PUT على الأطباق ونرى ما يحدث.

376
00:30:54,895 --> 00:30:56,980
عندما تقوم بعمل PUT، من الواضح أنه يقول،

377
00:30:56,980 --> 00:31:02,255
«عملية PUT غير معتمدة على الأطباق»، كما نتوقع.

378
00:31:02,255 --> 00:31:03,770
دعونا نفعل DELETE.

379
00:31:03,770 --> 00:31:05,575
القيام بعملية DELETE،

380
00:31:05,575 --> 00:31:09,030
فإنه يعود هذا الرد قائلا،

381
00:31:09,030 --> 00:31:10,890
«N يساوي واحد»، حسنا،

382
00:31:10,890 --> 00:31:13,570
واحد يعني أنه قد حذف طبق واحد.

383
00:31:13,570 --> 00:31:15,660
دعونا الآن مرة أخرى، قم بإجراء عملية GET،

384
00:31:15,660 --> 00:31:22,850
ومن ثم سترى أن أطباقي فارغة كما توقعنا.

385
00:31:22,980 --> 00:31:25,930
لذلك، ترى أن

386
00:31:25,930 --> 00:31:28,405
عمليات GET و PUT و POST و DELETE كلها تعمل بشكل صحيح.

387
00:31:28,405 --> 00:31:31,225
الآن، اسمحوا لي بوست الطبق مرة أخرى

388
00:31:31,225 --> 00:31:36,110
إلى الخادم لأنني أريد أن يكون طبق واحد في الخادم.

389
00:31:36,270 --> 00:31:38,725
لذلك، اسمحوا لي POST هذا الطبق،

390
00:31:38,725 --> 00:31:41,425
وستلاحظ أن الهوية قد تغيرت الآن.

391
00:31:41,425 --> 00:31:44,110
لذلك، اسمحوا لي أن حدد هذا المعرف،

392
00:31:44,110 --> 00:31:50,630
وبعد ذلك سوف نفعل جيت مع معرف في المكان.

393
00:31:51,990 --> 00:31:55,405
عندما تقوم بعمل GET مع المعرف في مكانه،

394
00:31:55,405 --> 00:32:02,300
ترى أنه يعيد هذا الطبق المحدد كما تتوقعه.

395
00:32:02,760 --> 00:32:07,630
دعونا نذهب إلى المحطة ونرى ما

396
00:32:07,630 --> 00:32:12,125
يتم طباعته على المحطة أو نافذة الأوامر الخاصة بك.

397
00:32:12,125 --> 00:32:15,300
لذلك، الذهاب إلى المحطة أو نافذة الأوامر الخاصة

398
00:32:15,300 --> 00:32:19,360
بك، ترى أنه يقوم بطباعة كل هذه الأشياء على نافذة الأوامر.

399
00:32:19,360 --> 00:32:21,540
لذلك، عندما قمنا بعملية GET الأولى،

400
00:32:21,540 --> 00:32:22,640
تقول، GET /الأطباق.

401
00:32:22,640 --> 00:32:24,375
لذلك، وهذا هو مرة أخرى،

402
00:32:24,375 --> 00:32:28,155
مورغان القيام بهذا العمل بالنسبة لك، فإنه يتم طباعتها،

403
00:32:28,155 --> 00:32:31,170
وتتبع هذه المعلومات وتقول

404
00:32:31,170 --> 00:32:34,575
طبق تم إنشاؤها ومن ثم تم طباعة معلومات طبق معين،

405
00:32:34,575 --> 00:32:38,190
وبعد ذلك يقول POS/أطباق، GET /أطباق،

406
00:32:38,190 --> 00:32:41,130
وبعد ذلك عندما فعلت PUT عاد 403

407
00:32:41,130 --> 00:32:44,170
هناك وكنت مرة أخرى خلق الأطباق وهلم جرا.

408
00:32:44,170 --> 00:32:47,145
لذلك، ترى أن الخادم الخاص بك يقوم بالفعل بكل العمل،

409
00:32:47,145 --> 00:32:53,110
ويتم إدخال هذه الأشياء في قاعدة بيانات MongoDB كما كنت تتوقع.

410
00:32:53,110 --> 00:32:58,540
الآن، نعود إلى ساعي البريد،

411
00:32:58,540 --> 00:33:00,850
دعونا نفعل بوست على الأطباق.

412
00:33:00,850 --> 00:33:03,605
الآن، هذا غير معتمد على جانب الخادم،

413
00:33:03,605 --> 00:33:04,750
لذلك يجب أن يقول الخادم الخاص بك،

414
00:33:04,750 --> 00:33:10,225
«عملية POST غير معتمدة على نقطة النهاية هذه،» كما قد تتوقع ذلك.

415
00:33:10,225 --> 00:33:13,070
دعونا نفعل عملية PUT.

416
00:33:14,430 --> 00:33:17,190
عندما تقوم بعملية PUT،

417
00:33:17,190 --> 00:33:20,955
ما سأقوم به في عملية PUT هو أنني سأقوم

418
00:33:20,955 --> 00:33:26,860
باستبدال التسمية هناك.

419
00:33:26,860 --> 00:33:29,550
لذلك، في جسدي من الرسالة.

420
00:33:29,550 --> 00:33:34,570
لذلك، تذكر أنه إذا نظرتم إلى ملف Db.json،

421
00:33:34,570 --> 00:33:38,180
فإن التسمية

422
00:33:38,180 --> 00:33:51,160
لذلك ستكون جديدة، ولذا سأقوم بتغيير هذه التسمية إلى ساخنة.

423
00:33:51,160 --> 00:33:53,040
نظرًا لأن هذا يجب أن يكون في Json،

424
00:33:53,040 --> 00:33:57,895
لذا قم بتسمية أيضًا في علامات اقتباس Json،

425
00:33:57,895 --> 00:34:02,810
ثم دعنا نقوم بعمل PUT على نقطة النهاية المحددة هذه.

426
00:34:04,080 --> 00:34:07,615
كانت عملية PUT ناجحة،

427
00:34:07,615 --> 00:34:12,280
وهكذا ترى أنه عند الانتهاء من عملية PUT،

428
00:34:12,280 --> 00:34:19,150
ستلاحظ أن التسمية قد تغيرت الآن من جديد إلى ساخن هنا،

429
00:34:19,150 --> 00:34:22,630
ولاحظ على وجه الخصوص، قيمة

430
00:34:22,630 --> 00:34:28,900
CreateDat وقيمة UpdateDat.

431
00:34:28,900 --> 00:34:31,990
لذلك، لاحظ أن هذا السجل تم إنشاؤه

432
00:34:31,990 --> 00:34:36,970
في هذه النقطة الزمنية وتم تحديثه بعد ذلك بقليل.

433
00:34:36,970 --> 00:34:40,000
لذلك، تم التحديث عن طريق عملية بوت التي قمت

434
00:34:40,000 --> 00:34:43,450
بها للتو على هذا الطبق معين.

435
00:34:43,450 --> 00:34:46,240
دعونا حذف الطبق.

436
00:34:46,240 --> 00:34:49,795
هذا مسموح به لذلك، سنقوم بحذف الطبق،

437
00:34:49,795 --> 00:34:54,100
ومن ثم سيتم حذف الطبق وسيتم إرجاع القيمة.

438
00:34:54,100 --> 00:34:58,930
الآن، إذا قمت بإجراء عملية GET

439
00:34:58,930 --> 00:35:04,615
على نقطة نهاية الأطباق، سترى أن هذا سيعود فارغة.

440
00:35:04,615 --> 00:35:09,385
لذلك، كنت قد تمكنت للتو من حذف الطبق من قاعدة البيانات لدينا.

441
00:35:09,385 --> 00:35:14,095
ما سأقوم به هو إجراء

442
00:35:14,095 --> 00:35:20,630
عملية GET على طبق غير موجود ونرى ما يحدث.

443
00:35:20,630 --> 00:35:23,905
عندما أقوم بإجراء عملية GET على طبق غير موجود،

444
00:35:23,905 --> 00:35:27,300
فإنه يعود فارغة لأن هذا الطبق غير موجود.

445
00:35:27,300 --> 00:35:31,570
لذلك، فإنه يعود قيمة فارغة قائلا أن الطبق غير موجود.

446
00:35:31,570 --> 00:35:40,525
الآن، اسمحوا لي بإجراء عملية جيت على غير أوبجكتيد ونرى ما يحدث.

447
00:35:40,525 --> 00:35:44,980
يعود كما ترى.

448
00:35:44,980 --> 00:35:46,465
اسمحوا لي أن معاينة ذلك.

449
00:35:46,465 --> 00:35:51,840
لذلك، تقول، «فشل الإرسال إلى ObjectId للقيمة هنا في المسار.»

450
00:35:51,840 --> 00:35:53,840
لذلك، سأكون من الواضح أن هذا ليس

451
00:35:53,840 --> 00:35:57,565
ObjectId صالح لذلك تمكنت فقط من حذف جزء منه،

452
00:35:57,565 --> 00:36:02,050
ومن ثم تنفيذ العملية حتى يعود خطأ قائلا،

453
00:36:02,050 --> 00:36:04,915
لذلك ترى هناك 500 خطأ خادم داخلي.

454
00:36:04,915 --> 00:36:09,505
لم يتمكن الخادم من التعامل مع هذا ثم إرجاع هذه القيمة هنا.

455
00:36:09,505 --> 00:36:11,925
لذلك، تقول، «لا،

456
00:36:11,925 --> 00:36:13,230
هذا غير مسموح به».

457
00:36:13,230 --> 00:36:18,385
لذلك، لأن هذا ليس ObjectID صالح.

458
00:36:18,385 --> 00:36:22,275
لذلك، حتى يتم التعامل مع الأخطاء بشكل مناسب كما ترون هنا.

459
00:36:22,275 --> 00:36:26,050
لذلك، اسمحوا لي مرة أخرى، القيام بعملية GET على الأطباق،

460
00:36:26,050 --> 00:36:27,975
والخادم الخاص بك لا يزال قيد التشغيل،

461
00:36:27,975 --> 00:36:30,650
وسوف يعود قيمة فارغة هنا.

462
00:36:30,650 --> 00:36:34,465
لذلك، رأينا كيف عن طريق تعديل

463
00:36:34,465 --> 00:36:40,900
خادم REST API الخاص بنا لتكون قادرة على التفاعل مع خادم MongoDB.

464
00:36:40,900 --> 00:36:45,775
لدينا الآن خادم REST API كامل قادر على تخزين

465
00:36:45,775 --> 00:36:48,090
واسترداد وتنفيذ عمليات مختلفة على

466
00:36:48,090 --> 00:36:51,220
البيانات المخزنة على خادم MongoDB الخاص بي.

467
00:36:51,220 --> 00:36:54,535
مع هذا، نكمل هذا التمرين.

468
00:36:54,535 --> 00:36:56,290
لذلك، في هذا التمرين،

469
00:36:56,290 --> 00:37:05,200
رأينا كيف يمكننا التفاعل مع خادم REST API الخاص بنا،

470
00:37:05,200 --> 00:37:07,560
وبدوره، مع خادم MongoDB،

471
00:37:07,560 --> 00:37:12,400
ثم نقوم بالاستفادة من خادم MongoDB لتخزين واسترجاع البيانات من الخادم.

472
00:37:12,400 --> 00:37:14,770
أنت قادر على التفاعل من

473
00:37:14,770 --> 00:37:20,225
تطبيق Express الخاص بنا مع خادم MongoDB باستخدام Mongoose.

474
00:37:20,225 --> 00:37:24,700
هذا هو الوقت المناسب بالنسبة لك للقيام جيت الالتزام مع الرسالة،

475
00:37:24,700 --> 00:37:31,550
«إكسبريس ريست أبي مع النمس الجزء الأول.»