1
00:00:00,000 --> 00:00:05,340
Bây giờ chúng tôi đã

2
00:00:05,340 --> 00:00:11,610
hoàn thành việc thực hiện máy chủ REST API bằng cách sử dụng Express và MongoDB trong khóa học này,

3
00:00:11,610 --> 00:00:14,990
suy nghĩ ngay lập tức tiếp theo có thể xảy ra trong tâm trí của bạn là,

4
00:00:14,990 --> 00:00:18,555
vì chúng tôi đã phát triển các ứng dụng khách hàng, cho

5
00:00:18,555 --> 00:00:21,460
dù đó là ứng dụng Angular, ứng dụng Ionic,

6
00:00:21,460 --> 00:00:25,380
hoặc Ứng dụng Native Script trong các khóa học trước đây,

7
00:00:25,380 --> 00:00:29,820
làm thế nào để chúng tôi tích hợp hai với nhau để ứng dụng khách hàng của chúng tôi có thể

8
00:00:29,820 --> 00:00:35,780
tương tác với máy chủ API REST đầy đủ mà chúng tôi đã phát triển trong khóa học này?

9
00:00:35,780 --> 00:00:39,605
Vì vậy, đây là những gì chúng ta sẽ kiểm tra trong bài học

10
00:00:39,605 --> 00:00:44,715
này, trong bài giảng này, và hai bài tập theo sau bài giảng này.

11
00:00:44,715 --> 00:00:46,655
Vì vậy, ở phần cuối của bài học này,

12
00:00:46,655 --> 00:00:49,295
bạn sẽ có một khách hàng Angular mà chúng tôi sẽ có

13
00:00:49,295 --> 00:00:52,220
thể giao tiếp với máy chủ mà bạn vừa phát triển trong

14
00:00:52,220 --> 00:00:55,265
khóa học này và có thể hỗ trợ

15
00:00:55,265 --> 00:01:01,410
xem phía khách hàng đầy đủ của toàn bộ ứng dụng của chúng tôi.

16
00:01:01,410 --> 00:01:03,860
Vì vậy, theo cách đó, chúng ta sẽ thấy rằng chúng ta đã

17
00:01:03,860 --> 00:01:11,150
phát triển ứng dụng kết thúc hoàn chỉnh từ phía khách hàng tất cả các cách để phía máy chủ.

18
00:01:11,150 --> 00:01:13,895
Một cách tiếp cận tương tự cũng có thể được sử dụng với

19
00:01:13,895 --> 00:01:17,290
máy khách Ionic của bạn hoặc với máy khách kịch bản gốc của bạn, với

20
00:01:17,290 --> 00:01:20,430
thực tế là cả hai kịch bản Ionic và Native đã được

21
00:01:20,430 --> 00:01:24,420
phát triển với công cụ Angular đằng sau hậu trường.

22
00:01:24,420 --> 00:01:31,100
Vì vậy, thực hiện một tập hợp các bước tương tự sẽ có thể làm cho khách hàng Ionic của bạn và cũng

23
00:01:31,100 --> 00:01:35,240
Native script client của bạn giao tiếp với

24
00:01:35,240 --> 00:01:40,295
máy chủ API phần còn lại Express cộng với MongoDB mà chúng tôi đã phát triển trong khóa học này.

25
00:01:40,295 --> 00:01:43,415
Để tích hợp máy khách và máy chủ,

26
00:01:43,415 --> 00:01:44,810
như chúng tôi đã nhận ra,

27
00:01:44,810 --> 00:01:50,020
máy chủ của chúng tôi đã được triển khai để hỗ trợ API REST đầy đủ.

28
00:01:50,020 --> 00:01:51,695
Từ phía khách hàng của chúng tôi,

29
00:01:51,695 --> 00:01:53,240
cho dù đó là khách hàng góc cạnh,

30
00:01:53,240 --> 00:01:55,750
khách hàng ion hoặc khách hàng kịch bản gốc,

31
00:01:55,750 --> 00:02:00,740
tất cả chúng tương tác với máy chủ bằng cách sử dụng điểm cuối REST API.

32
00:02:00,740 --> 00:02:06,135
Vì vậy, khi máy khách gửi yêu cầu tới máy chủ tại điểm cuối REST API,

33
00:02:06,135 --> 00:02:10,729
máy chủ sẽ đáp ứng với dữ liệu JSON tương ứng trở lại máy khách,

34
00:02:10,729 --> 00:02:16,720
và máy khách sau đó có thể sử dụng dữ liệu JSON để hiển thị các lượt xem cho người dùng.

35
00:02:16,720 --> 00:02:22,970
Vì vậy, với sự hiểu biết này về giao tiếp giữa máy khách và máy

36
00:02:22,970 --> 00:02:25,780
chủ, việc tích hợp phải khá đơn giản.

37
00:02:25,780 --> 00:02:26,960
Nhưng, bây giờ tất nhiên,

38
00:02:26,960 --> 00:02:30,820
khi chúng tôi phát triển của chúng tôi Angular hoặc Ionic hoặc NativeScript client,

39
00:02:30,820 --> 00:02:34,990
chúng tôi đã không làm phần xác thực người dùng chính thức,

40
00:02:34,990 --> 00:02:38,225
bởi vì chúng tôi không có điều đó trong máy chủ JSON của chúng tôi.

41
00:02:38,225 --> 00:02:43,250
Bây giờ chúng tôi có xác thực người dùng được tích

42
00:02:43,250 --> 00:02:47,810
hợp vào phía máy chủ của chúng tôi, chúng tôi cần phải trang bị thêm các ứng dụng khách hàng của

43
00:02:47,810 --> 00:02:52,970
chúng tôi để cho phép họ thực hiện xác thực người dùng ở phía máy chủ,

44
00:02:52,970 --> 00:02:56,660
bằng cách đăng thông tin đăng nhập vào máy chủ và sau đó

45
00:02:56,660 --> 00:03:01,190
lấy mã thông báo xác thực từ phía máy chủ,

46
00:03:01,190 --> 00:03:04,400
và sau đó, giao tiếp với máy chủ bao gồm

47
00:03:04,400 --> 00:03:08,175
mã thông báo xác thực trong tiêu đề của các tin nhắn yêu cầu.

48
00:03:08,175 --> 00:03:10,130
Vì vậy, tất cả điều này có nghĩa là chúng ta cần phải làm

49
00:03:10,130 --> 00:03:12,860
điều chỉnh nhỏ cho cả khách hàng và máy chủ,

50
00:03:12,860 --> 00:03:15,860
để cả hai có thể giao tiếp với nhau.

51
00:03:15,860 --> 00:03:21,020
Một khía cạnh mà tôi đã không xử lý trong bài tập trước đó,

52
00:03:21,020 --> 00:03:26,445
là làm thế nào các máy chủ sẽ xử lý các tham số truy vấn mà đến từ phía khách hàng.

53
00:03:26,445 --> 00:03:27,970
Vì vậy, như chúng tôi nhận ra,

54
00:03:27,970 --> 00:03:31,925
khi phía khách hàng gửi một yêu cầu cho

55
00:03:31,925 --> 00:03:37,360
một món ăn đặc trưng hoặc một nhà lãnh đạo đặc trưng hoặc một chương trình khuyến mãi tính năng

56
00:03:37,360 --> 00:03:41,665
, chúng tôi thấy rằng URL bao gồm

57
00:03:45,095 --> 00:03:48,840
các món ăn, tính năng dấu hỏi bằng đúng trong URL yêu cầu đến từ phía khách hàng.

58
00:03:48,840 --> 00:03:51,670
Bây giờ, trong dữ liệu ở phía máy chủ,

59
00:03:51,670 --> 00:03:54,040
chúng tôi đã thấy rằng món ăn,

60
00:03:54,040 --> 00:03:56,090
chương trình khuyến mãi hoặc nhà lãnh đạo,

61
00:03:56,090 --> 00:03:59,835
bao gồm cờ tính năng đã có trong dữ liệu JSON.

62
00:03:59,835 --> 00:04:02,975
Vì vậy, khi yêu cầu này đến phía máy chủ,

63
00:04:02,975 --> 00:04:10,285
sau đó máy chủ sẽ có thể trích xuất tham số truy vấn này từ yêu cầu đến,

64
00:04:10,285 --> 00:04:16,865
và sau đó một cách thích hợp làm truy vấn của

65
00:04:16,865 --> 00:04:24,485
MongoDB và sau đó có được chỉ kết quả mà cờ đặc trưng này được thiết lập thành true.

66
00:04:24,485 --> 00:04:26,365
Vì vậy, để làm điều đó như chúng ta đã thấy,

67
00:04:26,365 --> 00:04:36,380
URL được sử dụng để gửi yêu cầu đến máy chủ là /dishes? feature=true.

68
00:04:36,380 --> 00:04:42,365
Vì vậy, đó là cách chúng tôi sẽ cung cấp các tham số truy vấn cho phía máy chủ của chúng tôi.

69
00:04:42,365 --> 00:04:47,510
Bây giờ, ngoài ra, khi thông tin này được nhận ở phía máy chủ,

70
00:04:47,510 --> 00:04:51,890
bây giờ, chúng tôi thấy rằng trước đó khi chúng tôi đã làm yêu cầu get ở phía máy chủ,

71
00:04:51,890 --> 00:04:56,975
chúng tôi chỉ đơn giản là nói món ăn tìm thấy và sau đó chúng tôi sẽ tìm thấy tất cả các món ăn và sau đó trả lại chúng

72
00:04:56,975 --> 00:05:03,675
khi yêu cầu get được gửi đến DishRouterRoute/.

73
00:05:03,675 --> 00:05:09,470
Logic tương tự áp dụng cho cả bộ định tuyến quảng cáo cũng như cho bộ định tuyến lãnh đạo.

74
00:05:09,470 --> 00:05:14,805
Bây giờ, khi bạn bao gồm một tham số truy vấn như thế

75
00:05:14,805 --> 00:05:19,270
nào trong URL, phía máy chủ của chúng tôi sẽ có thể trích xuất tham số truy vấn này như thế nào?

76
00:05:19,270 --> 00:05:22,730
Vì vậy, đây là nơi khi yêu cầu đến có

77
00:05:22,730 --> 00:05:27,055
tham số truy vấn này gắn liền với URL đến,

78
00:05:27,055 --> 00:05:31,835
máy chủ express sẽ tự động xử lý điều đó và biến nó thành

79
00:05:31,835 --> 00:05:38,910
một đối tượng JSON được nạp vào một thông điệp yêu cầu đến ở phía máy chủ.

80
00:05:38,910 --> 00:05:45,185
Bây giờ, điều này có sẵn ở phía máy chủ dưới dạng req.query.

81
00:05:45,185 --> 00:05:49,665
Vì vậy, bất cứ tham số truy vấn nào bạn bao gồm trong URL,

82
00:05:49,665 --> 00:05:56,860
sẽ được biến thành các đối tượng JSON tương ứng với các thông tin được thiết lập như được hiển thị ở đây,

83
00:05:56,860 --> 00:06:01,350
và sau đó được nạp vào đối tượng yêu cầu ở phía máy chủ.

84
00:06:01,350 --> 00:06:04,670
Vì vậy, bằng cách sử dụng req.query ở phía máy chủ,

85
00:06:04,670 --> 00:06:08,105
chúng tôi sẽ có thể có được các tham số truy vấn.

86
00:06:08,105 --> 00:06:11,840
Vì vậy, khi bạn thực hiện một yêu cầu get ở phía máy chủ,

87
00:06:11,840 --> 00:06:18,635
bạn nói dishes.find và sau đó bạn bao gồm req.query vào tìm ở đó.

88
00:06:18,635 --> 00:06:25,040
Vì vậy, do đó, khi MongoDB được truy vấn, sau đó,

89
00:06:25,040 --> 00:06:31,160
chỉ những hồ sơ hoặc chỉ những tài liệu mà tính năng được thiết lập thành true sẽ được

90
00:06:31,160 --> 00:06:38,270
trích xuất từ MongoDB và cung cấp lại cho chúng tôi trong phương pháp get này ở đây,

91
00:06:38,270 --> 00:06:41,625
và sau đó, có thể được trả về phía khách hàng.

92
00:06:41,625 --> 00:06:49,745
Vì vậy, điều này là đơn giản như trong việc xử lý các tham số truy vấn ở phía máy chủ của chúng tôi.

93
00:06:49,745 --> 00:06:55,135
Vì vậy, bản cập nhật này chúng tôi sẽ làm cho cả bộ định tuyến đĩa, bộ

94
00:06:55,135 --> 00:07:01,225
định tuyến quảng cáo và bộ định tuyến lãnh đạo ở phía máy chủ của chúng tôi.

95
00:07:01,225 --> 00:07:04,880
Phần tiếp theo là tất nhiên, xác thực người dùng.

96
00:07:04,880 --> 00:07:07,530
Vì vậy, như chúng tôi đã nhận ra ở phía máy chủ,

97
00:07:07,530 --> 00:07:11,095
chúng tôi đã có những điểm cuối REST API này

98
00:07:11,095 --> 00:07:13,780
, rất hữu ích cho việc xác thực người dùng.

99
00:07:13,780 --> 00:07:18,855
Đặc biệt, khi bạn thực hiện một bài đăng lên /users/login,

100
00:07:18,855 --> 00:07:22,040
với tên người dùng và mật khẩu, sau đó,

101
00:07:22,040 --> 00:07:26,140
bạn sẽ có thể xác thực người dùng ở phía máy chủ.

102
00:07:26,140 --> 00:07:30,535
Bây giờ, khi người dùng được xác thực ở phía máy chủ thành công,

103
00:07:30,535 --> 00:07:35,059
thì thông điệp trả lời đến từ phía máy chủ sẽ bao gồm

104
00:07:35,059 --> 00:07:43,345
mã thông báo web JSON trong nội dung trả lời của thông điệp trả lời đến từ phía máy chủ.

105
00:07:43,345 --> 00:07:44,810
Vì vậy, ở phía khách hàng,

106
00:07:44,810 --> 00:07:49,210
chúng ta sẽ có thể trích xuất mã thông báo này và sau đó sử dụng mã thông báo này sau đó.

107
00:07:49,210 --> 00:07:52,700
Vì vậy, khi khách hàng nhận được thông báo trả lời từ

108
00:07:52,700 --> 00:07:57,140
phía máy chủ và người dùng được xác thực thành công ở phía máy chủ,

109
00:07:57,140 --> 00:07:59,690
thông báo trả lời sẽ chứa mã thông báo web JSON,

110
00:07:59,690 --> 00:08:02,290
mà phải được trích xuất, và sau đó,

111
00:08:02,290 --> 00:08:05,240
khách hàng nên bao gồm mã thông báo web JSON này

112
00:08:05,240 --> 00:08:10,620
trong cho mọi yêu cầu gửi đi từ phía khách hàng.

113
00:08:10,620 --> 00:08:13,585
Vậy, làm thế nào để chúng ta xử lý toàn bộ các hoạt động này?

114
00:08:13,585 --> 00:08:15,800
Bây giờ, đây là nơi chúng tôi sẽ thực hiện

115
00:08:15,800 --> 00:08:20,255
một dịch vụ khác sẽ được sử dụng ở phía khách hàng của chúng tôi,

116
00:08:20,255 --> 00:08:21,720
trong máy khách Angular của chúng tôi,

117
00:08:21,720 --> 00:08:23,810
được gọi là dịch vụ xác thực,

118
00:08:23,810 --> 00:08:30,185
và đó là nơi chúng tôi sẽ xử lý toàn bộ đăng nhập và các hoạt động đăng xuất.

119
00:08:30,185 --> 00:08:33,850
Bây giờ, quá trình đăng xuất là khá đơn giản nhưng,

120
00:08:33,850 --> 00:08:37,840
nếu chúng ta phá hủy mã thông báo web JSON mà chúng ta có ở phía khách hàng,

121
00:08:37,840 --> 00:08:41,160
sau đó khách hàng sẽ không còn có thể truy cập vào máy chủ.

122
00:08:41,160 --> 00:08:43,850
Vì vậy, nó là đơn giản như chỉ phá hủy

123
00:08:43,850 --> 00:08:48,095
mã thông báo web JSON ở phía khách hàng để đăng xuất máy khách đó.

124
00:08:48,095 --> 00:08:50,460
Vì vậy, với sự hiểu biết này,

125
00:08:50,460 --> 00:08:54,110
chúng ta hãy xem các bước có liên quan đến

126
00:08:54,110 --> 00:08:59,760
việc thực hiện xác thực người dùng và xử lý xác thực người dùng ở phía khách hàng.

127
00:08:59,760 --> 00:09:03,320
Vì vậy, để xử lý xác thực người dùng ở phía client,

128
00:09:03,320 --> 00:09:08,945
client sẽ gửi một post request tới điểm cuối /users/login,

129
00:09:08,945 --> 00:09:14,110
và phần thân của post request sẽ chứa tên người dùng và mật khẩu.

130
00:09:14,110 --> 00:09:16,660
Chúng tôi đang sử dụng xác thực đăng nhập trong trường hợp này.

131
00:09:16,660 --> 00:09:18,650
Bây giờ, để xác thực Facebook một lần nữa,

132
00:09:18,650 --> 00:09:22,355
đó là một thiết lập khác mà tôi sẽ không thảo luận ngay bây giờ.

133
00:09:22,355 --> 00:09:26,465
Tuy nhiên, nội dung yêu cầu như bạn sẽ thấy để xác thực cục bộ,

134
00:09:26,465 --> 00:09:28,730
sẽ chứa tên người dùng và mật khẩu.

135
00:09:28,730 --> 00:09:33,170
Vì vậy, khi người dùng được xác thực thành công ở phía máy chủ, máy

136
00:09:33,170 --> 00:09:36,410
chủ sau đó sẽ trả lời lại cho máy

137
00:09:36,410 --> 00:09:41,425
khách bằng cách bao gồm mã thông báo web JSON trong thư trả lời.

138
00:09:41,425 --> 00:09:46,070
Vì vậy, khi khách hàng nhận được thông điệp trả lời từ phía máy chủ,

139
00:09:46,070 --> 00:09:49,790
sau đó khách hàng sẽ phải nắm bắt mã thông báo web JSON này,

140
00:09:49,790 --> 00:09:55,025
và sau đó lưu mã thông báo web JSON vào bộ nhớ cục bộ ở phía khách hàng.

141
00:09:55,025 --> 00:10:01,250
Sau đó, khách hàng nên bao gồm mã thông báo này trong mọi yêu cầu gửi đi.

142
00:10:01,250 --> 00:10:04,455
Vì vậy, làm thế nào là điều này được thực hiện ở phía khách hàng?

143
00:10:04,455 --> 00:10:06,155
Trước hết, tất nhiên,

144
00:10:06,155 --> 00:10:11,980
bạn cần lưu mã thông báo web JSON đến vào bộ nhớ cục bộ,

145
00:10:11,980 --> 00:10:16,790
và điều đó được thực hiện trong dịch vụ xác thực mà chúng tôi sẽ thực hiện ở phía khách hàng.

146
00:10:16,790 --> 00:10:19,975
Bây giờ, đối với mọi yêu cầu đi,

147
00:10:19,975 --> 00:10:22,850
khách hàng sẽ bao gồm mã thông báo này vào tiêu

148
00:10:22,850 --> 00:10:27,100
đề, tiêu đề ủy quyền của yêu cầu đi.

149
00:10:27,100 --> 00:10:28,555
Bây giờ, làm thế nào điều này được thực hiện?

150
00:10:28,555 --> 00:10:33,935
Vì vậy, đây là nơi chúng ta sẽ có sự giúp đỡ của một máy đánh chặn HTTP,

151
00:10:33,935 --> 00:10:37,265
rằng HttpClient trong Angular hỗ trợ.

152
00:10:37,265 --> 00:10:39,675
Vì vậy, với máy chặn HTTP,

153
00:10:39,675 --> 00:10:42,305
máy chặn cho phép chúng tôi chặn

154
00:10:42,305 --> 00:10:45,875
mọi tin nhắn yêu cầu gửi đi hoặc thậm chí

155
00:10:45,875 --> 00:10:50,010
chặn mọi tin nhắn trả lời đến nếu bạn chọn.

156
00:10:50,010 --> 00:10:52,175
Nhưng trong ứng dụng Angular,

157
00:10:52,175 --> 00:10:56,215
chúng tôi sẽ được thực hiện các yêu cầu chặn,

158
00:10:56,215 --> 00:10:59,540
mà tôi sẽ minh họa trong bài tập sau này.

159
00:10:59,540 --> 00:11:02,460
Trong trình chặn yêu cầu HTTP,

160
00:11:02,460 --> 00:11:04,375
khi thông điệp yêu cầu bị chặn,

161
00:11:04,375 --> 00:11:09,915
mọi thông điệp yêu cầu đi sẽ bị chặn và sau đó mã thông báo web JSON

162
00:11:09,915 --> 00:11:15,650
sẽ được chèn vào tiêu đề ủy quyền của thông điệp yêu cầu.

163
00:11:15,650 --> 00:11:20,290
Sau đó, thông báo yêu cầu sẽ được chuyển sang phía máy chủ.

164
00:11:20,290 --> 00:11:26,825
Vì vậy, qua đó mọi yêu cầu đi sau khi người dùng được xác thực ở phía máy chủ,

165
00:11:26,825 --> 00:11:30,620
mọi yêu cầu đi từ phía máy khách sẽ mang

166
00:11:30,620 --> 00:11:35,590
mã thông báo web JSON trong tiêu đề ủy quyền của yêu cầu đi.

167
00:11:35,590 --> 00:11:38,600
Bây giờ, một khi khách hàng đăng xuất,

168
00:11:38,600 --> 00:11:42,595
mã thông báo web JSON sẽ bị phá hủy ở phía khách hàng.

169
00:11:42,595 --> 00:11:47,215
Vì vậy, sau đó, các yêu cầu đi sẽ không chứa mã thông báo web JSON nữa,

170
00:11:47,215 --> 00:11:50,160
bởi vì mã thông báo web JSON không tồn tại ở phía máy khách.

171
00:11:50,160 --> 00:11:53,240
Vì vậy, do đó, người dùng mất xác thực.

172
00:11:53,240 --> 00:12:00,030
Vì vậy, đó là cách chúng tôi sẽ xử lý quá trình đăng nhập và đăng xuất ở phía khách hàng,

173
00:12:00,030 --> 00:12:02,290
bằng cách giao tiếp với máy chủ,

174
00:12:02,290 --> 00:12:04,225
và sau đó có được mã thông báo web JSON,

175
00:12:04,225 --> 00:12:08,845
và sau đó bao gồm mã thông báo web JSON trong mọi yêu cầu đi.

176
00:12:08,845 --> 00:12:14,250
Bây giờ, với sự hiểu biết này về cách khách hàng và máy chủ sẽ tương tác,

177
00:12:14,250 --> 00:12:18,205
bây giờ chúng ta hãy tiến hành hai bài tập tiếp theo.

178
00:12:18,205 --> 00:12:22,540
Đầu tiên, chúng tôi sẽ cập nhật phía máy chủ với một vài bổ sung,

179
00:12:22,540 --> 00:12:28,220
để nó có thể tích hợp tốt với trang web khách hàng của chúng tôi.

180
00:12:28,220 --> 00:12:32,750
Sau đó, chúng tôi sẽ cập nhật phía khách hàng hay đúng hơn tôi sẽ cung cấp cho bạn

181
00:12:32,750 --> 00:12:36,215
một ứng dụng khách hàng đầy đủ mà tôi đã

182
00:12:36,215 --> 00:12:40,795
lấy từ khóa học Angular trước đó và sau đó tôi sẽ cập nhật nó,

183
00:12:40,795 --> 00:12:45,875
mà cũng cung cấp cho chúng tôi khả năng sử dụng HTTP chặn

184
00:12:45,875 --> 00:12:51,595
trên cả các yêu cầu đi và tin nhắn trả lời đến.

185
00:12:51,595 --> 00:12:56,090
Vì vậy, chúng tôi sẽ đối phó với cả hai trong hai bài tập tiếp theo,

186
00:12:56,090 --> 00:12:58,370
và ở phần cuối của nó, bạn sẽ hiểu làm thế nào để

187
00:12:58,370 --> 00:13:02,530
tích hợp khách hàng của bạn và phía máy chủ.