1
00:00:03,810 --> 00:00:05,895
В предыдущей лекции

2
00:00:05,895 --> 00:00:07,880
мы узнали о REST API.

3
00:00:07,880 --> 00:00:10,781
Вы видели, как конечные точки REST API

4
00:00:10,781 --> 00:00:14,990
поддерживают способ получения клиентским приложением

5
00:00:14,990 --> 00:00:23,100
данных с сервера или загрузки данных на сервер с помощью различных операций HTTP.

6
00:00:23,100 --> 00:00:27,062
В этой лекции и упражнении, которое следует за этой лекцией,

7
00:00:27,062 --> 00:00:30,985
мы рассмотрим, в частности, какую поддержку

8
00:00:30,985 --> 00:00:36,545
поддерживает Express для проектирования и внедрения сервера на основе REST API.

9
00:00:36,545 --> 00:00:40,085
В частности, мы также рассмотрим экспресс-маршрутизатор,

10
00:00:40,085 --> 00:00:44,600
и как он позволяет нам разделить наше приложение, а

11
00:00:44,600 --> 00:00:50,285
затем организовать его в несколько мини-Экспресс приложений,

12
00:00:50,285 --> 00:00:54,495
которые объединяются, чтобы сформировать приложение Express, в

13
00:00:54,495 --> 00:01:00,605
частности, когда мы имеем дело с различными REST API и частей.

14
00:01:00,605 --> 00:01:02,985
Таким образом, подытоживая, в предыдущей лекции

15
00:01:02,985 --> 00:01:06,315
мы подробно рассмотрели REST.

16
00:01:06,315 --> 00:01:10,560
Мы также рассмотрели, как каждая конечная точка идентифицируется URI,

17
00:01:10,560 --> 00:01:13,950
и как мы можем указать различные операции, которые должны быть выполнены на

18
00:01:13,950 --> 00:01:18,295
каждой конечной точке, используя соответствующий

19
00:01:18,295 --> 00:01:20,880
HTTP-глагол, GET, PUT, POST или DELETE.

20
00:01:20,880 --> 00:01:22,560
Теперь в этой лекции

21
00:01:22,560 --> 00:01:29,530
мы рассмотрим, как Express поддерживает разработку сервера REST API.

22
00:01:29,530 --> 00:01:35,070
Мы рассмотрим поддержку Express для различных вопросов, таких как app.all,

23
00:01:35,070 --> 00:01:38,335
app.get, put, post и delete,

24
00:01:38,335 --> 00:01:43,305
и как эти методы могут быть использованы для создания сервера REST API.

25
00:01:43,305 --> 00:01:50,104
В Express различные группы приложений могут быть определены с помощью приложения,.

26
00:01:50,104 --> 00:01:51,955
и различные методы.

27
00:01:51,955 --> 00:01:59,180
Таким образом, app.all указывает операцию, которая должна быть выполнена на всех различных глаголах,

28
00:01:59,180 --> 00:02:00,990
on, in и part.

29
00:02:00,990 --> 00:02:04,050
Так, например, в этом примере

30
00:02:04,050 --> 00:02:07,970
мы видим, что конечная точка определяется /dishes,

31
00:02:07,970 --> 00:02:13,230
и поэтому app.all, что указано в функции, которая дана для app.all,

32
00:02:13,230 --> 00:02:16,830
будет применяться ко всем входящим запросам.

33
00:02:16,830 --> 00:02:22,155
App.get указывает, что должно быть сделано для запросов GET и,

34
00:02:22,155 --> 00:02:24,233
соответственно, для

35
00:02:24,233 --> 00:02:30,015
запросов POST, PUT и DELETE, которые отправляются в конечную точку /dishes,

36
00:02:30,015 --> 00:02:32,700
как показано в этом примере.

37
00:02:32,700 --> 00:02:39,471
Экспресс также поддерживает определение конечных точек с помощью параметров.

38
00:02:39,471 --> 00:02:45,750
Так, например, вы можете указать конкретный идентификатор блюда, если хотите,

39
00:02:45,750 --> 00:02:49,500
а затем разрешить операцию для

40
00:02:49,500 --> 00:02:55,320
конкретной конечной точки, относящейся к конкретному блюду с заданным идентификатором блюда.

41
00:02:55,320 --> 00:02:58,890
Таким образом, в этом случае в

42
00:02:58,890 --> 00:03:03,706
качестве параметра задается сам идентификатор блюда, и шаблон, используемый для этого,

43
00:03:03,706 --> 00:03:05,460
как вы видите в этом примере,

44
00:03:05,460 --> 00:03:11,920
/dishes/: и тогда вы указываете параметр здесь.

45
00:03:11,920 --> 00:03:14,310
Чтобы сделать это легко для нас понять,

46
00:03:14,310 --> 00:03:18,060
я назвал параметр DishID там.

47
00:03:18,060 --> 00:03:22,035
Вы можете использовать любое имя параметра, которое вы выбрали, но, опять же,

48
00:03:22,035 --> 00:03:27,290
использование значимого имени параметра упрощает понимание кода.

49
00:03:27,290 --> 00:03:28,815
Таким образом, в этом примере

50
00:03:28,815 --> 00:03:34,058
: Dishid означает, что если мы выдаем запрос на конечную точку,

51
00:03:34,058 --> 00:03:38,400
скажем, /dishes/23,

52
00:03:38,400 --> 00:03:45,300
то параметр DishID позволяет нам извлечь это число 23 так, что мы

53
00:03:45,300 --> 00:03:48,420
можем работать на блюдо номер 23 в

54
00:03:48,420 --> 00:03:52,496
функции, которая указана внутри этого метода здесь.

55
00:03:52,496 --> 00:03:55,190
Таким образом, параметр,

56
00:03:55,190 --> 00:04:01,440
сам параметр DishID может быть получен с помощью объекта запроса, на котором

57
00:04:01,440 --> 00:04:04,020
поддерживается свойство params, а свойство

58
00:04:04,020 --> 00:04:08,885
params поддерживает все параметры входящего запроса,

59
00:04:08,885 --> 00:04:10,470
и DishID, в частности,

60
00:04:10,470 --> 00:04:13,710
является одним из тех параметров запроса, которые можно получить доступ,

61
00:04:13,710 --> 00:04:16,271
как показано в коде здесь.

62
00:04:16,271 --> 00:04:22,585
Когда вы отправляете запрос PUT или POST от клиента на сервер,

63
00:04:22,585 --> 00:04:28,545
вы часто вводите данные в тело сообщения, которое отправляется на сервер.

64
00:04:28,545 --> 00:04:31,110
Теперь, что означает, что нам нужен метод

65
00:04:31,110 --> 00:04:34,230
извлечения информации из тела сообщения.

66
00:04:34,230 --> 00:04:39,320
Так вот где промежуточное программное обеспечение синтаксического анализа тела для Express очень полезно.

67
00:04:39,320 --> 00:04:44,805
Таким образом, анализатор тела позволяет анализировать информацию из тела сообщения.

68
00:04:44,805 --> 00:04:47,515
Чтобы использовать анализатор тела, как мы и ожидали,

69
00:04:47,515 --> 00:04:52,155
мы установим модуль узла body-parser,

70
00:04:52,155 --> 00:04:56,070
а затем запросим его в нашем приложении Express,

71
00:04:56,070 --> 00:04:59,550
а затем укажите app.use (BodyParser).

72
00:04:59,550 --> 00:05:03,570
И если тело содержит данные в формате JSON,

73
00:05:03,570 --> 00:05:05,810
вы можете сказать BodyParser.json,

74
00:05:05,810 --> 00:05:09,561
так что это означает, что это будет анализировать только данные, которые находятся в

75
00:05:09,561 --> 00:05:14,250
формате JSON, которые заключены в тело этого сообщения запроса.

76
00:05:14,250 --> 00:05:16,145
В частности, в упражнении

77
00:05:16,145 --> 00:05:22,620
мы будем анализировать входящие данные, которые отправляются в виде строки JSON.

78
00:05:22,620 --> 00:05:24,930
Парсер тела, как и следовало ожидать,

79
00:05:24,930 --> 00:05:30,480
анализирует тело сообщения и заполняет свойство req.body.

80
00:05:30,480 --> 00:05:32,190
Таким образом, по запросу

81
00:05:32,190 --> 00:05:36,250
свойство body будет содержать все, что анализируется

82
00:05:36,250 --> 00:05:41,600
из тела сообщения запроса парсером тела.

83
00:05:41,600 --> 00:05:45,030
Если вы реализуете приложение Express,

84
00:05:45,030 --> 00:05:48,465
которое поддерживает несколько конечных точек REST API,

85
00:05:48,465 --> 00:05:53,265
то имеет смысл разделить код на

86
00:05:53,265 --> 00:05:59,520
несколько модулей, а затем использовать их для создания общего приложения Express.

87
00:05:59,520 --> 00:06:03,347
Так вот, где экспресс-роутер приходит нам на помощь.

88
00:06:03,347 --> 00:06:08,070
Маршрутизатор Express определяет множество приложений Express,

89
00:06:08,070 --> 00:06:10,045
и в рамках этого множества приложений Express

90
00:06:10,045 --> 00:06:11,480
вы можете, например,

91
00:06:11,480 --> 00:06:16,550
более подробно обращаться с одной конкретной конечной точкой REST API

92
00:06:16,550 --> 00:06:20,215
или с одним конкретным шаблоном конечной точки REST API более подробно.

93
00:06:20,215 --> 00:06:27,656
Так, например, мы можем определить DishRouter как Express.Router,

94
00:06:27,656 --> 00:06:32,450
а затем DishRouter может обрабатывать конечные точки.

95
00:06:32,450 --> 00:06:35,420
Поэтому, когда вы выражаете что-то как Express.Router,

96
00:06:35,420 --> 00:06:38,570
он поддерживает конечную точку маршрута.

97
00:06:38,570 --> 00:06:41,015
Одна из причин использования экспресс-маршрутизатора,

98
00:06:41,015 --> 00:06:42,455
как вы понимаете,

99
00:06:42,455 --> 00:06:45,470
заключается в том, что если мы используем стандартные

100
00:06:45,470 --> 00:06:47,142
методы GET, PUT, POST и DELETE приложения,

101
00:06:47,142 --> 00:06:48,760
для каждого из этих методов,

102
00:06:48,760 --> 00:06:52,315
вам нужно явно указать конечные точки REST API.

103
00:06:52,315 --> 00:06:55,130
Одно из преимуществ использования экспресс-маршрутизатора заключается в том, что если вы

104
00:06:55,130 --> 00:06:59,422
говорите router.route, а затем укажете

105
00:06:59,422 --> 00:07:07,220
конечную точку, эта конечная точка будет применяться ко всем методам, а все различные

106
00:07:07,220 --> 00:07:11,060
методы GET, PUT, POST и DELETE, связанные с глаголами, могут быть

107
00:07:11,060 --> 00:07:16,575
объединены в маршрут при определении кода для нашего приложения.

108
00:07:16,575 --> 00:07:22,075
Мы рассмотрим более подробную информацию об этом в упражнении, которое следует за этой лекцией.

109
00:07:22,075 --> 00:07:27,505
С этим быстрым пониманием того, как Express поддерживает конечную точку REST API,

110
00:07:27,505 --> 00:07:31,070
давайте перейдем к упражнению, где мы построим

111
00:07:31,070 --> 00:07:35,682
их поддержку для конечной точки /dishes REST API. В

112
00:07:35,682 --> 00:07:38,180
рамках первого задания

113
00:07:38,180 --> 00:07:40,160
вы будете продолжать расширять

114
00:07:40,160 --> 00:07:44,559
это приложение Express для поддержки дополнительных конечных точек REST API,

115
00:07:44,559 --> 00:07:48,990
включая /promotions и/leaders.

116
00:07:48,990 --> 00:07:52,040
Если вы прошли предыдущие курсы по специализации,

117
00:07:52,040 --> 00:07:55,220
вы сразу же начнете понимать, почему мы поддерживаем

118
00:07:55,220 --> 00:08:00,810
все эти разные конечные точки REST API на другой стороне сервера.