1
00:00:03,200 --> 00:00:09,035
Deixe-me dar-lhe um breve descanso. Apanhei-te lá.

2
00:00:09,035 --> 00:00:11,535
O que eu queria dizer foi deixe-me dar-lhe

3
00:00:11,535 --> 00:00:16,420
uma breve visão geral da Transferência Estadual Representacional.

4
00:00:16,420 --> 00:00:18,460
O que exatamente é REST?

5
00:00:18,460 --> 00:00:22,670
Como fazemos uso dele em nosso aplicativo React,

6
00:00:22,670 --> 00:00:26,130
e como fazemos uso disso para nos comunicarmos com o servidor?

7
00:00:26,130 --> 00:00:29,455
Como um servidor oferece suporte à API REST

8
00:00:29,455 --> 00:00:34,615
e como acessamos a API REST do nosso aplicativo React?

9
00:00:34,615 --> 00:00:39,230
Vamos falar sobre isso um pouco mais nesta lição.

10
00:00:39,230 --> 00:00:47,680
Tenho certeza que você já ouviu o termo serviços da Web sendo mencionado no mundo da TI com muita frequência.

11
00:00:47,680 --> 00:00:49,895
O que são exatamente serviços da Web?

12
00:00:49,895 --> 00:00:55,520
Serviços Web são uma forma de projetar sistemas para suportar a interoperabilidade

13
00:00:55,520 --> 00:01:01,745
entre os sistemas que estão conectados através de uma rede como a Internet, como vemos hoje.

14
00:01:01,745 --> 00:01:05,504
Isso é o que chamamos de arquitetura orientada a serviços.

15
00:01:05,504 --> 00:01:09,170
Agora, o que isso significa é que você fornece

16
00:01:09,170 --> 00:01:14,870
uma maneira padronizada para que duas máquinas conectadas à internet possam

17
00:01:14,870 --> 00:01:17,720
se comunicar entre si no

18
00:01:17,720 --> 00:01:24,660
nível da camada de aplicativo para aplicativos baseados na Web usando padrões abertos.

19
00:01:24,660 --> 00:01:29,175
Agora, eu usei muito jargão lá.

20
00:01:29,175 --> 00:01:32,000
Vamos tentar dividi-los e entender

21
00:01:32,000 --> 00:01:36,195
um pouco sobre cada um deles nesta palestra.

22
00:01:36,195 --> 00:01:43,390
Duas abordagens comuns que são usadas para suportar serviços Web são SOAP.

23
00:01:43,390 --> 00:01:49,550
Os serviços Web baseados no Simple Object Access Protocol que usa

24
00:01:49,550 --> 00:01:52,805
a linguagem de descrição de serviços Web para

25
00:01:52,805 --> 00:01:57,080
especificar como os dois pontos finais se comunicam entre si.

26
00:01:57,080 --> 00:02:01,700
Normalmente SOAP é baseado no uso de XML como

27
00:02:01,700 --> 00:02:07,340
o formato para as mensagens que estão sendo trocadas entre os dois pontos finais. A

28
00:02:07,340 --> 00:02:12,975
Transferência de Estado Representacional ou REST também usa padrões web,

29
00:02:12,975 --> 00:02:17,240
mas a troca de dados entre os dois pontos finais pode ser XML ou

30
00:02:17,240 --> 00:02:22,385
cada vez mais usando JSON como o formato.

31
00:02:22,385 --> 00:02:29,705
A forma REST de interoperabilidade é mais simples em comparação com SOAP e, portanto, a

32
00:02:29,705 --> 00:02:37,650
REST encontrou uma implantação muito mais ampla no mundo dos serviços web.

33
00:02:37,650 --> 00:02:41,215
Normalmente, a comunicação cliente-servidor é

34
00:02:41,215 --> 00:02:45,830
facilitada usando REST, onde o servidor oferece suporte

35
00:02:45,830 --> 00:02:49,960
a uma API REST e o cliente pode invocar os pontos finais da API REST

36
00:02:49,960 --> 00:02:54,595
para obter informações ou carregar informações para o servidor.

37
00:02:54,595 --> 00:02:59,885
Novamente, mencionei a palavra invocar os pontos finais da API REST,

38
00:02:59,885 --> 00:03:03,210
então estes são alguns termos que usei.

39
00:03:03,210 --> 00:03:07,385
Vamos esclarecer alguns destes nos próximos slides.

40
00:03:07,385 --> 00:03:12,590
Representational State Transfer é um estilo de arquitetura de software

41
00:03:12,590 --> 00:03:18,200
que é especialmente projetado para hipermídia distribuída através da World Wide Web.

42
00:03:18,200 --> 00:03:24,604
Agora isso foi introduzido pela primeira vez por Roy Fielding em sua tese de doutorado.

43
00:03:24,604 --> 00:03:26,990
Agora esta é uma daquelas teses de doutorado

44
00:03:26,990 --> 00:03:29,660
que realmente produziu algo útil para o mundo.

45
00:03:29,660 --> 00:03:38,690
Então isso encontrou novamente muita tração no mundo dos serviços web.

46
00:03:38,690 --> 00:03:42,800
Esta é uma coleção de princípios de rede que descrevem como

47
00:03:42,800 --> 00:03:47,300
os recursos podem ser disponibilizados em servidores

48
00:03:47,300 --> 00:03:50,950
e esses recursos podem ser acessados a partir de clientes,

49
00:03:50,950 --> 00:03:56,285
identificando os recursos usando endpoints de API de descanso.

50
00:03:56,285 --> 00:03:58,855
Dentro da Transferência Estadual Representacional,

51
00:03:58,855 --> 00:04:01,050
existem quatro princípios básicos de concepção.

52
00:04:01,050 --> 00:04:05,375
Primeiro e acima de tudo, REST é construído sobre o protocolo HTTP,

53
00:04:05,375 --> 00:04:11,365
por isso ele usa todos os métodos HTTP que já vimos na lição anterior.

54
00:04:11,365 --> 00:04:15,045
Em segundo lugar, REST foi projetado para ser apátrida,

55
00:04:15,045 --> 00:04:17,930
o que significa que o servidor não armazena nenhuma informação sobre

56
00:04:17,930 --> 00:04:21,450
o estado após a comunicação ser concluída.

57
00:04:21,450 --> 00:04:25,615
Então, quando um servidor recebe a solicitação, o servidor responde,

58
00:04:25,615 --> 00:04:29,110
e depois disso ele não se lembra de

59
00:04:29,110 --> 00:04:33,340
nada mais sobre a conversa entre o cliente e o servidor.

60
00:04:33,340 --> 00:04:38,635
Terceiro, a maneira REST de fornecer recursos é

61
00:04:38,635 --> 00:04:44,945
expor uma estrutura de diretórios como URLs (Uniform Resource Locators - URLs).

62
00:04:44,945 --> 00:04:50,230
Em quarto lugar, o formato para troca de dados é tipicamente JSON

63
00:04:50,230 --> 00:04:56,145
ou XML ou ambos podem ser suportados usando REST.

64
00:04:56,145 --> 00:05:03,350
Uma das motivações para Roy sugerir REST como uma forma de apoiar serviços web é

65
00:05:03,350 --> 00:05:06,620
que ele captura todas as coisas que são boas sobre

66
00:05:06,620 --> 00:05:10,880
a World Wide Web e que fez a World Wide Web bem sucedida.

67
00:05:10,880 --> 00:05:14,040
O uso de Indicadores Uniformes de Recursos ou

68
00:05:14,040 --> 00:05:18,320
URLs (Uniform Resource Locators, Localizadores Uniformes de

69
00:05:18,320 --> 00:05:23,170
Recursos) que permitem que você aborde recursos especificando-os como um URL.

70
00:05:23,170 --> 00:05:29,390
O segundo, sendo um protocolo que vive em cima do protocolo HTTP.

71
00:05:29,390 --> 00:05:34,600
HTTP já encontrou ampla implantação na internet.

72
00:05:34,600 --> 00:05:40,135
Em terceiro lugar, o ciclo de resposta de solicitação que HTTP é conhecido para.

73
00:05:40,135 --> 00:05:42,420
Então você envia uma solicitação,

74
00:05:42,420 --> 00:05:45,775
o servidor recebe sua solicitação, processa a solicitação,

75
00:05:45,775 --> 00:05:49,530
envia a resposta à solicitação,

76
00:05:49,530 --> 00:05:51,830
e o cliente recebe a resposta,

77
00:05:51,830 --> 00:05:54,765
age sobre isso, e pode gerar mais solicitações.

78
00:05:54,765 --> 00:05:58,580
Então, essa abordagem do ciclo de resposta de solicitação é muito

79
00:05:58,580 --> 00:06:03,115
bem estabelecida com HTTP e a World Wide Web.

80
00:06:03,115 --> 00:06:08,505
Agora, o protocolo HTTP como vimos anteriormente,

81
00:06:08,505 --> 00:06:13,650
vamos usar todos os vários verbos que HTTP fornece.

82
00:06:13,650 --> 00:06:15,520
especificamente, o GET, PUT,

83
00:06:15,520 --> 00:06:18,635
POST e DELETE

84
00:06:18,635 --> 00:06:23,480
para ser capaz de especificar operações a serem feitas em recursos que são armazenados no lado do servidor.

85
00:06:23,480 --> 00:06:27,470
Então, por exemplo, se você fizer uma solicitação HTTP GET,

86
00:06:27,470 --> 00:06:30,125
você está pedindo para o servidor para retornar o recurso.

87
00:06:30,125 --> 00:06:32,415
Se você fizer uma solicitação POST,

88
00:06:32,415 --> 00:06:35,415
estará solicitando que o servidor crie um novo recurso.

89
00:06:35,415 --> 00:06:36,670
Se você fizer uma solicitação PUT,

90
00:06:36,670 --> 00:06:39,650
você está solicitando que o servidor atualize um recurso existente.

91
00:06:39,650 --> 00:06:42,170
E se você emitir uma solicitação DELETE,

92
00:06:42,170 --> 00:06:45,020
você está solicitando

93
00:06:45,020 --> 00:06:48,070
que o servidor exclua o recurso identificado pelo URL específico.

94
00:06:48,070 --> 00:06:51,735
Além disso, tenta preservar a Idempotência.

95
00:06:51,735 --> 00:06:56,165
Algumas operações, quando são realizadas mesmo repetidamente,

96
00:06:56,165 --> 00:06:58,225
não causarão nenhuma mudança de estado.

97
00:06:58,225 --> 00:07:02,085
Algumas outras operações, se você as fizer sucessivamente,

98
00:07:02,085 --> 00:07:05,170
elas podem causar uma mudança de estado.

99
00:07:05,170 --> 00:07:08,780
Então você precisa ter cuidado com quais operações podem ser repetidas sem

100
00:07:08,780 --> 00:07:14,395
quaisquer conseqüências prejudiciais e que devem ser feitas com muito cuidado.

101
00:07:14,395 --> 00:07:21,864
No mundo REST, muitas vezes você ouve pessoas falando sobre substantivos, verbos e representações.

102
00:07:21,864 --> 00:07:27,875
Agora, vamos esclarecer cada um deles com um pouco mais de detalhes nos próximos slides.

103
00:07:27,875 --> 00:07:31,760
Os substantivos se referem especificamente a recursos e esses recursos são

104
00:07:31,760 --> 00:07:36,320
geralmente identificados por suas URLs e estes são irrestritos. Os

105
00:07:36,320 --> 00:07:40,700
verbos são constrangimentos e estes especificam as ações a serem

106
00:07:40,700 --> 00:07:45,010
feitas sobre os recursos e representações como vemos.

107
00:07:45,010 --> 00:07:47,285
Quando as informações precisam ser transmitidas

108
00:07:47,285 --> 00:07:49,910
do servidor para o cliente ou do cliente para o servidor,

109
00:07:49,910 --> 00:07:51,855
como você codifica as informações.

110
00:07:51,855 --> 00:07:56,520
Normalmente, usando JSON ou usando XML.

111
00:07:56,520 --> 00:08:01,895
Recurso é a abstração chave que REST trabalha.

112
00:08:01,895 --> 00:08:06,810
Assim, as informações são abstraídas na forma de um recurso e o recurso

113
00:08:06,810 --> 00:08:12,475
é identificado especificando-o usando uma URL.

114
00:08:12,475 --> 00:08:18,395
Assim, qualquer informação que possa ser encapsulada e disponibilizada,

115
00:08:18,395 --> 00:08:20,720
pode ser identificada como um recurso.

116
00:08:20,720 --> 00:08:26,980
Um pedaço de informação como o tempo atual em Hong Kong poderia ser um recurso,

117
00:08:26,980 --> 00:08:29,345
uma imagem poderia ser um recurso,

118
00:08:29,345 --> 00:08:33,985
uma informação de preço de ações poderia ser um recurso e assim por diante.

119
00:08:33,985 --> 00:08:38,920
Então, o que quer que você defina como um pedaço de informação que um cliente pode estar interessado,

120
00:08:38,920 --> 00:08:41,430
pode ser identificado como um recurso.

121
00:08:41,430 --> 00:08:44,045
Você pode até mesmo lidar com recursos como coleção de

122
00:08:44,045 --> 00:08:48,740
recursos que o servidor pode enviar para o cliente.

123
00:08:48,740 --> 00:08:54,145
Um exemplo de como você nomeia recursos é ilustrado aqui.

124
00:08:54,145 --> 00:08:57,740
Então usamos URIs para identificar a fonte.

125
00:08:57,740 --> 00:09:03,355
Uma leitura rápida dessas especificações ou dos URIs aqui

126
00:09:03,355 --> 00:09:10,460
permitirá que você entenda facilmente o que estamos nos referindo usando esses URIs.

127
00:09:10,460 --> 00:09:14,420
Assim, por exemplo, algo que termina com pratos/,

128
00:09:14,420 --> 00:09:19,315
você assume automaticamente que isso está se referindo a uma coleção de pratos.

129
00:09:19,315 --> 00:09:22,795
Mas pratos/123, por exemplo,

130
00:09:22,795 --> 00:09:28,250
pode significar prato número 123 neste caso e assim por diante.

131
00:09:28,250 --> 00:09:31,320
Então, é muito fácil de salvar e você pode especificar

132
00:09:31,320 --> 00:09:34,650
uma coleção de recursos e ser capaz de

133
00:09:34,650 --> 00:09:38,815
identificá-los como uma coleção e, em seguida, baixá-los como uma coleção ou você pode

134
00:09:38,815 --> 00:09:43,965
identificar um recurso individual e dizer que você quer esse recurso em particular.

135
00:09:43,965 --> 00:09:50,395
Agora, esses recursos podem ser organizados em uma hierarquia da especificação deste URI.

136
00:09:50,395 --> 00:09:52,740
Então, à medida que você percorre o caminho,

137
00:09:52,740 --> 00:09:58,325
você vai do mais geral para o mais específico do recurso.

138
00:09:58,325 --> 00:10:02,110
Essa estrutura de diretórios permite que você identifique os recursos

139
00:10:02,110 --> 00:10:07,780
que você usa ou fornece do lado do servidor com muita facilidade.

140
00:10:07,780 --> 00:10:11,585
A segunda parte da API REST são os verbos.

141
00:10:11,585 --> 00:10:16,760
Em particular, estamos interessados nos quatro verbos de HTTP GET,

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

143
00:10:19,140 --> 00:10:24,410
Nesse caso, esses verbos serão mapeados em ações que

144
00:10:24,410 --> 00:10:29,755
queremos que sejam executadas no recurso, no lado do servidor.

145
00:10:29,755 --> 00:10:34,170
Um GET significaria que você deseja executar uma operação de leitura no recurso.

146
00:10:34,170 --> 00:10:39,980
Então, o que significa que um cliente enviando uma solicitação GET está indicando ao servidor que ele

147
00:10:39,980 --> 00:10:43,480
deseja obter uma representação

148
00:10:43,480 --> 00:10:46,380
desse recurso do lado do servidor para o lado do cliente.

149
00:10:46,380 --> 00:10:48,960
Um POST significa que você deseja criar

150
00:10:48,960 --> 00:10:52,755
um novo recurso e, em seguida, você especificará os detalhes do recurso

151
00:10:52,755 --> 00:10:55,795
na representação que é usada para

152
00:10:55,795 --> 00:10:59,799
especificar o recurso e, em seguida, enviar essas informações para o lado do servidor, de

153
00:10:59,799 --> 00:11:03,285
modo que o servidor criará esse recurso em seu nome.

154
00:11:03,285 --> 00:11:06,370
Um PUT seria modificação de recursos e

155
00:11:06,370 --> 00:11:09,955
um DELETE como você esperaria é a exclusão dos recursos.

156
00:11:09,955 --> 00:11:12,995
Assim, como você pode ver, os quatro verbos;

157
00:11:12,995 --> 00:11:15,110
GET, POST, PUT e DELETE,

158
00:11:15,110 --> 00:11:19,180
são mapeados para as quatro operações CRUD que você pode

159
00:11:19,180 --> 00:11:24,035
realizar em um banco de dados que armazena esses recursos no lado do servidor, as

160
00:11:24,035 --> 00:11:27,815
operações READ, CREATE, UPDATE e DELETE.

161
00:11:27,815 --> 00:11:33,760
Elaborando ainda mais, o HTTP GET é uma maneira de especificar que você

162
00:11:33,760 --> 00:11:36,950
deseja que as informações ou a representação

163
00:11:36,950 --> 00:11:40,235
do recurso para ser retornada para o cliente do lado do servidor.

164
00:11:40,235 --> 00:11:43,890
Então, quando você emite uma solicitação GET para um ponto final da API REST,

165
00:11:43,890 --> 00:11:49,130
você está pedindo uma coleção de recursos representados por

166
00:11:49,130 --> 00:11:57,530
URI ou um recurso específico que é identificado pelo ID desse recurso específico,

167
00:11:57,530 --> 00:11:59,490
especificado dentro da URL.

168
00:11:59,490 --> 00:12:01,000
Então, como você vê neste exemplo,

169
00:12:01,000 --> 00:12:03,800
se você diz, pratos/452,

170
00:12:03,800 --> 00:12:08,320
você está querendo dizer que o prato número 452 com

171
00:12:08,320 --> 00:12:13,075
a ID 452 deve ser retornado para o lado do cliente.

172
00:12:13,075 --> 00:12:18,175
Da mesma forma, a operação POST como vimos é usada para criar o recurso.

173
00:12:18,175 --> 00:12:20,065
Então, quando você cria o recurso,

174
00:12:20,065 --> 00:12:26,920
o conteúdo de descrever o recurso seria na forma de uma representação JSON ou

175
00:12:26,920 --> 00:12:29,790
uma representação XML e que será incluído no

176
00:12:29,790 --> 00:12:34,075
corpo da mensagem de solicitação que é enviada para o lado do servidor.

177
00:12:34,075 --> 00:12:38,095
Assim, uma operação POST espera uma representação

178
00:12:38,095 --> 00:12:42,870
do recurso no formato JSON ou XML no corpo da mensagem de solicitação.

179
00:12:42,870 --> 00:12:44,890
Quando o servidor recebe essa mensagem de solicitação,

180
00:12:44,890 --> 00:12:49,960
o servidor cria esse recurso no lado do servidor e retorna

181
00:12:49,960 --> 00:12:58,030
uma conformação ou um erro para indicar que a criação do recurso falhou.

182
00:12:58,030 --> 00:13:02,725
Da mesma forma, uma operação PUT é usada para atualizar um recurso.

183
00:13:02,725 --> 00:13:06,315
Quando você faz uma operação PUT em um recurso no lado do servidor,

184
00:13:06,315 --> 00:13:10,200
você pode enviar de volta a modificação,

185
00:13:10,200 --> 00:13:15,470
especificando apenas a modificação parcial que você deseja afetar sobre

186
00:13:15,470 --> 00:13:20,200
o recurso específico no corpo da mensagem de resposta ou você pode enviar

187
00:13:20,200 --> 00:13:25,345
a representação completa do no corpo da mensagem.

188
00:13:25,345 --> 00:13:28,705
Dependendo da organização entre o cliente e o servidor,

189
00:13:28,705 --> 00:13:37,195
o servidor espera que as informações sejam transmitidas no corpo da mensagem de solicitação.

190
00:13:37,195 --> 00:13:42,600
Uma operação DELETE como seria de esperar exclui o recurso existente.

191
00:13:42,600 --> 00:13:45,460
Agora, neste caso particular,

192
00:13:45,460 --> 00:13:49,670
é claro que uma operação DELETE seria idempotente porque se você

193
00:13:49,670 --> 00:13:54,145
tentar excluir um recurso e o recurso existir, ele será excluído.

194
00:13:54,145 --> 00:13:56,445
Se você estiver tentando excluir um recurso não existente,

195
00:13:56,445 --> 00:14:01,220
ele não causará nenhuma modificação adicional no lado do servidor,

196
00:14:01,220 --> 00:14:06,165
exceto que o servidor responderá com um erro dizendo que o recurso não existe.

197
00:14:06,165 --> 00:14:12,530
Mas, no entanto, DELETE é um exemplo de uma operação idempotente neste caso.

198
00:14:12,530 --> 00:14:16,510
Da mesma forma, a operação GET também é uma operação idempotente porque

199
00:14:16,510 --> 00:14:20,885
não está fazendo quaisquer modificações para o recurso no lado do servidor.

200
00:14:20,885 --> 00:14:26,925
POST e PUT, é claro, vão modificar o recurso no lado do servidor,

201
00:14:26,925 --> 00:14:31,940
ou criar um novo recurso ou modificar um recurso existente no lado do servidor.

202
00:14:31,940 --> 00:14:34,060
Claro, as representações,

203
00:14:34,060 --> 00:14:36,730
como eu tenho enfatizado,

204
00:14:36,730 --> 00:14:43,980
os dois formatos comuns para representar é JSON ou XML.

205
00:14:43,980 --> 00:14:47,105
A última parte que precisamos enfatizar é

206
00:14:47,105 --> 00:14:51,060
que o lado do servidor deve ser completamente sem estado, o

207
00:14:51,060 --> 00:14:53,640
que significa que o lado do servidor não rastreia

208
00:14:53,640 --> 00:14:59,145
o estado do cliente porque se o servidor precisa rastrear o estado dos clientes,

209
00:14:59,145 --> 00:15:00,935
ele não será escalável.

210
00:15:00,935 --> 00:15:05,160
Então, para uma implementação escalável do lado do servidor,

211
00:15:05,160 --> 00:15:09,620
você normalmente usa um servidor sem estado no lado do servidor.

212
00:15:09,620 --> 00:15:12,910
Assim, cada solicitação que o cliente envia para o servidor será

213
00:15:12,910 --> 00:15:16,490
tratada como uma solicitação independente e

214
00:15:16,490 --> 00:15:20,330
não refletirá sobre solicitações anteriores

215
00:15:20,330 --> 00:15:24,685
que já foram tratadas pelo servidor desse cliente específico.

216
00:15:24,685 --> 00:15:29,605
Portanto, é responsabilidade do cliente rastrear seu próprio estado,

217
00:15:29,605 --> 00:15:34,635
seja na forma de usar cookies ou usando um banco de dados do lado do cliente,

218
00:15:34,635 --> 00:15:37,435
seja qual for o meio adequado.

219
00:15:37,435 --> 00:15:41,790
Agora, essa abordagem em que o cliente rastreia seu próprio estado é

220
00:15:41,790 --> 00:15:44,815
muito mais escalável porque cada cliente individual

221
00:15:44,815 --> 00:15:48,240
será responsável por rastrear seu próprio estado.

222
00:15:48,240 --> 00:15:53,840
Este é o lugar onde a configuração MVC do lado do cliente nos ajuda a este respeito.

223
00:15:53,840 --> 00:15:57,440
Finalmente, ainda não terminamos com REST.

224
00:15:57,440 --> 00:16:04,145
Veremos mais de REST nos exercícios que se seguem nesta lição particular

225
00:16:04,145 --> 00:16:12,310
e, em seguida, também veremos mais detalhes sobre o uso de REST no resto deste curso.