1
00:00:03,200 --> 00:00:09,035
Để tôi nghỉ ngơi một chút. Bắt được anh ở đó.

2
00:00:09,035 --> 00:00:11,535
Điều tôi muốn nói là để tôi cho các bạn

3
00:00:11,535 --> 00:00:16,420
một cái nhìn tổng quan ngắn gọn về chuyển giao nhà nước đại diện.

4
00:00:16,420 --> 00:00:18,460
REST chính xác là gì?

5
00:00:18,460 --> 00:00:22,670
Làm thế nào để chúng ta sử dụng nó trong ứng dụng React của chúng tôi,

6
00:00:22,670 --> 00:00:26,130
và làm thế nào để chúng ta sử dụng nó để giao tiếp với máy chủ?

7
00:00:26,130 --> 00:00:29,455
Làm thế nào để một máy chủ hỗ trợ REST API

8
00:00:29,455 --> 00:00:34,615
và làm thế nào để chúng tôi truy cập API REST từ ứng dụng React của chúng tôi?

9
00:00:34,615 --> 00:00:39,230
Chúng ta hãy nói về điều đó một chút nữa trong bài học này.

10
00:00:39,230 --> 00:00:47,680
Tôi chắc chắn bạn đã nghe thuật ngữ dịch vụ web được đề cập trong thế giới CNTT rất thường xuyên.

11
00:00:47,680 --> 00:00:49,895
Chính xác các dịch vụ web là gì?

12
00:00:49,895 --> 00:00:55,520
Dịch vụ Web là một cách thiết kế các hệ thống để hỗ trợ khả năng tương tác

13
00:00:55,520 --> 00:01:01,745
giữa các hệ thống được kết nối qua một mạng như internet như chúng ta thấy ngày nay.

14
00:01:01,745 --> 00:01:05,504
Đây là những gì chúng tôi gọi là một kiến trúc định hướng dịch vụ.

15
00:01:05,504 --> 00:01:09,170
Bây giờ, điều này có nghĩa là bạn cung cấp

16
00:01:09,170 --> 00:01:14,870
một cách chuẩn hóa cho hai máy được kết nối với internet để có thể

17
00:01:14,870 --> 00:01:17,720
giao tiếp với nhau ở

18
00:01:17,720 --> 00:01:24,660
cấp lớp ứng dụng cho các ứng dụng dựa trên web sử dụng các chuẩn mở.

19
00:01:24,660 --> 00:01:29,175
Bây giờ, tôi đã sử dụng rất nhiều thuật ngữ ở đó.

20
00:01:29,175 --> 00:01:32,000
Chúng ta hãy cố gắng phá vỡ chúng và hiểu

21
00:01:32,000 --> 00:01:36,195
một chút về từng điều đó trong bài giảng này.

22
00:01:36,195 --> 00:01:43,390
Hai cách tiếp cận phổ biến được sử dụng để hỗ trợ các dịch vụ web là SOAP.

23
00:01:43,390 --> 00:01:49,550
Các dịch vụ web dựa trên giao thức truy cập đối tượng đơn giản sử dụng

24
00:01:49,550 --> 00:01:52,805
ngôn ngữ mô tả dịch vụ web

25
00:01:52,805 --> 00:01:57,080
để xác định cách hai điểm cuối giao tiếp với nhau.

26
00:01:57,080 --> 00:02:01,700
Thông thường SOAP dựa trên việc sử dụng XML làm

27
00:02:01,700 --> 00:02:07,340
định dạng cho các thư được trao đổi giữa hai điểm cuối.

28
00:02:07,340 --> 00:02:12,975
Chuyển trạng thái đại diện hay REST cũng sử dụng

29
00:02:12,975 --> 00:02:17,240
các tiêu chuẩn web, nhưng việc trao đổi dữ liệu giữa hai điểm cuối có thể là XML hoặc

30
00:02:17,240 --> 00:02:22,385
ngày càng sử dụng JSON làm định dạng.

31
00:02:22,385 --> 00:02:29,705
Cách tương tác REST đơn giản hơn so với SOAP và do đó,

32
00:02:29,705 --> 00:02:37,650
REST đã tìm thấy triển khai rộng hơn rất nhiều trong thế giới dịch vụ web.

33
00:02:37,650 --> 00:02:41,215
Thông thường, giao tiếp client-server được

34
00:02:41,215 --> 00:02:45,830
tạo điều kiện bằng cách sử dụng REST nơi máy chủ hỗ trợ một REST API và máy

35
00:02:45,830 --> 00:02:49,960
khách sau đó có thể gọi các điểm cuối REST API

36
00:02:49,960 --> 00:02:54,595
để có được thông tin hoặc tải thông tin lên máy chủ.

37
00:02:54,595 --> 00:02:59,885
Một lần nữa, tôi đã đề cập từ gọi các điểm cuối REST API,

38
00:02:59,885 --> 00:03:03,210
vì vậy đây là một vài thuật ngữ mà tôi đã sử dụng.

39
00:03:03,210 --> 00:03:07,385
Hãy làm rõ một số trong số này trong vài trang trình bày tiếp theo.

40
00:03:07,385 --> 00:03:12,590
Chuyển giao trạng thái đại diện là một phong cách kiến trúc phần mềm

41
00:03:12,590 --> 00:03:18,200
được thiết kế đặc biệt cho các siêu phương tiện truyền thông phân tán qua World Wide Web.

42
00:03:18,200 --> 00:03:24,604
Điều này lần đầu tiên được Roy Fielding giới thiệu trong luận án tiến sĩ của ông.

43
00:03:24,604 --> 00:03:26,990
Đây là một trong những luận án tiến sĩ

44
00:03:26,990 --> 00:03:29,660
thực sự tạo ra một thứ gì đó hữu ích cho thế giới.

45
00:03:29,660 --> 00:03:38,690
Vì vậy, điều này đã tìm thấy một lần nữa rất nhiều lực kéo trong thế giới dịch vụ web.

46
00:03:38,690 --> 00:03:42,800
Đây là một tập hợp các nguyên tắc mạng phác thảo cách

47
00:03:42,800 --> 00:03:47,300
tài nguyên có thể được cung cấp trên máy chủ

48
00:03:47,300 --> 00:03:50,950
và các tài nguyên này có thể được truy cập từ máy khách

49
00:03:50,950 --> 00:03:56,285
bằng cách xác định các tài nguyên bằng cách sử dụng các điểm cuối API còn lại.

50
00:03:56,285 --> 00:03:58,855
Trong phạm vi chuyển giao Nhà nước đại diện,

51
00:03:58,855 --> 00:04:01,050
có bốn nguyên tắc thiết kế cơ bản.

52
00:04:01,050 --> 00:04:05,375
Đầu tiên và quan trọng nhất, REST được xây dựng dựa trên giao thức HTTP,

53
00:04:05,375 --> 00:04:11,365
vì vậy nó sử dụng tất cả các phương thức HTTP mà chúng ta đã thấy trong bài học trước đó.

54
00:04:11,365 --> 00:04:15,045
Thứ hai, REST được thiết kế là không có trạng thái,

55
00:04:15,045 --> 00:04:17,930
nghĩa là máy chủ không lưu trữ bất kỳ thông tin nào về

56
00:04:17,930 --> 00:04:21,450
trạng thái sau khi giao tiếp hoàn tất.

57
00:04:21,450 --> 00:04:25,615
Vì vậy, khi một máy chủ nhận được yêu cầu, máy chủ trả lời,

58
00:04:25,615 --> 00:04:29,110
và sau đó nó không nhớ

59
00:04:29,110 --> 00:04:33,340
thêm bất cứ điều gì về cuộc trò chuyện giữa máy khách và máy chủ.

60
00:04:33,340 --> 00:04:38,635
Thứ ba, cách REST cung cấp tài nguyên là

61
00:04:38,635 --> 00:04:44,945
phơi bày một cấu trúc thư mục như URL (Uniform Resource Locators - URL).

62
00:04:44,945 --> 00:04:50,230
Thứ tư, định dạng cho trao đổi dữ liệu thường là JSON

63
00:04:50,230 --> 00:04:56,145
hoặc XML hoặc cả hai có thể được hỗ trợ bằng cách sử dụng REST.

64
00:04:56,145 --> 00:05:03,350
Một trong những động lực cho Roy gợi ý REST như một cách để hỗ trợ các dịch vụ web

65
00:05:03,350 --> 00:05:06,620
là nó nắm bắt tất cả những điều tốt đẹp về

66
00:05:06,620 --> 00:05:10,880
World Wide Web và điều đó làm cho World Wide Web thành công.

67
00:05:10,880 --> 00:05:14,040
Việc sử dụng Uniform Resource Indicators hoặc

68
00:05:14,040 --> 00:05:18,320
Uniform Resource Locators (URL) cho phép bạn

69
00:05:18,320 --> 00:05:23,170
giải quyết các tài nguyên bằng cách chỉ định chúng dưới dạng URL.

70
00:05:23,170 --> 00:05:29,390
Thứ hai, là một giao thức sống trên đầu trang của giao thức HTTP.

71
00:05:29,390 --> 00:05:34,600
HTTP đã tìm thấy triển khai rộng rãi trên internet.

72
00:05:34,600 --> 00:05:40,135
Thứ ba, chu kỳ đáp ứng yêu cầu HTTP được biết đến với.

73
00:05:40,135 --> 00:05:42,420
Vì vậy, bạn gửi một yêu cầu,

74
00:05:42,420 --> 00:05:45,775
máy chủ nhận được yêu cầu của bạn, xử lý yêu cầu,

75
00:05:45,775 --> 00:05:49,530
gửi phản hồi đến yêu cầu,

76
00:05:49,530 --> 00:05:51,830
và khách hàng nhận được phản hồi,

77
00:05:51,830 --> 00:05:54,765
hành động theo đó, và có thể tạo ra các yêu cầu khác.

78
00:05:54,765 --> 00:05:58,580
Vì vậy, cách tiếp cận này của chu kỳ đáp ứng yêu cầu được

79
00:05:58,580 --> 00:06:03,115
thiết lập rất tốt với HTTP và World Wide Web.

80
00:06:03,115 --> 00:06:08,505
Bây giờ, giao thức HTTP như chúng ta đã thấy trước đó,

81
00:06:08,505 --> 00:06:13,650
chúng ta sẽ sử dụng tất cả các động từ khác nhau mà HTTP cung cấp.

82
00:06:13,650 --> 00:06:15,520
cụ thể, GET, PUT,

83
00:06:15,520 --> 00:06:18,635
POST và DELETE để có thể

84
00:06:18,635 --> 00:06:23,480
xác định các hoạt động được thực hiện trên tài nguyên được lưu trữ ở phía máy chủ.

85
00:06:23,480 --> 00:06:27,470
Vì vậy, ví dụ, nếu bạn thực hiện một yêu cầu HTTP GET,

86
00:06:27,470 --> 00:06:30,125
bạn đang yêu cầu cho máy chủ để trả về tài nguyên.

87
00:06:30,125 --> 00:06:32,415
Nếu bạn thực hiện một yêu cầu POST,

88
00:06:32,415 --> 00:06:35,415
bạn đang yêu cầu máy chủ để tạo một tài nguyên mới.

89
00:06:35,415 --> 00:06:36,670
Nếu bạn thực hiện một yêu cầu PUT,

90
00:06:36,670 --> 00:06:39,650
bạn đang yêu cầu cho máy chủ để cập nhật một tài nguyên hiện có.

91
00:06:39,650 --> 00:06:42,170
Và nếu bạn phát hành một yêu cầu DELETE,

92
00:06:42,170 --> 00:06:45,020
bạn đang yêu cầu máy chủ để xóa tài nguyên

93
00:06:45,020 --> 00:06:48,070
được xác định bởi URL cụ thể.

94
00:06:48,070 --> 00:06:51,735
Ngoài ra, nó cố gắng để bảo vệ Idempotence.

95
00:06:51,735 --> 00:06:56,165
Một số hoạt động, khi chúng được thực hiện thậm chí nhiều lần,

96
00:06:56,165 --> 00:06:58,225
sẽ không gây ra bất kỳ sự thay đổi nào của nhà nước.

97
00:06:58,225 --> 00:07:02,085
Một số hoạt động khác, nếu bạn làm chúng liên tiếp,

98
00:07:02,085 --> 00:07:05,170
chúng có thể gây ra một sự thay đổi của nhà nước.

99
00:07:05,170 --> 00:07:08,780
Vì vậy, bạn cần phải cẩn thận về những hoạt động có thể được lặp lại mà không có

100
00:07:08,780 --> 00:07:14,395
bất kỳ hậu quả gây hại và phải được thực hiện rất cẩn thận.

101
00:07:14,395 --> 00:07:21,864
Trong thế giới REST, bạn thường nghe mọi người nói về danh từ, động từ và biểu diễn.

102
00:07:21,864 --> 00:07:27,875
Bây giờ, chúng ta sẽ làm rõ từng cái trong số này một chút chi tiết hơn trong vài trang trình bày tiếp theo.

103
00:07:27,875 --> 00:07:31,760
Danh từ đặc biệt đề cập đến các tài nguyên và các tài nguyên này

104
00:07:31,760 --> 00:07:36,320
thường được xác định bởi các URL của chúng và chúng không bị giới hạn.

105
00:07:36,320 --> 00:07:40,700
Động từ là hạn chế và những chỉ định các hành động cần

106
00:07:40,700 --> 00:07:45,010
thực hiện trên các nguồn lực và biểu diễn như chúng ta thấy.

107
00:07:45,010 --> 00:07:47,285
Khi thông tin cần phải được chuyển tải từ

108
00:07:47,285 --> 00:07:49,910
máy chủ đến máy khách hoặc từ máy khách đến máy chủ,

109
00:07:49,910 --> 00:07:51,855
làm thế nào bạn mã hóa thông tin.

110
00:07:51,855 --> 00:07:56,520
Thông thường, hoặc sử dụng JSON hoặc sử dụng XML.

111
00:07:56,520 --> 00:08:01,895
Tài nguyên là sự trừu tượng quan trọng mà REST hoạt động xung quanh.

112
00:08:01,895 --> 00:08:06,810
Vì vậy, thông tin được trừu tượng dưới dạng một tài nguyên và tài nguyên

113
00:08:06,810 --> 00:08:12,475
được xác định bằng cách chỉ định nó bằng cách sử dụng một URL.

114
00:08:12,475 --> 00:08:18,395
Vì vậy, bất kỳ thông tin nào có thể được đóng gói và được cung cấp, có

115
00:08:18,395 --> 00:08:20,720
thể được xác định là một nguồn tài nguyên.

116
00:08:20,720 --> 00:08:26,980
Một mẩu thông tin như thời tiết hiện tại ở Hồng Kông có thể là một nguồn lực,

117
00:08:26,980 --> 00:08:29,345
một hình ảnh có thể là một nguồn lực,

118
00:08:29,345 --> 00:08:33,985
một thông tin giá cổ phiếu có thể là một nguồn lực và như vậy.

119
00:08:33,985 --> 00:08:38,920
Vì vậy, bất cứ điều gì bạn định nghĩa như là một phần của thông tin mà một khách hàng có thể quan tâm,

120
00:08:38,920 --> 00:08:41,430
có thể được xác định là một nguồn tài nguyên.

121
00:08:41,430 --> 00:08:44,045
Bạn thậm chí có thể đối phó với các nguồn lực như là bộ sưu tập

122
00:08:44,045 --> 00:08:48,740
các nguồn lực mà máy chủ có thể gửi lên cho khách hàng.

123
00:08:48,740 --> 00:08:54,145
Một ví dụ về cách bạn đặt tên tài nguyên được minh họa ở đây.

124
00:08:54,145 --> 00:08:57,740
Vì vậy, chúng tôi sử dụng URI để xác định nguồn.

125
00:08:57,740 --> 00:09:03,355
Đọc nhanh các đặc tả này hoặc URI ở đây sẽ

126
00:09:03,355 --> 00:09:10,460
dễ dàng cho phép bạn hiểu những gì chúng tôi đang đề cập đến bằng cách sử dụng các URI này.

127
00:09:10,460 --> 00:09:14,420
Vì vậy, ví dụ, một cái gì đó kết thúc với món ăn/,

128
00:09:14,420 --> 00:09:19,315
bạn tự động giả định rằng đây là đề cập đến một bộ sưu tập các món ăn.

129
00:09:19,315 --> 00:09:22,795
Nhưng món ăn/123 ví dụ,

130
00:09:22,795 --> 00:09:28,250
có thể có nghĩa là món ăn số 123 trong trường hợp này và như vậy.

131
00:09:28,250 --> 00:09:31,320
Vì vậy, nó rất dễ dàng để lưu và bạn có thể chỉ định

132
00:09:31,320 --> 00:09:34,650
một bộ sưu tập các tài nguyên và có thể xác định

133
00:09:34,650 --> 00:09:38,815
chúng như là một bộ sưu tập và sau đó tải chúng dưới dạng một bộ sưu tập hoặc bạn có thể

134
00:09:38,815 --> 00:09:43,965
xác định một tài nguyên cá nhân và nói rằng bạn muốn tài nguyên cụ thể đó.

135
00:09:43,965 --> 00:09:50,395
Bây giờ, các tài nguyên này có thể được tổ chức thành một hệ thống phân cấp của đặc tả của URI này.

136
00:09:50,395 --> 00:09:52,740
Vì vậy, khi bạn đi qua con đường,

137
00:09:52,740 --> 00:09:58,325
bạn đi từ tổng quát hơn đến cụ thể hơn của tài nguyên.

138
00:09:58,325 --> 00:10:02,110
Cấu trúc thư mục này cho phép bạn xác định các nguồn lực

139
00:10:02,110 --> 00:10:07,780
mà bạn sử dụng hoặc cung cấp từ phía máy chủ của bạn rất dễ dàng.

140
00:10:07,780 --> 00:10:11,585
Phần thứ hai của REST API là các động từ.

141
00:10:11,585 --> 00:10:16,760
Đặc biệt, chúng tôi quan tâm đến bốn động từ của HTTP GET, P

142
00:10:16,760 --> 00:10:19,140
UT, POST và DELETE.

143
00:10:19,140 --> 00:10:24,410
Trong trường hợp này, các động từ này sẽ được ánh xạ thành các hành động mà chúng ta

144
00:10:24,410 --> 00:10:29,755
muốn được thực hiện trên tài nguyên, ở phía máy chủ.

145
00:10:29,755 --> 00:10:34,170
Một GET có nghĩa là bạn muốn thực hiện một thao tác đọc trên tài nguyên.

146
00:10:34,170 --> 00:10:39,980
Vì vậy, có nghĩa là một khách hàng gửi một yêu cầu GET chỉ ra cho máy chủ rằng nó

147
00:10:39,980 --> 00:10:43,480
muốn để có được một đại diện

148
00:10:43,480 --> 00:10:46,380
của tài nguyên đó từ phía máy chủ để phía máy khách.

149
00:10:46,380 --> 00:10:48,960
Một POST có nghĩa là bạn muốn tạo

150
00:10:48,960 --> 00:10:52,755
một tài nguyên mới và sau đó bạn sẽ chỉ định các chi tiết của tài nguyên

151
00:10:52,755 --> 00:10:55,795
trong đại diện được sử dụng

152
00:10:55,795 --> 00:10:59,799
để xác định tài nguyên và sau đó gửi thông tin đó qua phía máy chủ,

153
00:10:59,799 --> 00:11:03,285
do đó máy chủ sẽ tạo ra tài nguyên đó thay mặt cho bạn.

154
00:11:03,285 --> 00:11:06,370
Một PUT sẽ được sửa đổi các nguồn lực và

155
00:11:06,370 --> 00:11:09,955
một DELETE như bạn mong đợi là xóa các nguồn lực.

156
00:11:09,955 --> 00:11:12,995
Vì vậy, như bạn có thể thấy, bốn động từ;

157
00:11:12,995 --> 00:11:15,110
GET, POST, PUT và DELETE,

158
00:11:15,110 --> 00:11:19,180
được ánh xạ vào bốn hoạt động CRUD mà bạn có thể thực

159
00:11:19,180 --> 00:11:24,035
hiện trên một cơ sở dữ liệu lưu trữ các tài nguyên trên phía máy chủ,

160
00:11:24,035 --> 00:11:27,815
các hoạt động đọc, tạo, Cập Nhật và DELETE.

161
00:11:27,815 --> 00:11:33,760
Xây dựng thêm, HTTP GET là một cách xác định rằng bạn

162
00:11:33,760 --> 00:11:36,950
muốn thông tin hoặc đại diện

163
00:11:36,950 --> 00:11:40,235
của tài nguyên được trả lại cho khách hàng từ phía máy chủ.

164
00:11:40,235 --> 00:11:43,890
Vì vậy, khi bạn đưa ra một yêu cầu GET

165
00:11:43,890 --> 00:11:49,130
cho một điểm cuối API REST, bạn đang yêu cầu một tập hợp các tài nguyên đại diện bởi

166
00:11:49,130 --> 00:11:57,530
URI hoặc một tài nguyên cụ thể được xác định bởi ID của tài nguyên cụ thể đó, được

167
00:11:57,530 --> 00:11:59,490
chỉ định trong URL.

168
00:11:59,490 --> 00:12:01,000
Vì vậy, như bạn thấy trong ví dụ này,

169
00:12:01,000 --> 00:12:03,800
nếu bạn nói, món ăn/452,

170
00:12:03,800 --> 00:12:08,320
bạn có nghĩa là để nói rằng món ăn số 452 với

171
00:12:08,320 --> 00:12:13,075
ID 452 nên được trả lại cho phía khách hàng.

172
00:12:13,075 --> 00:12:18,175
Tương tự như vậy, hoạt động POST như chúng ta thấy được sử dụng để tạo ra tài nguyên.

173
00:12:18,175 --> 00:12:20,065
Vì vậy, khi bạn tạo tài

174
00:12:20,065 --> 00:12:26,920
nguyên, nội dung mô tả tài nguyên sẽ ở dạng đại diện JSON hoặc đại

175
00:12:26,920 --> 00:12:29,790
diện XML và sẽ được bao gồm

176
00:12:29,790 --> 00:12:34,075
trong nội dung của thông báo yêu cầu được gửi đến phía máy chủ.

177
00:12:34,075 --> 00:12:38,095
Vì vậy, một hoạt động POST mong đợi một đại diện

178
00:12:38,095 --> 00:12:42,870
của tài nguyên trong một trong hai định dạng JSON hoặc XML trong nội dung của thông điệp yêu cầu.

179
00:12:42,870 --> 00:12:44,890
Khi máy chủ nhận được thông báo yêu cầu đó,

180
00:12:44,890 --> 00:12:49,960
máy chủ tạo ra tài nguyên đó ở phía máy chủ và sau đó trả về

181
00:12:49,960 --> 00:12:58,030
hoặc là một cấu hình hoặc một lỗi để chỉ ra rằng việc tạo tài nguyên thất bại.

182
00:12:58,030 --> 00:13:02,725
Tương tự, một thao tác PUT được sử dụng để cập nhật một tài nguyên.

183
00:13:02,725 --> 00:13:06,315
Khi bạn thực hiện một thao tác PUT trên một nguồn lực ở phía máy chủ,

184
00:13:06,315 --> 00:13:10,200
bạn có thể gửi lại các sửa đổi

185
00:13:10,200 --> 00:13:15,470
hoặc bằng cách chỉ định một phần sửa đổi mà bạn muốn có hiệu lực trên

186
00:13:15,470 --> 00:13:20,200
các tài nguyên cụ thể trong cơ thể của thư trả lời hoặc bạn có thể gửi

187
00:13:20,200 --> 00:13:25,345
đại diện đầy đủ của các tài nguyên trong nội dung của tin nhắn.

188
00:13:25,345 --> 00:13:28,705
Tùy thuộc vào sự sắp xếp giữa máy khách và máy

189
00:13:28,705 --> 00:13:37,195
chủ, máy chủ mong đợi thông tin sẽ được truyền vào trong nội dung của thư yêu cầu.

190
00:13:37,195 --> 00:13:42,600
Một thao tác DELETE như bạn mong đợi xóa tài nguyên hiện có.

191
00:13:42,600 --> 00:13:45,460
Bây giờ, trong trường hợp cụ thể này,

192
00:13:45,460 --> 00:13:49,670
tất nhiên một thao tác DELETE sẽ là idempotent bởi vì nếu bạn

193
00:13:49,670 --> 00:13:54,145
cố gắng xóa một tài nguyên và tài nguyên tồn tại, nó sẽ bị xóa.

194
00:13:54,145 --> 00:13:56,445
Nếu bạn đang cố gắng xóa một tài nguyên không tồn tại,

195
00:13:56,445 --> 00:14:01,220
nó sẽ không gây ra bất kỳ sửa đổi nào cho phía máy chủ,

196
00:14:01,220 --> 00:14:06,165
ngoại trừ việc máy chủ sẽ trả lời với một lỗi nói rằng tài nguyên không tồn tại.

197
00:14:06,165 --> 00:14:12,530
Tuy nhiên, tuy nhiên, DELETE là một ví dụ về một hoạt động idempotent trong trường hợp này.

198
00:14:12,530 --> 00:14:16,510
Tương tự như vậy, các hoạt động GET cũng là một hoạt động idempotent bởi vì nó

199
00:14:16,510 --> 00:14:20,885
không thực hiện bất kỳ sửa đổi tài nguyên ở phía máy chủ.

200
00:14:20,885 --> 00:14:26,925
POST và PUT tất nhiên sẽ sửa đổi tài nguyên ở phía máy chủ,

201
00:14:26,925 --> 00:14:31,940
hoặc là tạo ra một tài nguyên mới hoặc sửa đổi một tài nguyên hiện có ở phía máy chủ.

202
00:14:31,940 --> 00:14:34,060
Tất nhiên, các đại diện,

203
00:14:34,060 --> 00:14:36,730
như tôi đã được nhấn mạnh,

204
00:14:36,730 --> 00:14:43,980
hai định dạng phổ biến để đại diện là JSON hoặc XML.

205
00:14:43,980 --> 00:14:47,105
Phần cuối cùng mà chúng ta cần nhấn mạnh là

206
00:14:47,105 --> 00:14:51,060
phía máy chủ phải hoàn toàn không trạng thái,

207
00:14:51,060 --> 00:14:53,640
có nghĩa là phía máy chủ không theo dõi

208
00:14:53,640 --> 00:14:59,145
trạng thái máy khách vì nếu máy chủ cần theo dõi trạng thái máy khách thì

209
00:14:59,145 --> 00:15:00,935
nó sẽ không thể mở rộng được.

210
00:15:00,935 --> 00:15:05,160
Vì vậy, để thực hiện khả năng mở rộng của phía máy chủ,

211
00:15:05,160 --> 00:15:09,620
bạn thường sử dụng một máy chủ không trạng thái ở phía máy chủ.

212
00:15:09,620 --> 00:15:12,910
Vì vậy, mọi yêu cầu mà máy khách gửi đến máy chủ sẽ được

213
00:15:12,910 --> 00:15:16,490
coi là một yêu cầu độc lập và sẽ

214
00:15:16,490 --> 00:15:20,330
không phản ánh các yêu cầu trước

215
00:15:20,330 --> 00:15:24,685
đó đã được xử lý bởi máy chủ từ máy khách cụ thể đó.

216
00:15:24,685 --> 00:15:29,605
Vì vậy, trách nhiệm của khách hàng để theo dõi trạng thái riêng của mình,

217
00:15:29,605 --> 00:15:34,635
hoặc dưới hình thức sử dụng cookie hoặc sử dụng một cơ sở dữ liệu phía khách hàng,

218
00:15:34,635 --> 00:15:37,435
bất cứ phương tiện nào phù hợp.

219
00:15:37,435 --> 00:15:41,790
Bây giờ, cách tiếp cận này mà khách hàng theo dõi trạng thái riêng của mình

220
00:15:41,790 --> 00:15:44,815
có khả năng mở rộng hơn rất nhiều bởi vì mỗi khách hàng cá nhân

221
00:15:44,815 --> 00:15:48,240
sẽ chịu trách nhiệm theo dõi trạng thái riêng của mình.

222
00:15:48,240 --> 00:15:53,840
Đây là nơi thiết lập MVC phía khách hàng giúp chúng tôi trong vấn đề này.

223
00:15:53,840 --> 00:15:57,440
Cuối cùng, chúng tôi chưa được thực hiện với REST.

224
00:15:57,440 --> 00:16:04,145
Chúng ta sẽ thấy nhiều hơn về REST trong các bài tập theo sau trong bài học cụ thể này

225
00:16:04,145 --> 00:16:12,310
và sau đó chúng ta cũng sẽ xem thêm chi tiết về việc sử dụng REST trong phần còn lại của khóa học này.