1
00:00:00,000 --> 00:00:03,979
[МУЗЫКА]

2
00:00:03,979 --> 00:00:06,750
Позвольте мне немного отдохнуть.

3
00:00:08,010 --> 00:00:09,480
Я тебя там!

4
00:00:09,480 --> 00:00:10,800
То, что я хотел сказать, было,

5
00:00:10,800 --> 00:00:16,860
позвольте мне дать вам краткий обзор репрезентативного государственного перевода.

6
00:00:16,860 --> 00:00:18,670
Что именно такое отдых?

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

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

9
00:00:26,450 --> 00:00:30,050
Как сервер поддерживает REST API и

10
00:00:30,050 --> 00:00:35,060
, как мы получаем доступ к REST API из нашего углового приложения?

11
00:00:35,060 --> 00:00:39,170
Давайте поговорим об этом немного больше в этом уроке.

12
00:00:39,170 --> 00:00:43,880
В этой конкретной лекции я дам вам краткий обзор REST.

13
00:00:46,010 --> 00:00:50,620
Я уверен, что вы слышали термин Web Services упоминается

14
00:00:50,620 --> 00:00:53,990
в мире ИТ очень часто.

15
00:00:53,990 --> 00:00:56,160
Что такое веб-сервисы?

16
00:00:56,160 --> 00:01:01,980
Веб-сервисы — это способ проектирования систем для поддержки взаимодействия между

17
00:01:01,980 --> 00:01:07,920
системами, которые подключены по сети, как Интернет, как мы видим сегодня.

18
00:01:07,920 --> 00:01:11,830
Это то, что мы называем сервис-ориентированной архитектурой.

19
00:01:11,830 --> 00:01:18,100
Теперь это означает, что вы предоставляете стандартизированный способ для двух компьютеров

20
00:01:18,100 --> 00:01:22,190
, подключенных к Интернету, чтобы иметь возможность общаться друг с другом.

21
00:01:23,670 --> 00:01:26,970
Их уровень макета приложения для приложений баз данных

22
00:01:26,970 --> 00:01:30,920
с использованием открытых стандартов.

23
00:01:30,920 --> 00:01:34,660
Теперь я использовал много жаргона.

24
00:01:35,710 --> 00:01:37,420
Давайте попробуем сломать их и

25
00:01:37,420 --> 00:01:41,640
немного поймем о каждом из них в этой лекции.

26
00:01:42,640 --> 00:01:49,570
Два распространенных подхода, которые используются для поддержки веб-сервисов, являются SOAP,

27
00:01:49,570 --> 00:01:54,720
простые веб-сервисы на основе протокола доступа к объектам,

28
00:01:54,720 --> 00:01:58,820
, который использует язык описания веб-сервисов для

29
00:01:58,820 --> 00:02:03,150
, определяя, как две конечные точки взаимодействуют друг с другом.

30
00:02:03,150 --> 00:02:07,667
И обычно мыло основано на использовании XML в качестве

31
00:02:07,667 --> 00:02:12,240
формата для обмена сообщениями между двумя конечными точками.

32
00:02:13,990 --> 00:02:19,910
Передача или остальное состояние презентации также использует веб-стандарты, но обмен

33
00:02:19,910 --> 00:02:24,020
данных между двумя конечными точками может быть либо XML, либо все чаще.

34
00:02:25,150 --> 00:02:28,960
Использование JSON в качестве формата.

35
00:02:28,960 --> 00:02:34,960
Способ взаимодействия REST проще по сравнению с SOAP и

36
00:02:34,960 --> 00:02:42,940
, поэтому REST нашел гораздо более широкое развертывание в оставшихся веб-сервисах.

37
00:02:43,950 --> 00:02:49,230
Как правило, взаимодействие с клиентским сервером облегчается с помощью REST

38
00:02:49,230 --> 00:02:54,830
, где сервер поддерживает REST API и клиент может затем вызывать свои конечные точки REST API

39
00:02:54,830 --> 00:03:01,000
для получения информации или загрузки информации на сервер.

40
00:03:01,000 --> 00:03:05,910
Опять же, я упомянул слово, вызываю конечную точку REST API.

41
00:03:05,910 --> 00:03:09,290
Итак, это несколько терминов, которые я использовал.

42
00:03:09,290 --> 00:03:12,460
Давайте проясним некоторые из них в следующих нескольких слайдах.

43
00:03:13,790 --> 00:03:18,710
Перенос репрезентативного состояния — это стиль архитектуры программного обеспечения, который

44
00:03:18,710 --> 00:03:23,360
специально разработан для распределенных гипермедиа через World Wide Web.

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

46
00:03:30,810 --> 00:03:33,750
Теперь, это одна из тех кандидатских диссертаций, которые фактически произвели

47
00:03:33,750 --> 00:03:35,970
что-то полезное для мира.

48
00:03:35,970 --> 00:03:44,250
Таким образом, это снова нашло много тяги в мире веб-сервисов.

49
00:03:44,250 --> 00:03:50,410
Это набор сетевых принципов, которые описывают, как ресурсы могут быть доступны на серверах, и к этим ресурсам можно получить доступ от клиентов

50
00:03:51,630 --> 00:04:02,520
путем идентификации ресурсов с помощью конечных точек API REST.

51
00:04:02,520 --> 00:04:07,150
В рамках представительного государственного трансферта существует четыре основных принципа проектирования.

52
00:04:07,150 --> 00:04:11,310
Прежде всего, REST основан на протоколе HTTP.

53
00:04:11,310 --> 00:04:17,800
Таким образом, он использует все методы HTTP, которые мы уже видели в предыдущем уроке.

54
00:04:17,800 --> 00:04:22,750
Во-вторых, REST предназначен для безгражданства, что означает, что сервер не хранит

55
00:04:22,750 --> 00:04:27,350
никакой информации о состоянии после завершения связи.

56
00:04:27,350 --> 00:04:31,850
Поэтому, когда сервер получает запрос, сервер отвечает, а затем

57
00:04:31,850 --> 00:04:37,020
после этого, он ничего не помнит об этом

58
00:04:37,020 --> 00:04:39,730
разговоре между клиентом и сервером.

59
00:04:39,730 --> 00:04:44,620
В-третьих, способ REST предоставления ресурсов состоит в том, чтобы

60
00:04:44,620 --> 00:04:49,990
выставить структуру каталогов, такую как URL-адреса однородных локаторов ресурсов.

61
00:04:51,090 --> 00:04:57,210
И в-четвертых, их формат для обмена данными обычно JSON или

62
00:04:57,210 --> 00:05:02,360
XML, или оба они могут поддерживаться с помощью REST.

63
00:05:02,360 --> 00:05:07,940
Одна из мотиваций для подъема, предлагающая REST как способ поддержки веб-сервисов

64
00:05:07,940 --> 00:05:14,060
, заключается в том, что он захватывает все, что хорошо от всей Всемирной паутины.

65
00:05:14,060 --> 00:05:17,130
И это сделало Word Wide Web успешным.

66
00:05:17,130 --> 00:05:23,240
Использование Uniform Resource Indicators или Uniform Resource Locators, URLs,

67
00:05:23,240 --> 00:05:28,660
, которые позволяют обращаться к ресурсам, указав их в качестве URL,

68
00:05:28,660 --> 00:05:35,370
второй протокол, который находится поверх протокола HTTP.

69
00:05:35,370 --> 00:05:40,820
HTTP уже нашел широкое развертывание в Интернете.

70
00:05:40,820 --> 00:05:46,370
В-третьих, цикл ответа на запрос, которым хорошо известен HTTP.

71
00:05:46,370 --> 00:05:51,850
Таким образом, вы отправляете запрос, сервер получает ваш запрос, обрабатывает запрос,

72
00:05:51,850 --> 00:05:57,835
отправляет ответ на запрос, и клиент получает ответ,

73
00:05:57,835 --> 00:06:00,845
действует на это и может генерировать дальнейшие запросы.

74
00:06:00,845 --> 00:06:06,815
Таким образом, этот подход цикла ответа на запрос очень хорошо установлен с HTTP

75
00:06:06,815 --> 00:06:14,740
и всемирным протоколом Web THe HTTP, как мы видели ранее,

76
00:06:14,740 --> 00:06:19,670
мы будем использовать все различные глаголы, которые предоставляет HTTP.

77
00:06:19,670 --> 00:06:23,120
В частности, ворота положить пост удалить.

78
00:06:23,120 --> 00:06:26,730
Для того, чтобы указать операции, которые должны быть выполнены

79
00:06:26,730 --> 00:06:29,680
на ресурсах, хранящихся на стороне сервера.

80
00:06:29,680 --> 00:06:34,320
Так, например, если вы выполняете запрос HTTP GET, вы запрашиваете

81
00:06:34,320 --> 00:06:36,180
сервер для возврата источника.

82
00:06:36,180 --> 00:06:41,410
Если вы выполняете запрос POST, вы запрашиваете сервер для создания нового ресурса.

83
00:06:41,410 --> 00:06:44,330
Если вы выполняете запрос PUT, вы просите сервер обновить

84
00:06:44,330 --> 00:06:48,780
существующий ресурс, и если вы выдаете запрос на удаление, вы просите

85
00:06:48,780 --> 00:06:54,210
сервер удалить ресурс, идентифицированный по этому конкретному URL-адресу.

86
00:06:54,210 --> 00:06:57,890
Также он пытается сохранить идемпотенцию.

87
00:06:57,890 --> 00:07:00,970
Некоторые операции при их выполнении

88
00:07:00,970 --> 00:07:04,370
Даже многократно не вызовут изменения состояния.

89
00:07:04,370 --> 00:07:08,160
Некоторые другие операции, если вы выполняете их последовательно,

90
00:07:08,160 --> 00:07:11,170
они могут привести к изменению состояния.

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

92
00:07:14,780 --> 00:07:16,660
каких-либо повреждающих последствий.

93
00:07:16,660 --> 00:07:19,570
И которые нужно сделать очень осторожно.

94
00:07:21,070 --> 00:07:25,530
В мире REST вы часто слышите, как люди говорят об существительных,

95
00:07:25,530 --> 00:07:28,230
глаголах и представлениях.

96
00:07:28,230 --> 00:07:34,120
Теперь мы проясним каждый из них немного более подробно в следующих нескольких слайдах.

97
00:07:34,120 --> 00:07:36,720
Существительные, в частности, полны ресурсов и

98
00:07:36,720 --> 00:07:42,580
эти ресурсы обычно идентифицируются по их URL-адресам, и они не ограничены.

99
00:07:42,580 --> 00:07:48,890
Глаголы ограничены, и эти указанные действия должны быть выполнены на ресурсах.

100
00:07:48,890 --> 00:07:53,200
И презентации, как мы видим, когда информация должна быть передана от

101
00:07:53,200 --> 00:07:54,560
сервера клиенту или

102
00:07:54,560 --> 00:07:58,150
от клиента к серверу, как вы кодируете информацию.

103
00:07:58,150 --> 00:08:02,840
Обычно либо с использованием JSON, либо с использованием XML.

104
00:08:02,840 --> 00:08:08,150
Ресурс - это ключевая абстракция, которая работает REST, поэтому

105
00:08:08,150 --> 00:08:11,787
, что информация абстрагируется в ресурсе.

106
00:08:11,787 --> 00:08:18,690
И ресурс идентифицируется, указав его с помощью URI.

107
00:08:18,690 --> 00:08:23,040
Таким образом, любая информация, которая может быть инкапсулирована и

108
00:08:23,040 --> 00:08:26,980
быть доступна, может быть идентифицирована как ресурс.

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

110
00:08:33,145 --> 00:08:35,465
изображение может быть ресурсом.

111
00:08:35,465 --> 00:08:39,915
Информация о ценах акций может быть ресурсом и так далее.

112
00:08:39,915 --> 00:08:43,905
Таким образом, что бы вы ни определяли как часть информации, которую клиент может заинтересовать

113
00:08:43,905 --> 00:08:47,515
, можно идентифицировать как ресурс.

114
00:08:47,515 --> 00:08:50,965
Вы даже можете иметь дело с ресурсами как с коллекцией ресурсов

115
00:08:50,965 --> 00:08:55,070
, которые этот сервер может отправить этому клиенту.

116
00:08:55,070 --> 00:09:00,380
Пример того, как вы называете ресурсы, показан здесь.

117
00:09:00,380 --> 00:09:03,898
Поэтому мы используем URI для идентификации источника.

118
00:09:03,898 --> 00:09:09,575
Быстрое чтение спецификации или URL здесь позволит

119
00:09:09,575 --> 00:09:16,525
легко понять, что мы имеем в виду, используя эти URL-адреса.

120
00:09:16,525 --> 00:09:19,675
Так, например, что-то, что заканчивается на блюде/,

121
00:09:19,675 --> 00:09:25,495
вы автоматически предполагаете, что это относится к коллекции блюд.

122
00:09:25,495 --> 00:09:28,909
Как и посуды/123, например,

123
00:09:28,909 --> 00:09:34,150
может означать блюдо номер 123, в данном случае и так далее.

124
00:09:34,150 --> 00:09:39,530
Так что очень легко сказать, что вы можете указать коллекцию ресурсов, а

125
00:09:39,530 --> 00:09:43,800
сможет идентифицировать их как коллекцию, а затем скачать их как коллекцию.

126
00:09:43,800 --> 00:09:46,960
Или вы можете определить отдельный ресурс, а

127
00:09:46,960 --> 00:09:50,070
сказать, что вы хотите этот конкретный ресурс.

128
00:09:50,070 --> 00:09:53,378
Теперь эти ресурсы могут быть организованы в иерархию

129
00:09:53,378 --> 00:09:56,500
, что спецификация этого URI.

130
00:09:56,500 --> 00:09:58,860
Таким образом, когда вы проходите путь,

131
00:09:58,860 --> 00:10:04,460
вы переходите от более общего к более конкретному из этого ресурса.

132
00:10:04,460 --> 00:10:08,260
Эта структура каталогов позволяет легко идентифицировать ресурсы, которые

133
00:10:09,320 --> 00:10:14,170
вы предоставляете с вашего сайта обслуживания.

134
00:10:14,170 --> 00:10:17,970
Вторая часть REST API - это слова.

135
00:10:17,970 --> 00:10:22,150
В частности, нас интересует 4 глагола HTTP, чтобы получить,

136
00:10:22,150 --> 00:10:25,320
положить, опубликовать и удалить.

137
00:10:25,320 --> 00:10:30,310
В этом случае эти глаголы будут прикасаться к действиям, которые мы

138
00:10:30,310 --> 00:10:36,165
хотим выполнить на ресурсе на стороне сервера.

139
00:10:36,165 --> 00:10:40,760
GETt означает, что вы хотите выполнить операцию чтения на ресурсе, что означает

140
00:10:40,760 --> 00:10:46,550
, что клиент, отправляющий запрос get, указывает серверу, что он хочет

141
00:10:46,550 --> 00:10:52,710
получить представление источника данных с сайта сервера на клиентский сайт.

142
00:10:52,710 --> 00:10:56,770
POST означает, что вы хотите создать новый ресурс, а затем вы будете.

143
00:10:56,770 --> 00:11:01,700
Укажите сведения о ресурсе в представлении, но используется для

144
00:11:01,700 --> 00:11:02,850
указания ресурса.

145
00:11:02,850 --> 00:11:05,900
Затем отправьте информацию на стороне сервера, чтобы

146
00:11:05,900 --> 00:11:09,590
, что сервер создаст ресурс от вашего имени.

147
00:11:09,590 --> 00:11:12,310
PUT будет модификацией ресурсов, а

148
00:11:12,310 --> 00:11:16,030
delete, как вы ожидали, это удаление источников.

149
00:11:16,030 --> 00:11:20,550
Итак, как вы можете видеть четыре глагола получить, пост, поставить и

150
00:11:20,550 --> 00:11:25,670
delete сопоставляются с четырьмя операциями CRUD, которые можно выполнить

151
00:11:25,670 --> 00:11:30,140
в базе данных, хранящей эти ресурсы на стороне сервера.

152
00:11:30,140 --> 00:11:34,130
Операции чтения, создания, обновления и удаления.

153
00:11:34,130 --> 00:11:39,140
Разрабатывая далее, HTTP GET - это способ указания.

154
00:11:39,140 --> 00:11:43,560
Что вы хотите, чтобы информация или их представление ресурса были

155
00:11:43,560 --> 00:11:46,280
возвращены клиенту с сайта сервера.

156
00:11:46,280 --> 00:11:49,980
Поэтому, когда вы выдаете запрос GET конечной точке API REST.

157
00:11:49,980 --> 00:11:54,370
Вы запрашиваете либо коллекцию ресурсов, которые представлены

158
00:11:55,890 --> 00:12:01,790
Uri или конкретный ресурс, который идентифицируется идентификатором

159
00:12:01,790 --> 00:12:06,950
, что конкретные ресурсы, указанные в URL, так как вы видите в этом примере,

160
00:12:06,950 --> 00:12:13,090
, если вы блюдите/452, вы имеете в виду сказать, что блюдо номер 452,

161
00:12:13,090 --> 00:12:16,950
с идентификатором 452 должны быть возвращены на клиентскую сторону.

162
00:12:19,370 --> 00:12:24,210
Аналогично, почтовая операция, как мы видели, используется для создания ресурса.

163
00:12:24,210 --> 00:12:29,940
Таким образом, когда вы создаете ресурс, содержание описания ресурса будет

164
00:12:29,940 --> 00:12:34,830
в виде представления JSON или XML-представления, и это будет

165
00:12:34,830 --> 00:12:40,220
включено в тело сообщения запроса, которое отправляется на стороне сервера.

166
00:12:40,220 --> 00:12:43,900
Таким образом, после операции ожидает представление

167
00:12:43,900 --> 00:12:49,040
ресурса в формате JSON или XML в теле сообщения запроса.

168
00:12:49,040 --> 00:12:53,250
И сервер получает такое сообщение запроса, сервер создает этот ресурс

169
00:12:53,250 --> 00:12:58,440
на стороне сервера, а затем возвращает либо подтверждение, либо

170
00:12:58,440 --> 00:13:04,390
ошибку, указывающую на то, что создание ресурса не удалось.

171
00:13:04,390 --> 00:13:08,820
Точно так же он поставил операцию легко использовать для обновления ресурса.

172
00:13:08,820 --> 00:13:14,630
Когда вы выполняете операцию PUT на ресурсе на стороне сервера, вы можете отправить обратно

173
00:13:14,630 --> 00:13:19,630
модификацию либо указав только частичное изменение

174
00:13:19,630 --> 00:13:25,450
, которое вы хотите воздействовать на конкретный ресурс в теле ответного сообщения.

175
00:13:25,450 --> 00:13:29,370
Или вы можете отправить полное представление ресурса

176
00:13:29,370 --> 00:13:33,890
в теле сообщения, в зависимости от расположения клиента и

177
00:13:33,890 --> 00:13:38,760
сервера, сервер ожидает, что информация будет

178
00:13:38,760 --> 00:13:43,320
передана в теле сообщения запроса.

179
00:13:43,320 --> 00:13:48,980
DELETE операция, как вы ожидаете, удаляет существующий ресурс.

180
00:13:48,980 --> 00:13:55,150
Теперь в данном конкретном случае, конечно, операция удаления будет заключаться в том, что

181
00:13:55,150 --> 00:14:00,220
, если вы попытаетесь удалить ресурс и ресурс существует, он будет удален.

182
00:14:00,220 --> 00:14:02,440
Если вы пытаетесь удалить несуществующий ресурс,

183
00:14:02,440 --> 00:14:07,990
это не приведет к дальнейшим изменениям на стороне сервера, кроме

184
00:14:07,990 --> 00:14:11,808
, что сервер ответит с ошибкой, говорящим, что ресурс не существует.

185
00:14:11,808 --> 00:14:18,700
Но тем не менее, является примером операции в данном случае.

186
00:14:18,700 --> 00:14:22,810
Аналогично, операция get также будет работать, потому что она не делает

187
00:14:22,810 --> 00:14:27,140
никаких изменений в ресурс на сайте сервера.

188
00:14:27,140 --> 00:14:32,740
Ввод сообщений, конечно, будет изменять ресурс на стороне сервера.

189
00:14:32,740 --> 00:14:34,770
Вам нужно создать новый ресурс или

190
00:14:34,770 --> 00:14:40,050
изменить существующий ресурс на стороне сервера и, конечно же, презентации данных.

191
00:14:40,050 --> 00:14:45,050
Как я подчеркивал, две общие резервные копии для

192
00:14:45,050 --> 00:14:51,570
представляют собой либо JSON XML, последняя часть

193
00:14:51,570 --> 00:14:57,140
, которую мы должны подчеркнуть, заключается в том, что серверная сторона должна быть полностью без гражданства.

194
00:14:57,140 --> 00:15:01,190
Это означает, что серверная сторона не отслеживает состояние клиента.

195
00:15:01,190 --> 00:15:07,060
Потому что, если сервер должен отслеживать состояние клиента, он не будет масштабироваться.

196
00:15:07,060 --> 00:15:11,140
Таким образом, для масштабируемой реализации серверной стороны

197
00:15:11,140 --> 00:15:15,650
вы обычно используете сервер без состояния на стороне сервера.

198
00:15:15,650 --> 00:15:19,580
Таким образом, если запрос клиентов, отправленный на сервер, будет рассматриваться как

199
00:15:19,580 --> 00:15:25,460
независимый запрос и не будет отражать предыдущие

200
00:15:25,460 --> 00:15:30,790
запросы, которые уже были обработаны сервером от конкретного клиента.

201
00:15:30,790 --> 00:15:35,760
Таким образом, клиент несет ответственность за отслеживание своего собственного состояния.

202
00:15:35,760 --> 00:15:40,770
Либо в виде использования файлов cookie, либо с использованием базы данных клиентского сайта.

203
00:15:40,770 --> 00:15:43,780
Что бы то ни было значит, что это подходит.

204
00:15:43,780 --> 00:15:48,760
Теперь этот подход, когда клиент отслеживает свое собственное состояние, намного более масштабируемый,

205
00:15:48,760 --> 00:15:52,880
, потому что ваш клиент будет отвечать за отслеживание своего собственного.

206
00:15:54,340 --> 00:15:58,880
И вот где настройка MVC на стороне клиента помогает нам в этом отношении.

207
00:16:00,100 --> 00:16:04,920
И, наконец, мы еще не закончили с REST, мы увидим больше

208
00:16:04,920 --> 00:16:10,280
REST в упражнениях, которые следуют в этом конкретном уроке.

209
00:16:10,280 --> 00:16:11,563
А затем,

210
00:16:11,563 --> 00:16:17,206
, мы увидим более подробную информацию об использовании REST в остальной части этого курса.

211
00:16:17,206 --> 00:16:20,509
[МУЗЫКА]