1
00:00:00,000 --> 00:00:03,979
[MUSIC]

2
00:00:03,979 --> 00:00:06,750
Để tôi nghỉ ngơi một chút.

3
00:00:08,010 --> 00:00:09,480
Bắt được anh rồi!

4
00:00:09,480 --> 00:00:10,800
Điều tôi muốn nói là, để

5
00:00:10,800 --> 00:00:16,860
tôi cho các bạn một cái nhìn tổng quan ngắn gọn về chuyển giao nhà nước đại diện.

6
00:00:16,860 --> 00:00:18,670
Chính xác thì nghỉ ngơi là gì?

7
00:00:18,670 --> 00:00:22,900
Làm thế nào để chúng ta sử dụng nó trong ứng dụng góc cạnh của chúng tôi và

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

9
00:00:26,450 --> 00:00:30,050
Làm thế nào để một máy chủ hỗ trợ REST API và

10
00:00:30,050 --> 00:00:35,060
làm thế nào để chúng tôi truy cập API REST từ ứng dụng Angular của chúng tôi?

11
00:00:35,060 --> 00:00:39,170
Hãy nói về điều đó một chút nữa trong bài học này.

12
00:00:39,170 --> 00:00:43,880
Trong bài giảng đặc biệt này, tôi sẽ cung cấp cho bạn một cái nhìn tổng quan ngắn gọn về REST.

13
00:00:46,010 --> 00:00:50,620
Tôi chắc chắn bạn đã nghe thuật ngữ Dịch vụ Web được đề cập

14
00:00:50,620 --> 00:00:53,990
trong thế giới CNTT rất thường xuyên.

15
00:00:53,990 --> 00:00:56,160
Chính xác các dịch vụ web là gì?

16
00:00:56,160 --> 00:01:01,980
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 giữa

17
00:01:01,980 --> 00:01:07,920
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.

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

19
00:01:11,830 --> 00:01:18,100
Bây giờ, điều này có nghĩa là bạn cung cấp một cách chuẩn hóa cho hai

20
00:01:18,100 --> 00:01:22,190
máy được kết nối với internet để có thể giao tiếp với nhau.

21
00:01:23,670 --> 00:01:26,970
Mức bố trí ứng dụng của họ cho các

22
00:01:26,970 --> 00:01:30,920
ứng dụng cơ sở dữ liệu sử dụng các tiêu chuẩn mở.

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

24
00:01:35,710 --> 00:01:37,420
Chúng ta hãy cố gắng phá vỡ chúng và

25
00:01:37,420 --> 00:01:41,640
hiểu một chút về từng điều đó trong bài giảng này.

26
00:01:42,640 --> 00:01:49,570
Hai cách tiếp cận phổ biến được sử dụng để hỗ trợ các dịch vụ web là SOAP,

27
00:01:49,570 --> 00:01:54,720
các dịch vụ web dựa trên giao thức truy cập đối tượng đơn giản,

28
00:01:54,720 --> 00:01:58,820
sử dụng ngôn ngữ mô tả dịch vụ web để

29
00:01:58,820 --> 00:02:03,150
xác định cách hai điểm kết thúc giao tiếp với nhau.

30
00:02:03,150 --> 00:02:07,667
Và thông thường, xà phòng được dựa trên việc sử dụng XML làm

31
00:02:07,667 --> 00:02:12,240
định dạng cho các tin nhắn được trao đổi giữa hai điểm cuối.

32
00:02:13,990 --> 00:02:19,910
Việc chuyển trạng thái trình bày hoặc phần còn lại cũng sử dụng các tiêu chuẩn web, nhưng

33
00:02:19,910 --> 00:02:24,020
việc trao đổi dữ liệu giữa hai điểm cuối có thể là XML hoặc ngày càng tăng.

34
00:02:25,150 --> 00:02:28,960
Sử dụng JSON làm định dạng.

35
00:02:28,960 --> 00:02:34,960
Cách tương tác REST đơn giản hơn so với SOAP và

36
00:02:34,960 --> 00:02:42,940
do đó REST đã tìm thấy triển khai rộng hơn rất nhiều trong các dịch vụ web còn lại.

37
00:02:43,950 --> 00:02:49,230
Thông thường, giao tiếp máy chủ khách được tạo điều kiện bằng cách sử dụng R

38
00:02:49,230 --> 00:02:54,830
EST nơi máy chủ hỗ trợ API REST và máy khách sau đó có thể gọi

39
00:02:54,830 --> 00:03:01,000
điểm cuối REST API của họ để có được thông tin hoặc tải thông tin lên máy chủ.

40
00:03:01,000 --> 00:03:05,910
Một lần nữa, tôi đã đề cập đến từ, gọi rằng điểm kết thúc REST API.

41
00:03:05,910 --> 00:03:09,290
Vì vậy, đây là một vài thuật ngữ mà tôi đã sử dụng.

42
00:03:09,290 --> 00:03:12,460
Hãy làm rõ một số trong số này trong vài slide tiếp theo.

43
00:03:13,790 --> 00:03:18,710
Chuyển trạng thái đại diện là một phong cách kiến trúc phần mềm

44
00:03:18,710 --> 00:03:23,360
đượ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.

45
00:03:24,770 --> 00:03:30,810
Đ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.

46
00:03:30,810 --> 00:03:33,750
Đây là một trong những luận án tiến sĩ đã tạo ra một

47
00:03:33,750 --> 00:03:35,970
thứ gì đó hữu ích cho thế giới.

48
00:03:35,970 --> 00:03:44,250
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.

49
00:03:44,250 --> 00:03:50,410
Đây là một tập hợp các nguyên tắc mạng phác thảo cách tài nguyên có thể

50
00:03:51,630 --> 00:03:57,060
được cung cấp trên máy chủ, và các tài nguyên này có thể được truy cập từ máy khách

51
00:03:57,060 --> 00:04:02,520
bằng cách xác định các tài nguyên bằng cách sử dụng điểm cuối REST API.

52
00:04:02,520 --> 00:04:07,150
Trong phạm vi chuyển giao Nhà nước đại diện có bốn nguyên tắc thiết kế cơ bản.

53
00:04:07,150 --> 00:04:11,310
Đầu tiên và quan trọng nhất, REST được xây dựng dựa trên giao thức HTTP.

54
00:04:11,310 --> 00:04:17,800
Vì vậy, nó sử dụng tất cả các phương pháp HTTP mà chúng ta đã thấy trong bài học trước đó.

55
00:04:17,800 --> 00:04:22,750
Thứ hai, REST được thiết kế là không có trạng thái, nghĩa là máy chủ không lưu trữ

56
00:04:22,750 --> 00:04:27,350
bất kỳ thông tin nào về trạng thái sau khi giao tiếp hoàn tất.

57
00:04:27,350 --> 00:04:31,850
Vì vậy, khi một máy chủ nhận được yêu cầu, máy chủ trả lời và

58
00:04:31,850 --> 00:04:37,020
sau đó, nó không nhớ thêm bất cứ điều gì về

59
00:04:37,020 --> 00:04:39,730
cuộc trò chuyện đó giữa máy khách và máy chủ.

60
00:04:39,730 --> 00:04:44,620
Thứ ba cách REST cung cấp tài nguyên là để

61
00:04:44,620 --> 00:04:49,990
lộ một cấu trúc thư mục như URL thống nhất định vị tài nguyên URL.

62
00:04:51,090 --> 00:04:57,210
Và thứ tư định dạng của họ để trao đổi dữ liệu thường là JSON hoặc

63
00:04:57,210 --> 00:05:02,360
XML, hoặc cả hai có thể được hỗ trợ bằng cách sử dụng REST.

64
00:05:02,360 --> 00:05:07,940
Một trong những động lực để tăng gợi ý REST như một cách để hỗ trợ các

65
00:05:07,940 --> 00:05:14,060
dịch vụ web là nó nắm bắt tất cả những điều tốt đẹp của tất cả World Wide Web.

66
00:05:14,060 --> 00:05:17,130
Và điều đó đã làm cho Word Wide Web thành công.

67
00:05:17,130 --> 00:05:23,240
Việc sử dụng Uniform Resource Indicators hoặc Uniform Resource Locators

68
00:05:23,240 --> 00:05:28,660
, URL, cho phép bạn giải quyết

69
00:05:28,660 --> 00:05:35,370
các tài nguyên bằng cách chỉ định chúng dưới dạng URL, thứ hai là một giao thức đi trên đầu trang của giao thức HTTP.

70
00:05:35,370 --> 00:05:40,820
HTTP đã tìm thấy triển khai rộng rãi trên Internet.

71
00:05:40,820 --> 00:05:46,370
Thứ ba, chu kỳ đáp ứng yêu cầu HTTP nổi tiếng với.

72
00:05:46,370 --> 00:05:51,850
Vì vậy, bạn gửi một yêu cầu, máy chủ nhận được yêu cầu của bạn, xử lý yêu cầu,

73
00:05:51,850 --> 00:05:57,835
gửi phản hồi đến yêu cầu, và máy khách đó nhận được phản hồi,

74
00:05:57,835 --> 00:06:00,845
hành động theo đó, và có thể tạo ra các yêu cầu khác.

75
00:06:00,845 --> 00:06:06,815
Vì vậy, cách tiếp cận này của chu kỳ đáp ứng yêu cầu được thiết lập rất tốt với HTTP

76
00:06:06,815 --> 00:06:14,740
và Web trên toàn thế giới Giao thức HTTP như chúng ta đã thấy trước đó,

77
00:06:14,740 --> 00:06:19,670
chúng ta sẽ sử dụng tất cả các động từ khác nhau mà HTTP cung cấp.

78
00:06:19,670 --> 00:06:23,120
Cụ thể, cổng đặt bài xóa.

79
00:06:23,120 --> 00:06:26,730
Để có thể xác định các hoạt động được thực hiện

80
00:06:26,730 --> 00:06:29,680
trên các tài nguyên được lưu trữ ở phía máy chủ.

81
00:06:29,680 --> 00:06:34,320
Vì vậy, ví dụ, nếu bạn thực hiện một yêu cầu HTTP GET, bạn đang yêu cầu cho

82
00:06:34,320 --> 00:06:36,180
máy chủ để trả về nguồn.

83
00:06:36,180 --> 00:06:41,410
Nếu bạn thực hiện một yêu cầu POST, bạn đang yêu cầu cho máy chủ để tạo một tài nguyên mới.

84
00:06:41,410 --> 00:06:44,330
Nếu bạn thực hiện một yêu cầu PUT, bạn đang yêu cầu máy chủ để cập nhật

85
00:06:44,330 --> 00:06:48,780
một tài nguyên hiện có và nếu bạn phát hành một yêu cầu xóa, bạn đang yêu cầu

86
00:06:48,780 --> 00:06:54,210
máy chủ để xóa tài nguyên được xác định bởi URL cụ thể đó.

87
00:06:54,210 --> 00:06:57,890
Ngoài ra, nó cố gắng để bảo vệ sự bất lực.

88
00:06:57,890 --> 00:07:00,970
Một số hoạt động khi chúng được thực hiện

89
00:07:00,970 --> 00:07:04,370
Thậm chí nhiều lần sẽ không gây ra bất kỳ sự thay đổi của nhà nước.

90
00:07:04,370 --> 00:07:08,160
Một số hoạt động khác, nếu bạn làm chúng liên tiếp,

91
00:07:08,160 --> 00:07:11,170
chúng có thể gây ra sự thay đổi của nhà nước.

92
00:07:11,170 --> 00:07:14,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ó

93
00:07:14,780 --> 00:07:16,660
bất kỳ hậu quả gây hại nào.

94
00:07:16,660 --> 00:07:19,570
Và điều đó phải được thực hiện rất cẩn thận.

95
00:07:21,070 --> 00:07:25,530
Trong thế giới REST, bạn thường nghe mọi người nói về danh từ,

96
00:07:25,530 --> 00:07:28,230
động từ và biểu diễn.

97
00:07:28,230 --> 00:07:34,120
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.

98
00:07:34,120 --> 00:07:36,720
Danh từ, cụ thể, chúng có đầy đủ các tài nguyên và

99
00:07:36,720 --> 00:07:42,580
các tài nguyên này thường được xác định bởi URL của chúng và chúng không bị giới hạn.

100
00:07:42,580 --> 00:07:48,890
Động từ bị hạn chế và những hành động được chỉ định sẽ được thực hiện trên các nguồn tài nguyên.

101
00:07:48,890 --> 00:07:53,200
Và các bài thuyết trình như chúng ta thấy khi thông tin cần phải được chuyển tải từ

102
00:07:53,200 --> 00:07:54,560
máy chủ đến máy khách hoặc

103
00:07:54,560 --> 00:07:58,150
từ máy khách đến máy chủ, cách bạn mã hóa thông tin.

104
00:07:58,150 --> 00:08:02,840
Thông thường hoặc sử dụng JSON hoặc sử dụng XML.

105
00:08:02,840 --> 00:08:08,150
Tài nguyên là sự trừu tượng quan trọng mà REST hoạt động xung quanh để

106
00:08:08,150 --> 00:08:11,787
thông tin được trừu tượng hóa trong tài nguyên.

107
00:08:11,787 --> 00:08:18,690
Và tài nguyên được xác định bằng cách xác định nó bằng cách sử dụng một URI.

108
00:08:18,690 --> 00:08:23,040
Vì vậy, bất kỳ thông tin nào có thể được đóng gói và

109
00:08:23,040 --> 00:08:26,980
được cung cấp có thể được xác định là một nguồn tài nguyên.

110
00:08:26,980 --> 00:08:33,145
Một mẩu thông tin như thời tiết hiện tại tại Hồng Kông có thể là một nguồn tài nguyên,

111
00:08:33,145 --> 00:08:35,465
một hình ảnh có thể là một nguồn tài nguyên.

112
00:08:35,465 --> 00:08:39,915
Một thông tin giá cổ phiếu có thể là một nguồn lực, và như vậy.

113
00:08:39,915 --> 00:08:43,905
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ể

114
00:08:43,905 --> 00:08:47,515
quan tâm, có thể được xác định là một nguồn tài nguyên.

115
00:08:47,515 --> 00:08:50,965
Bạn thậm chí có thể đối phó với các nguồn lực như là tập hợp các nguồn lực

116
00:08:50,965 --> 00:08:55,070
mà máy chủ đó có thể gửi đến khách hàng đó.

117
00:08:55,070 --> 00:09:00,380
Một ví dụ về cách bạn đặt tên tài nguyên được minh họa ở đây.

118
00:09:00,380 --> 00:09:03,898
Vì vậy, chúng tôi sử dụng URI để xác định nguồn.

119
00:09:03,898 --> 00:09:09,575
Việc đọc nhanh thông số kỹ thuật hoặc các URL ở đây sẽ

120
00:09:09,575 --> 00:09:16,525
dễ dàng cho phép bạn hiểu được những gì chúng tôi đang đề cập đến bằng cách sử dụng các URL này.

121
00:09:16,525 --> 00:09:19,675
Vì vậy, ví dụ, một cái gì đó kết thúc với món ăn/,

122
00:09:19,675 --> 00:09:25,495
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.

123
00:09:25,495 --> 00:09:28,909
Giống như món ăn/123 ví dụ,

124
00:09:28,909 --> 00:09:34,150
có thể có nghĩa là món ăn số 123, trong trường hợp này và vân vân.

125
00:09:34,150 --> 00:09:39,530
Vì vậy, rất dễ dàng để nói rằng bạn có thể chỉ định một bộ sưu tập các tài nguyên, và có

126
00:09:39,530 --> 00:09:43,800
thể xác định chúng như là một bộ sưu tập, và sau đó tải chúng xuống dưới dạng một bộ sưu tập.

127
00:09:43,800 --> 00:09:46,960
Hoặc, bạn có thể xác định một tài nguyên cá nhân, và

128
00:09:46,960 --> 00:09:50,070
nói rằng bạn muốn tài nguyên cụ thể đó.

129
00:09:50,070 --> 00:09:53,378
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

130
00:09:53,378 --> 00:09:56,500
mà đặc tả của URI này.

131
00:09:56,500 --> 00:09:58,860
Vì vậy, khi bạn đi qua con đường,

132
00:09:58,860 --> 00:10:04,460
bạn đi từ tổng quát hơn đến cụ thể hơn của tài nguyên đó.

133
00:10:04,460 --> 00:10:08,260
Cấu trúc thư mục này cho phép bạn xác định các tài nguyên mà

134
00:10:09,320 --> 00:10:14,170
bạn cung cấp từ trang web dịch vụ của bạn rất dễ dàng.

135
00:10:14,170 --> 00:10:17,970
Phần thứ hai của REST API là các từ.

136
00:10:17,970 --> 00:10:22,150
Đặc biệt, chúng tôi quan tâm đến 4 động từ của HTTP để lấy,

137
00:10:22,150 --> 00:10:25,320
đặt, đăng, và xóa.

138
00:10:25,320 --> 00:10:30,310
Trong trường hợp này các động từ này sẽ được ngủ trưa trong các hành động mà chúng ta

139
00:10:30,310 --> 00:10:36,165
muốn được thực hiện trên tài nguyên ở phía máy chủ.

140
00:10:36,165 --> 00:10:40,760
GetT có nghĩa là bạn muốn thực hiện một hoạt động đọc trên tài nguyên, có nghĩa là

141
00:10:40,760 --> 00:10:46,550
một khách hàng gửi một yêu cầu get là chỉ ra cho máy chủ rằng nó muốn

142
00:10:46,550 --> 00:10:52,710
có được rằng trình bày của nguồn dữ liệu từ trang web máy chủ đến trang web khách hàng.

143
00:10:52,710 --> 00:10:56,770
POST có nghĩa là bạn muốn tạo một tài nguyên mới và sau đó bạn sẽ.

144
00:10:56,770 --> 00:11:01,700
Chỉ định các chi tiết của tài nguyên trong biểu diễn, nhưng được sử dụng để

145
00:11:01,700 --> 00:11:02,850
xác định tài nguyên.

146
00:11:02,850 --> 00:11:05,900
Sau đó gửi thông tin qua phía máy chủ, do

147
00:11:05,900 --> 00:11:09,590
đó máy chủ sẽ tạo ra các tài nguyên thay mặt cho bạn.

148
00:11:09,590 --> 00:11:12,310
Một PUT sẽ được sửa đổi các nguồn tài nguyên

149
00:11:12,310 --> 00:11:16,030
, và xóa, như bạn mong đợi, là xóa các nguồn.

150
00:11:16,030 --> 00:11:20,550
Vì vậy, như bạn có thể thấy bốn động từ nhận được, đăng, đặt và

151
00:11:20,550 --> 00:11:25,670
xóa được ánh xạ vào bốn hoạt động CRUD mà bạn có thể thực hiện

152
00:11:25,670 --> 00:11:30,140
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ủ.

153
00:11:30,140 --> 00:11:34,130
Các hoạt động đọc, tạo, cập nhật và xóa.

154
00:11:34,130 --> 00:11:39,140
Xây dựng thêm, HTTP GET là một cách để xác định.

155
00:11:39,140 --> 00:11:43,560
Rằng bạn muốn thông tin hoặc bản trình bày của họ về tài nguyên để được

156
00:11:43,560 --> 00:11:46,280
trả lại cho khách hàng từ trang web máy chủ.

157
00:11:46,280 --> 00:11:49,980
Vì vậy, khi bạn phát hành một yêu cầu GET cho một điểm cuối REST API.

158
00:11:49,980 --> 00:11:54,370
Bạn đang yêu cầu một bộ sưu tập các tài nguyên được trình bày bởi

159
00:11:55,890 --> 00:12:01,790
Uri hoặc một tài nguyên cụ thể được xác định bởi ID của

160
00:12:01,790 --> 00:12:06,950
các tài nguyên cụ thể được xác định trong URL để như bạn thấy trong ví dụ này,

161
00:12:06,950 --> 00:12:13,090
nếu bạn món ăn/452, bạn có nghĩa là để nói rằng món ăn số 452,

162
00:12:13,090 --> 00:12:16,950
với id 452 nên được trả lại cho phía khách hàng.

163
00:12:19,370 --> 00:12:24,210
Tương tự như vậy, hoạt động bài, như chúng ta đã thấy, được sử dụng để tạo ra tài nguyên.

164
00:12:24,210 --> 00:12:29,940
Vì vậy, khi bạn tạo tài nguyên, nội dung mô tả tài nguyên

165
00:12:29,940 --> 00:12:34,830
sẽ ở dạng đại diện JSON hoặc đại diện XML, và điều đó sẽ được

166
00:12:34,830 --> 00:12:40,220
bao gồm trong nội dung của thông báo yêu cầu được gửi đến phía máy chủ.

167
00:12:40,220 --> 00:12:43,900
Vì vậy, một bài hoạt động mong đợi một đại diện

168
00:12:43,900 --> 00:12:49,040
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.

169
00:12:49,040 --> 00:12:53,250
Và máy chủ nhận được thông báo yêu cầu như vậy, máy chủ tạo ra

170
00:12:53,250 --> 00:12:58,440
tài nguyên đó ở phía máy chủ và sau đó trả về hoặc là một xác nhận hoặc

171
00:12:58,440 --> 00:13:04,390
một lỗi để chỉ ra rằng việc tạo tài nguyên không thành công.

172
00:13:04,390 --> 00:13:08,820
Tương tự như vậy nó đặt hoạt động dễ dàng sử dụng để cập nhật một tài nguyên.

173
00:13:08,820 --> 00:13:14,630
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ủ, bạn có thể gửi lại

174
00:13:14,630 --> 00:13:19,630
các sửa đổi hoặc bằng cách chỉ định một phần sửa đổi

175
00:13:19,630 --> 00:13:25,450
mà bạn muốn để có hiệu lực trên các tài nguyên cụ thể trong cơ thể của thư trả lời.

176
00:13:25,450 --> 00:13:29,370
Hoặc bạn có thể gửi đại diện đầy đủ của tài nguyên

177
00:13:29,370 --> 00:13:33,890
trong nội dung của thư, tùy thuộc vào sự sắp xếp giữa máy khách và

178
00:13:33,890 --> 00:13:38,760
máy chủ, máy chủ mong đợi thông tin sẽ được

179
00:13:38,760 --> 00:13:43,320
truyền vào trong nội dung của thư yêu cầu.

180
00:13:43,320 --> 00:13:48,980
Xóa hoạt động như bạn mong đợi xóa tài nguyên hiện có.

181
00:13:48,980 --> 00:13:55,150
Bây giờ trong trường hợp cụ thể này, tất nhiên, một thao tác xóa sẽ là bởi vì

182
00:13:55,150 --> 00:14:00,220
nếu bạn 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.

183
00:14:00,220 --> 00:14:02,440
Nếu bạn đang cố gắng xóa một tài nguyên không tồn tại,

184
00:14:02,440 --> 00:14:07,990
nó sẽ không gây ra bất kỳ sửa đổi nào thêm cho phía máy chủ Ngoại trừ

185
00:14:07,990 --> 00:14:11,808
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.

186
00:14:11,808 --> 00:14:18,700
Tuy nhiên, là một ví dụ về một hoạt động trong trường hợp này.

187
00:14:18,700 --> 00:14:22,810
Tương tự như vậy, thao tác get cũng sẽ hoạt động vì nó không thực

188
00:14:22,810 --> 00:14:27,140
hiện bất kỳ sửa đổi nào đối với tài nguyên trên trang web máy chủ.

189
00:14:27,140 --> 00:14:32,740
Đăng nhập tất nhiên sẽ sửa đổi tài nguyên ở phía máy chủ.

190
00:14:32,740 --> 00:14:34,770
Bạn cần phải tạo một tài nguyên mới hoặc

191
00:14:34,770 --> 00:14:40,050
sửa đổi tài nguyên hiện có ở phía máy chủ, và tất nhiên các bài thuyết trình dữ liệu.

192
00:14:40,050 --> 00:14:45,050
Như tôi đã được nhấn mạnh, hai dự phòng phổ biến cho

193
00:14:45,050 --> 00:14:51,570
đại diện là một trong hai JSON XML, phần cuối cùng

194
00:14:51,570 --> 00:14:57,140
mà chúng ta cần nhấn mạnh là phía máy chủ nên hoàn toàn không có trạng thái.

195
00:14:57,140 --> 00:15:01,190
Có nghĩa là, phía máy chủ không theo dõi trạng thái của khách hàng.

196
00:15:01,190 --> 00:15:07,060
Bởi vì, nếu máy chủ cần theo dõi trạng thái của máy khách, nó sẽ không được mở rộng.

197
00:15:07,060 --> 00:15:11,140
Vì vậy, đối với một triển khai khả năng mở rộng của phía máy chủ,

198
00:15:11,140 --> 00:15:15,650
bạn thường sử dụng một máy chủ không trạng thái ở phía máy chủ.

199
00:15:15,650 --> 00:15:19,580
Vì vậy, nếu yêu cầu của các khách hàng được gửi đến máy chủ sẽ được coi là

200
00:15:19,580 --> 00:15:25,460
một yêu cầu độc lập, và sẽ không phản ánh

201
00:15:25,460 --> 00:15:30,790
các yêu cầu trước đó đã được xử lý bởi máy chủ từ máy khách cụ thể.

202
00:15:30,790 --> 00:15:35,760
Vì vậy, đó là trách nhiệm của khách hàng để theo dõi trạng thái của chính nó.

203
00:15:35,760 --> 00:15:40,770
Hoặc dưới dạng sử dụng cookie hoặc sử dụng cơ sở dữ liệu trang web của khách hàng.

204
00:15:40,770 --> 00:15:43,780
Bất cứ điều gì có nghĩa là phù hợp.

205
00:15:43,780 --> 00:15:48,760
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 có khả năng mở rộng hơn rất nhiều,

206
00:15:48,760 --> 00:15:52,880
bởi vì khách hàng của bạn sẽ chịu trách nhiệm theo dõi của riêng mình.

207
00:15:54,340 --> 00:15:58,880
Và đâ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.

208
00:16:00,100 --> 00:16:04,920
Và cuối cùng chúng ta chưa được thực hiện với REST, chúng ta sẽ thấy nhiều hơn

209
00:16:04,920 --> 00:16:10,280
REST trong các bài tập tiếp theo trong bài học cụ thể này.

210
00:16:10,280 --> 00:16:11,563
Và sau đó,

211
00:16:11,563 --> 00:16:17,206
chúng ta 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.

212
00:16:17,206 --> 00:16:20,509
[ NHẠC]