1
00:00:03,810 --> 00:00:05,895
Na palestra anterior,

2
00:00:05,895 --> 00:00:07,880
aprendemos sobre REST API.

3
00:00:07,880 --> 00:00:10,781
Você viu como os pontos finais da API REST

4
00:00:10,781 --> 00:00:14,990
suportam uma maneira de um aplicativo cliente ser capaz de recuperar

5
00:00:14,990 --> 00:00:23,100
dados do servidor ou carregar dados para o servidor usando as várias operações HTTP.

6
00:00:23,100 --> 00:00:27,062
Nesta palestra e exercício que se segue a esta palestra,

7
00:00:27,062 --> 00:00:30,985
analisaremos especificamente o tipo de suporte que o Express

8
00:00:30,985 --> 00:00:36,545
suporta para projetar e implementar um servidor baseado em API REST.

9
00:00:36,545 --> 00:00:40,085
Em particular, também vamos olhar para o roteador Express,

10
00:00:40,085 --> 00:00:44,600
e como ele nos permite subdividir nosso aplicativo e

11
00:00:44,600 --> 00:00:50,285
depois organizá-lo em vários aplicativos mini Express-like,

12
00:00:50,285 --> 00:00:54,495
que se combinam para formar o aplicativo Express,

13
00:00:54,495 --> 00:01:00,605
especificamente quando estamos lidando com várias API REST e peças.

14
00:01:00,605 --> 00:01:02,985
Então, para resumir, na palestra anterior,

15
00:01:02,985 --> 00:01:06,315
examinamos o REST em detalhes.

16
00:01:06,315 --> 00:01:10,560
Também analisamos como cada endpoint é identificado por um URI

17
00:01:10,560 --> 00:01:13,950
e como podemos especificar as várias operações a serem feitas em

18
00:01:13,950 --> 00:01:18,295
cada endpoint usando o verbo HTTP apropriado, o

19
00:01:18,295 --> 00:01:20,880
GET, PUT, POST ou DELETE.

20
00:01:20,880 --> 00:01:22,560
Agora, nesta palestra,

21
00:01:22,560 --> 00:01:29,530
veremos como o Express suporta o desenvolvimento de um servidor de API REST.

22
00:01:29,530 --> 00:01:35,070
Vamos olhar para o suporte do Express para vários assuntos como app.all,

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

24
00:01:38,335 --> 00:01:43,305
e como esses métodos podem ser usados para construir um servidor de API REST.

25
00:01:43,305 --> 00:01:50,104
No Express, os vários grupos de aplicativos podem ser definidos usando o aplicativo,.

26
00:01:50,104 --> 00:01:51,955
e os vários métodos.

27
00:01:51,955 --> 00:01:59,180
Então, o app.all especifica uma operação que precisa ser feita em todos os vários verbos,

28
00:01:59,180 --> 00:02:00,990
on, in, e parte.

29
00:02:00,990 --> 00:02:04,050
Assim, por exemplo, neste exemplo,

30
00:02:04,050 --> 00:02:07,970
vemos que o endpoint é definido por /dish,

31
00:02:07,970 --> 00:02:13,230
e assim o app.all, o que for especificado na função que é dada para app.all,

32
00:02:13,230 --> 00:02:16,830
será aplicado a todas as solicitações recebidas.

33
00:02:16,830 --> 00:02:22,155
O app.get especifica o que precisa ser feito para solicitações GET e,

34
00:02:22,155 --> 00:02:24,233
correspondentemente, para as

35
00:02:24,233 --> 00:02:30,015
solicitações POST, PUT e DELETE que são enviadas para o endpoint /dish,

36
00:02:30,015 --> 00:02:32,700
como mostrado neste exemplo. O

37
00:02:32,700 --> 00:02:39,471
Express também suporta a definição de endpoints com parâmetros.

38
00:02:39,471 --> 00:02:45,750
Assim, por exemplo, você pode especificar um ID de prato específico, se desejar,

39
00:02:45,750 --> 00:02:49,500
e então deixar a operação ser executada para

40
00:02:49,500 --> 00:02:55,320
esse ponto final específico referente a esse prato específico com um dado ID de prato.

41
00:02:55,320 --> 00:02:58,890
Então, neste caso, o ID do prato em si é

42
00:02:58,890 --> 00:03:03,706
especificado como um parâmetro e o padrão usado para isso é,

43
00:03:03,706 --> 00:03:05,460
como você vê neste exemplo,

44
00:03:05,460 --> 00:03:11,920
/dishes/: e então você especificaria o parâmetro aqui.

45
00:03:11,920 --> 00:03:14,310
Para facilitar a compreensão,

46
00:03:14,310 --> 00:03:18,060
nomeei o parâmetro como DishID lá.

47
00:03:18,060 --> 00:03:22,035
Você pode usar qualquer nome de parâmetro que escolher, mas novamente,

48
00:03:22,035 --> 00:03:27,290
usar um nome significativo para um parâmetro torna mais fácil entender o código.

49
00:03:27,290 --> 00:03:28,815
Então, neste exemplo,

50
00:03:28,815 --> 00:03:34,058
o:DISHID significa que se emitirmos uma solicitação

51
00:03:34,058 --> 00:03:38,400
para um endpoint, digamos, por exemplo,

52
00:03:38,400 --> 00:03:45,300
/dishes/23, então o parâmetro DISHID nos permite extrair esse número 23 para que

53
00:03:45,300 --> 00:03:48,420
possamos operar no prato número 23 dentro

54
00:03:48,420 --> 00:03:52,496
da função especificada dentro deste método aqui.

55
00:03:52,496 --> 00:03:55,190
Então lá, o parâmetro,

56
00:03:55,190 --> 00:04:01,440
o próprio parâmetro DishID pode ser obtido usando o objeto request no qual

57
00:04:01,440 --> 00:04:04,020
a propriedade params que você suportou e

58
00:04:04,020 --> 00:04:08,885
a propriedade params suporta todos os parâmetros de solicitação de entrada,

59
00:04:08,885 --> 00:04:10,470
e DISHID, em particular,

60
00:04:10,470 --> 00:04:13,710
é um desses parâmetros de solicitação que pode ser acessado,

61
00:04:13,710 --> 00:04:16,271
como mostrado no código aqui.

62
00:04:16,271 --> 00:04:22,585
Quando você envia uma solicitação PUT ou POST do cliente para o servidor,

63
00:04:22,585 --> 00:04:28,545
você geralmente está anexando os dados no corpo da mensagem que é enviada para o servidor.

64
00:04:28,545 --> 00:04:31,110
Agora, o que significa que precisamos

65
00:04:31,110 --> 00:04:34,230
de um método para extrair informações do corpo da mensagem.

66
00:04:34,230 --> 00:04:39,320
Então é aqui que o middleware do analisador de corpo para Express é muito útil.

67
00:04:39,320 --> 00:04:44,805
Assim, o analisador de corpo nos permite analisar as informações do corpo da mensagem.

68
00:04:44,805 --> 00:04:47,515
Para usar o analisador de corpo, como seria de esperar,

69
00:04:47,515 --> 00:04:52,155
nós instalaríamos o módulo do nó corpo-parser

70
00:04:52,155 --> 00:04:56,070
e, em seguida, exigi-lo dentro do nosso aplicativo Express

71
00:04:56,070 --> 00:04:59,550
e, em seguida, especificar app.use (BodyParser).

72
00:04:59,550 --> 00:05:03,570
E se o corpo contém dados no formato JSON,

73
00:05:03,570 --> 00:05:05,810
você pode dizer bodyParser.json, o

74
00:05:05,810 --> 00:05:09,561
que significa que isso irá analisar apenas os dados que estão no

75
00:05:09,561 --> 00:05:14,250
formato JSON que está incluído no corpo da mensagem de solicitação.

76
00:05:14,250 --> 00:05:16,145
Em particular, no exercício,

77
00:05:16,145 --> 00:05:22,620
estaremos analisando dados recebidos que são enviados na forma de uma string JSON.

78
00:05:22,620 --> 00:05:24,930
O analisador de corpo, como seria de esperar,

79
00:05:24,930 --> 00:05:30,480
analisa o corpo da mensagem e preenche a propriedade req.body.

80
00:05:30,480 --> 00:05:32,190
Assim, na solicitação,

81
00:05:32,190 --> 00:05:36,250
a propriedade body conterá o que for analisado

82
00:05:36,250 --> 00:05:41,600
a partir do corpo da mensagem de solicitação pelo analisador de corpo.

83
00:05:41,600 --> 00:05:45,030
Se você estiver implementando um aplicativo Express

84
00:05:45,030 --> 00:05:48,465
que suporta vários pontos finais da API REST,

85
00:05:48,465 --> 00:05:53,265
então faz sentido subdividir o código em

86
00:05:53,265 --> 00:05:59,520
vários módulos e, em seguida, fazer uso deles para construir o aplicativo Express geral.

87
00:05:59,520 --> 00:06:03,347
Então é aqui que o roteador Express vem em nosso auxílio.

88
00:06:03,347 --> 00:06:08,070
Um roteador Express define muitos aplicativos Express,

89
00:06:08,070 --> 00:06:10,045
e dentro de muitos aplicativos Express,

90
00:06:10,045 --> 00:06:11,480
você pode, por exemplo,

91
00:06:11,480 --> 00:06:16,550
lidar com um ponto de extremidade da API REST em particular com mais detalhes,

92
00:06:16,550 --> 00:06:20,215
ou um padrão específico do ponto de extremidade da API REST com mais detalhes.

93
00:06:20,215 --> 00:06:27,656
Então, por exemplo, podemos definir um DishRouter como Express.Router

94
00:06:27,656 --> 00:06:32,450
e, em seguida, o DishRouter pode lidar com os endpoints.

95
00:06:32,450 --> 00:06:35,420
Então, quando você expressa algo como Express.Router,

96
00:06:35,420 --> 00:06:38,570
ele suporta o endpoint de rota.

97
00:06:38,570 --> 00:06:41,015
Uma das razões para usar o roteador Express,

98
00:06:41,015 --> 00:06:42,455
como você perceberia,

99
00:06:42,455 --> 00:06:45,470
é que se usarmos o aplicativo padrão GET,

100
00:06:45,470 --> 00:06:47,142
PUT, POST e DELETE métodos,

101
00:06:47,142 --> 00:06:48,760
para cada um desses métodos,

102
00:06:48,760 --> 00:06:52,315
você precisa especificar explicitamente os pontos finais da API REST.

103
00:06:52,315 --> 00:06:55,130
Uma vantagem de usar o roteador Express é que se você

104
00:06:55,130 --> 00:06:59,422
disser o roteador.Route e, em seguida, especificar o

105
00:06:59,422 --> 00:07:07,220
endpoint, esse endpoint será aplicado a todos os métodos e todos os vários

106
00:07:07,220 --> 00:07:11,060
métodos relacionados ao verbo GET, PUT, POST e DELETE podem ser encadeados

107
00:07:11,060 --> 00:07:16,575
juntos na rota na definição do código para a nossa aplicação.

108
00:07:16,575 --> 00:07:22,075
Analisaremos mais detalhes sobre isso no exercício que se segue a esta palestra.

109
00:07:22,075 --> 00:07:27,505
Com essa compreensão rápida de como o Express suporta o ponto final da API REST,

110
00:07:27,505 --> 00:07:31,070
vamos passar para o exercício onde construiremos

111
00:07:31,070 --> 00:07:35,682
seu suporte para o endpoint da API REST /meals.

112
00:07:35,682 --> 00:07:38,180
Como parte da primeira atribuição,

113
00:07:38,180 --> 00:07:40,160
você estará estendendo ainda mais

114
00:07:40,160 --> 00:07:44,559
este aplicativo Express para suportar endpoints adicionais da API REST,

115
00:07:44,559 --> 00:07:48,990
incluindo /promotions e /leaders.

116
00:07:48,990 --> 00:07:52,040
Se você fez os cursos anteriores na especialização,

117
00:07:52,040 --> 00:07:55,220
você começará imediatamente a ver por que estamos dando suporte a

118
00:07:55,220 --> 00:08:00,810
todos esses diferentes pontos de extremidade da API REST em outro lado do servidor.