1
00:00:03,200 --> 00:00:09,035
Позвольте мне дать вам небольшой отдых. Взял тебя туда.

2
00:00:09,035 --> 00:00:11,535
Я хотел сказать, что позвольте мне дать вам

3
00:00:11,535 --> 00:00:16,420
краткий обзор репрезентативной передачи государства.

4
00:00:16,420 --> 00:00:18,460
Что именно такое REST?

5
00:00:18,460 --> 00:00:22,670
Как мы используем его в нашем приложении React,

6
00:00:22,670 --> 00:00:26,130
и как мы используем это для связи с сервером?

7
00:00:26,130 --> 00:00:29,455
Как сервер поддерживает REST API

8
00:00:29,455 --> 00:00:34,615
и как мы получаем доступ к REST API из нашего приложения React?

9
00:00:34,615 --> 00:00:39,230
Давайте поговорим об этом немного больше в этом уроке.

10
00:00:39,230 --> 00:00:47,680
Я уверен, что вы слышали, как термин веб-сервисы упоминается в мире ИТ очень часто.

11
00:00:47,680 --> 00:00:49,895
Что такое веб-сервисы?

12
00:00:49,895 --> 00:00:55,520
Веб-сервисы - это способ проектирования систем для поддержки взаимодействия

13
00:00:55,520 --> 00:01:01,745
между системами, которые подключены через сеть, как Интернет, как мы видим сегодня.

14
00:01:01,745 --> 00:01:05,504
Это то, что мы называем сервисно-ориентированной архитектурой.

15
00:01:05,504 --> 00:01:09,170
Теперь это означает, что вы предоставляете

16
00:01:09,170 --> 00:01:14,870
стандартизированный способ для двух компьютеров, подключенных к Интернету, чтобы иметь возможность

17
00:01:14,870 --> 00:01:17,720
общаться друг с другом

18
00:01:17,720 --> 00:01:24,660
на уровне приложений для веб-приложений с использованием открытых стандартов.

19
00:01:24,660 --> 00:01:29,175
Я использовал там много жаргона.

20
00:01:29,175 --> 00:01:32,000
Давайте попробуем сломать их и

21
00:01:32,000 --> 00:01:36,195
немного разобраться в каждой из них в этой лекции.

22
00:01:36,195 --> 00:01:43,390
Два общих подхода, которые используются для поддержки веб-сервисов, являются SOAP.

23
00:01:43,390 --> 00:01:49,550
Веб-службы на основе протокола простого доступа к объектам,

24
00:01:49,550 --> 00:01:52,805
использующие язык описания веб-служб для

25
00:01:52,805 --> 00:01:57,080
указания способа взаимодействия между двумя конечными точками.

26
00:01:57,080 --> 00:02:01,700
Как правило, SOAP основан на использовании XML

27
00:02:01,700 --> 00:02:07,340
в качестве формата сообщений, обмениваемых между двумя конечными точками.

28
00:02:07,340 --> 00:02:12,975
Representational State Transfer или REST также использует веб-стандарты,

29
00:02:12,975 --> 00:02:17,240
но обмен данными между двумя конечными точками может быть либо XML, либо

30
00:02:17,240 --> 00:02:22,385
все чаще использовать JSON в качестве формата.

31
00:02:22,385 --> 00:02:29,705
Способ совместимости REST проще по сравнению с SOAP, и, следовательно,

32
00:02:29,705 --> 00:02:37,650
REST нашел гораздо более широкое развертывание в мире веб-сервисов.

33
00:02:37,650 --> 00:02:41,215
Как правило, взаимодействие между клиентом и сервером

34
00:02:41,215 --> 00:02:45,830
упрощается с помощью REST, где сервер поддерживает REST API, и

35
00:02:45,830 --> 00:02:49,960
клиент может затем вызвать конечные точки REST API

36
00:02:49,960 --> 00:02:54,595
для получения информации или загрузки информации на сервер.

37
00:02:54,595 --> 00:02:59,885
Опять же, я упомянул слово, вызывающее конечные точки REST API,

38
00:02:59,885 --> 00:03:03,210
поэтому это несколько терминов, которые я использовал.

39
00:03:03,210 --> 00:03:07,385
Давайте уточним некоторые из них в следующих нескольких слайдах.

40
00:03:07,385 --> 00:03:12,590
Representational State Transfer

41
00:03:12,590 --> 00:03:18,200
— это стиль архитектуры программного обеспечения, который специально разработан для распределенных гипермедиа по всемирной паутине.

42
00:03:18,200 --> 00:03:24,604
Теперь это было впервые представлено Рой Филдингом в его кандидатской диссертации.

43
00:03:24,604 --> 00:03:26,990
Сейчас это одна из тех докторских диссертаций

44
00:03:26,990 --> 00:03:29,660
, которые на самом деле произвели что-то полезное для мира.

45
00:03:29,660 --> 00:03:38,690
Таким образом, это снова нашло много тяги в мире веб-сервисов.

46
00:03:38,690 --> 00:03:42,800
Это набор сетевых принципов, которые определяют, как

47
00:03:42,800 --> 00:03:47,300
ресурсы могут быть доступны на серверах,

48
00:03:47,300 --> 00:03:50,950
и эти ресурсы могут быть доступны от клиентов

49
00:03:50,950 --> 00:03:56,285
путем идентификации ресурсов с помощью конечных точек API отдыха.

50
00:03:56,285 --> 00:03:58,855
В представительском государственном

51
00:03:58,855 --> 00:04:01,050
трансферте есть четыре основных принципа проектирования.

52
00:04:01,050 --> 00:04:05,375
Прежде всего, REST построен на HTTP протоколе,

53
00:04:05,375 --> 00:04:11,365
поэтому он использует все методы HTTP, которые мы уже видели в предыдущем уроке.

54
00:04:11,365 --> 00:04:15,045
Во-вторых, REST предназначен для безгражданства,

55
00:04:15,045 --> 00:04:17,930
что означает, что сервер не хранит никакой информации

56
00:04:17,930 --> 00:04:21,450
о состоянии после завершения связи.

57
00:04:21,450 --> 00:04:25,615
Поэтому, когда сервер получает запрос, сервер отвечает,

58
00:04:25,615 --> 00:04:29,110
а затем он не помнит

59
00:04:29,110 --> 00:04:33,340
ничего больше о разговоре между клиентом и сервером.

60
00:04:33,340 --> 00:04:38,635
В-третьих, способ REST предоставления ресурсов заключается в

61
00:04:38,635 --> 00:04:44,945
раскрытии структуры каталогов, такой как URL-адреса (Uniform Resource Locators - URL).

62
00:04:44,945 --> 00:04:50,230
В-четвертых, формат для обмена данными обычно является JSON

63
00:04:50,230 --> 00:04:56,145
или XML или оба могут поддерживаться с помощью REST.

64
00:04:56,145 --> 00:05:03,350
Одна из мотивов для Рой, предлагающая REST как способ поддержки веб-сервисов, заключается в

65
00:05:03,350 --> 00:05:06,620
том, что он захватывает все вещи, которые хороши

66
00:05:06,620 --> 00:05:10,880
в всемирной паутине, и что сделало Всемирную паутину успешной.

67
00:05:10,880 --> 00:05:14,040
Использование Единых индикаторов ресурсов или

68
00:05:14,040 --> 00:05:18,320
Единых локаторов ресурсов (URL), которые позволяют

69
00:05:18,320 --> 00:05:23,170
обращаться к ресурсам, указав их в качестве URL-адреса.

70
00:05:23,170 --> 00:05:29,390
Второй - это протокол, который живет поверх протокола HTTP.

71
00:05:29,390 --> 00:05:34,600
HTTP уже нашел широкое развертывание в Интернете.

72
00:05:34,600 --> 00:05:40,135
В-третьих, цикл ответа запроса, который известен HTTP.

73
00:05:40,135 --> 00:05:42,420
Таким образом, вы отправляете запрос,

74
00:05:42,420 --> 00:05:45,775
сервер получает ваш запрос, обрабатывает запрос,

75
00:05:45,775 --> 00:05:49,530
отправляет ответ на запрос,

76
00:05:49,530 --> 00:05:51,830
и клиент получает ответ,

77
00:05:51,830 --> 00:05:54,765
действует на него и может генерировать дальнейшие запросы.

78
00:05:54,765 --> 00:05:58,580
Таким образом, этот подход цикла ответа запроса очень

79
00:05:58,580 --> 00:06:03,115
хорошо налажен с HTTP и World Wide Web.

80
00:06:03,115 --> 00:06:08,505
Теперь, протокол HTTP, как мы видели ранее,

81
00:06:08,505 --> 00:06:13,650
мы будем использовать все различные глаголы, которые предоставляет HTTP.

82
00:06:13,650 --> 00:06:15,520
в частности, GET,

83
00:06:15,520 --> 00:06:18,635
PUT, POST и DELETE для

84
00:06:18,635 --> 00:06:23,480
указания операций, которые будут выполняться с ресурсами, хранящимися на стороне сервера.

85
00:06:23,480 --> 00:06:27,470
Так, например, если вы выполняете HTTP-запрос GET,

86
00:06:27,470 --> 00:06:30,125
вы просите сервер вернуть ресурс.

87
00:06:30,125 --> 00:06:32,415
Если вы выполняете запрос POST,

88
00:06:32,415 --> 00:06:35,415
вы запрашиваете сервер для создания нового ресурса.

89
00:06:35,415 --> 00:06:36,670
Если вы выполняете запрос PUT,

90
00:06:36,670 --> 00:06:39,650
вы запрашиваете сервер для обновления существующего ресурса.

91
00:06:39,650 --> 00:06:42,170
И если вы выдаете запрос DELETE,

92
00:06:42,170 --> 00:06:45,020
вы просите сервер удалить ресурс

93
00:06:45,020 --> 00:06:48,070
, идентифицированный конкретным URL-адресом.

94
00:06:48,070 --> 00:06:51,735
Кроме того, он пытается сохранить Idempotence.

95
00:06:51,735 --> 00:06:56,165
Некоторые операции, когда они выполняются даже многократно,

96
00:06:56,165 --> 00:06:58,225
не вызовут никакого изменения состояния.

97
00:06:58,225 --> 00:07:02,085
Некоторые другие операции, если вы выполняете их последовательно,

98
00:07:02,085 --> 00:07:05,170
они могут привести к изменению состояния.

99
00:07:05,170 --> 00:07:08,780
Поэтому вам нужно быть осторожным в отношении того, какие операции могут быть повторены без

100
00:07:08,780 --> 00:07:14,395
каких-либо вредных последствий, и которые должны быть очень тщательно выполнены.

101
00:07:14,395 --> 00:07:21,864
В мире REST вы часто слышите, как люди говорят о существительных, глаголах и представлениях.

102
00:07:21,864 --> 00:07:27,875
Теперь мы уточним каждый из них чуть более подробно в следующих нескольких слайдах.

103
00:07:27,875 --> 00:07:31,760
Существительные конкретно относятся к ресурсам, и эти ресурсы

104
00:07:31,760 --> 00:07:36,320
обычно идентифицируются по их URL-адресам, и они не ограничены.

105
00:07:36,320 --> 00:07:40,700
Глаголы являются ограничением, и они определяют действия, которые должны быть

106
00:07:40,700 --> 00:07:45,010
выполнены на ресурсах и представлениях, как мы видим.

107
00:07:45,010 --> 00:07:47,285
Когда информация должна быть

108
00:07:47,285 --> 00:07:49,910
передана с сервера клиенту или от клиента к серверу,

109
00:07:49,910 --> 00:07:51,855
как вы кодируете информацию.

110
00:07:51,855 --> 00:07:56,520
Как правило, либо с использованием JSON, либо с использованием XML.

111
00:07:56,520 --> 00:08:01,895
Ресурс - это ключевая абстракция, вокруг которой работает REST.

112
00:08:01,895 --> 00:08:06,810
Таким образом, информация абстрагируется в виде ресурса и ресурс

113
00:08:06,810 --> 00:08:12,475
идентифицируется путем указания его с помощью URL.

114
00:08:12,475 --> 00:08:18,395
Таким образом, любая информация, которая может быть инкапсулирована и доступна,

115
00:08:18,395 --> 00:08:20,720
может быть идентифицирована как ресурс.

116
00:08:20,720 --> 00:08:26,980
Часть информации, как текущая погода в Гонконге, может быть ресурсом,

117
00:08:26,980 --> 00:08:29,345
изображение может быть

118
00:08:29,345 --> 00:08:33,985
ресурсом, информация о ценах акций может быть ресурсом и так далее.

119
00:08:33,985 --> 00:08:38,920
Таким образом, все, что вы определяете как часть информации, которая может быть интересна клиенту,

120
00:08:38,920 --> 00:08:41,430
может быть идентифицирована как ресурс.

121
00:08:41,430 --> 00:08:44,045
Вы даже можете иметь дело с ресурсами как с коллекцией

122
00:08:44,045 --> 00:08:48,740
ресурсов, которые сервер может отправить клиенту.

123
00:08:48,740 --> 00:08:54,145
Пример того, как вы называете ресурсы, приведен здесь.

124
00:08:54,145 --> 00:08:57,740
Поэтому мы используем URI для идентификации источника.

125
00:08:57,740 --> 00:09:03,355
Быстрое чтение этих спецификаций или URI здесь

126
00:09:03,355 --> 00:09:10,460
легко позволит вам понять, что мы имеем в виду, используя эти URI.

127
00:09:10,460 --> 00:09:14,420
Так, например, что-то, что заканчивается посудом/,

128
00:09:14,420 --> 00:09:19,315
вы автоматически предполагаете, что это относится к коллекции блюд.

129
00:09:19,315 --> 00:09:22,795
Но тарелки/123, например,

130
00:09:22,795 --> 00:09:28,250
может означать блюдо номер 123 в этом случае и так далее.

131
00:09:28,250 --> 00:09:31,320
Таким образом, это очень легко сохранить, и вы можете указать

132
00:09:31,320 --> 00:09:34,650
коллекцию ресурсов и иметь возможность идентифицировать

133
00:09:34,650 --> 00:09:38,815
их как коллекцию, а затем загрузить их как коллекцию, или вы можете

134
00:09:38,815 --> 00:09:43,965
определить отдельный ресурс и сказать, что вы хотите этот конкретный ресурс.

135
00:09:43,965 --> 00:09:50,395
Теперь эти ресурсы могут быть организованы в иерархию спецификации этого URI.

136
00:09:50,395 --> 00:09:52,740
Таким образом, когда вы пересекаете путь,

137
00:09:52,740 --> 00:09:58,325
вы переходите от более общего к более конкретному ресурсу.

138
00:09:58,325 --> 00:10:02,110
Эта структура каталогов позволяет

139
00:10:02,110 --> 00:10:07,780
легко идентифицировать ресурсы, которые вы используете или предоставляете на стороне сервера.

140
00:10:07,780 --> 00:10:11,585
Вторая часть REST API - это глаголы.

141
00:10:11,585 --> 00:10:16,760
В частности, нас интересуют четыре глагола HTTP GET, PUT

142
00:10:16,760 --> 00:10:19,140
, POST и DELETE.

143
00:10:19,140 --> 00:10:24,410
В этом случае эти глаголы будут сопоставлены в действия, которые мы

144
00:10:24,410 --> 00:10:29,755
хотим выполнить на ресурсе, на стороне сервера.

145
00:10:29,755 --> 00:10:34,170
GET означает, что вы хотите выполнить операцию чтения на ресурсе.

146
00:10:34,170 --> 00:10:43,480
Таким образом, это означает, что клиент, отправляющий запрос GET, указывает серверу,

147
00:10:43,480 --> 00:10:46,380
что он хочет получить представление этого ресурса с серверной стороны на стороне клиента.

148
00:10:46,380 --> 00:10:48,960
POST означает, что вы хотите создать

149
00:10:48,960 --> 00:10:52,755
новый ресурс, а затем вы будете указывать сведения о ресурсе

150
00:10:52,755 --> 00:10:55,795
в представлении, которое используется для

151
00:10:55,795 --> 00:10:59,799
указания ресурса, а затем отправить эту информацию на стороне сервера,

152
00:10:59,799 --> 00:11:03,285
чтобы сервер создавал этот ресурс от вашего имени.

153
00:11:03,285 --> 00:11:06,370
PUT будет модификацией ресурсов и

154
00:11:06,370 --> 00:11:09,955
DELETE, как вы ожидали, это удаление ресурсов.

155
00:11:09,955 --> 00:11:12,995
Таким образом, как вы можете видеть, четыре глагола:

156
00:11:12,995 --> 00:11:15,110
GET, POST, PUT и DELETE,

157
00:11:15,110 --> 00:11:19,180
сопоставляются в четыре операции CRUD, которые вы можете

158
00:11:19,180 --> 00:11:24,035
выполнять в базе данных, которая хранит эти ресурсы на стороне сервера,

159
00:11:24,035 --> 00:11:27,815
операции READ, CREATE, UPDATE и DELETE.

160
00:11:27,815 --> 00:11:33,760
Далее, HTTP GET является способом указания, что вы

161
00:11:33,760 --> 00:11:36,950
хотите,

162
00:11:36,950 --> 00:11:40,235
чтобы информация или представление ресурса были возвращены клиенту со стороны сервера.

163
00:11:40,235 --> 00:11:43,890
Таким образом, когда вы выдаете запрос GET

164
00:11:43,890 --> 00:11:49,130
для конечной точки REST API, вы запрашиваете либо коллекцию ресурсов, представленных

165
00:11:49,130 --> 00:11:57,530
URI, либо конкретный ресурс, который идентифицируется идентификатором этого конкретного ресурса,

166
00:11:57,530 --> 00:11:59,490
указанного в URL-адресе.

167
00:11:59,490 --> 00:12:01,000
Итак, как вы видите в этом примере,

168
00:12:01,000 --> 00:12:03,800
если вы говорите, тарелки/452,

169
00:12:03,800 --> 00:12:08,320
вы имеете в виду, что блюдо номер 452 с

170
00:12:08,320 --> 00:12:13,075
идентификатором 452 должно быть возвращено на стороне клиента.

171
00:12:13,075 --> 00:12:18,175
Аналогично, операция POST, как мы видели, используется для создания ресурса.

172
00:12:18,175 --> 00:12:20,065
Таким образом, при создании ресурса

173
00:12:20,065 --> 00:12:26,920
содержимое описания ресурса будет в виде представления JSON или

174
00:12:26,920 --> 00:12:29,790
XML-представления и будет включено

175
00:12:29,790 --> 00:12:34,075
в тело сообщения запроса, отправляемого на сторону сервера.

176
00:12:34,075 --> 00:12:38,095
Таким образом, операция POST ожидает представление

177
00:12:38,095 --> 00:12:42,870
ресурса в формате JSON или XML в теле сообщения запроса.

178
00:12:42,870 --> 00:12:44,890
Когда сервер получает это сообщение запроса,

179
00:12:44,890 --> 00:12:49,960
сервер создает этот ресурс на стороне сервера, а затем возвращает

180
00:12:49,960 --> 00:12:58,030
либо конформацию, либо ошибку, указывающую на сбой создания ресурса.

181
00:12:58,030 --> 00:13:02,725
Аналогично, операция PUT используется для обновления ресурса.

182
00:13:02,725 --> 00:13:06,315
Когда вы выполняете операцию PUT на ресурсе на стороне сервера,

183
00:13:06,315 --> 00:13:10,200
вы можете отправить изменение,

184
00:13:10,200 --> 00:13:15,470
либо указав только частичное изменение, которое вы хотите воздействовать на

185
00:13:15,470 --> 00:13:20,200
конкретный ресурс в теле ответного сообщения, либо вы можете отправить

186
00:13:20,200 --> 00:13:25,345
полное представление в теле сообщения.

187
00:13:25,345 --> 00:13:28,705
В зависимости от договоренности между клиентом и сервером

188
00:13:28,705 --> 00:13:37,195
сервер ожидает, что информация будет передана в теле сообщения запроса.

189
00:13:37,195 --> 00:13:42,600
Операция DELETE, как вы ожидали, удаляет существующий ресурс.

190
00:13:42,600 --> 00:13:45,460
Теперь, в этом конкретном случае,

191
00:13:45,460 --> 00:13:49,670
конечно, операция DELETE будет идемпотентной, потому что если вы

192
00:13:49,670 --> 00:13:54,145
попытаетесь удалить ресурс и ресурс существует, он будет удален.

193
00:13:54,145 --> 00:13:56,445
Если вы пытаетесь удалить несуществующий ресурс,

194
00:13:56,445 --> 00:14:01,220
это не приведет к дальнейшим изменениям на стороне сервера,

195
00:14:01,220 --> 00:14:06,165
за исключением того, что сервер ответит с ошибкой, говорящей, что ресурс не существует.

196
00:14:06,165 --> 00:14:12,530
Но, тем не менее, DELETE является примером идемпотентной операции в этом случае.

197
00:14:12,530 --> 00:14:16,510
Аналогично, операция GET также является идемпотентной операцией, потому что она

198
00:14:16,510 --> 00:14:20,885
не вносит никаких изменений в ресурс на стороне сервера.

199
00:14:20,885 --> 00:14:26,925
POST и PUT, конечно, собираются изменить ресурс на стороне сервера,

200
00:14:26,925 --> 00:14:31,940
либо создать новый ресурс, либо изменить существующий ресурс на стороне сервера.

201
00:14:31,940 --> 00:14:34,060
Конечно, представления,

202
00:14:34,060 --> 00:14:36,730
как я подчеркивал,

203
00:14:36,730 --> 00:14:43,980
два общих формата для представления - это JSON или XML.

204
00:14:43,980 --> 00:14:47,105
Последняя часть, которую мы должны подчеркнуть, заключается в том,

205
00:14:47,105 --> 00:14:51,060
что серверная сторона должна быть полностью без гражданства, а

206
00:14:51,060 --> 00:14:53,640
это означает, что серверная сторона не отслеживает

207
00:14:53,640 --> 00:14:59,145
состояние клиента, потому что если сервер должен отслеживать состояние клиентов,

208
00:14:59,145 --> 00:15:00,935
он не будет масштабируемым.

209
00:15:00,935 --> 00:15:05,160
Таким образом, для масштабируемой реализации серверной части

210
00:15:05,160 --> 00:15:09,620
вы обычно используете сервер без гражданства на стороне сервера.

211
00:15:09,620 --> 00:15:12,910
Таким образом, каждый запрос, который клиент отправляет на сервер, будет

212
00:15:12,910 --> 00:15:16,490
рассматриваться как независимый запрос и

213
00:15:16,490 --> 00:15:20,330
не будет отражать предыдущие запросы

214
00:15:20,330 --> 00:15:24,685
, которые уже были обработаны сервером от этого конкретного клиента.

215
00:15:24,685 --> 00:15:29,605
Таким образом, клиент несет ответственность за отслеживание своего состояния,

216
00:15:29,605 --> 00:15:34,635
либо в форме использования файлов cookie, либо с помощью клиентской базы данных,

217
00:15:34,635 --> 00:15:37,435
независимо от того, какие средства подходят.

218
00:15:37,435 --> 00:15:41,790
Теперь этот подход, когда клиент отслеживает свое собственное состояние,

219
00:15:41,790 --> 00:15:44,815
намного более масштабируемым, потому что каждый отдельный клиент

220
00:15:44,815 --> 00:15:48,240
будет отвечать за отслеживание своего собственного состояния.

221
00:15:48,240 --> 00:15:53,840
Именно здесь клиентская настройка MVC помогает нам в этом отношении.

222
00:15:53,840 --> 00:15:57,440
Наконец, мы еще не закончили с REST.

223
00:15:57,440 --> 00:16:04,145
Мы увидим больше REST в упражнениях, которые следуют в этом конкретном уроке,

224
00:16:04,145 --> 00:16:12,310
а затем мы также увидим более подробную информацию об использовании REST в остальной части этого курса.