1
00:00:00,000 --> 00:00:03,979
[MÚSICA]

2
00:00:03,979 --> 00:00:06,750
Deixe-me dar-lhe um breve descanso.

3
00:00:08,010 --> 00:00:09,480
Te peguei lá!

4
00:00:09,480 --> 00:00:10,800
O que eu queria dizer foi,

5
00:00:10,800 --> 00:00:16,860
deixe-me dar-lhe uma breve visão geral da transferência de estado representacional.

6
00:00:16,860 --> 00:00:18,670
O que exatamente é descanso?

7
00:00:18,670 --> 00:00:22,900
Como fazemos uso dele em nossa aplicação angular e

8
00:00:22,900 --> 00:00:26,450
como fazemos uso disso para nos comunicarmos com o servidor?

9
00:00:26,450 --> 00:00:30,050
Como um servidor oferece suporte à API REST e

10
00:00:30,050 --> 00:00:35,060
como acessamos a API REST a partir de nosso aplicativo Angular?

11
00:00:35,060 --> 00:00:39,170
Vamos falar sobre isso um pouco mais nesta lição.

12
00:00:39,170 --> 00:00:43,880
Nesta palestra em particular, lhe darei uma breve visão geral do REST.

13
00:00:46,010 --> 00:00:50,620
Tenho certeza que você já ouviu o termo Serviços Web sendo mencionado

14
00:00:50,620 --> 00:00:53,990
no mundo da TI com muita frequência.

15
00:00:53,990 --> 00:00:56,160
O que exatamente são serviços web?Os serviços Web

16
00:00:56,160 --> 00:01:01,980
são uma forma de projetar sistemas para suportar a interoperabilidade entre os sistemas

17
00:01:01,980 --> 00:01:07,920
conectados através de uma rede, como a Internet, como vemos hoje.

18
00:01:07,920 --> 00:01:11,830
Isso é o que nos referimos como uma arquitetura orientada a serviços.

19
00:01:11,830 --> 00:01:18,100
Agora, o que isso significa é que você fornece uma maneira padronizada para duas máquinas

20
00:01:18,100 --> 00:01:22,190
que estão conectadas à Internet para serem capazes de se comunicar uns com os outros.

21
00:01:23,670 --> 00:01:26,970
Seu nível de layout de aplicativo para aplicativos de banco de dados

22
00:01:26,970 --> 00:01:30,920
usando padrões abertos.

23
00:01:30,920 --> 00:01:34,660
Agora, eu usei um monte de jargão lá.

24
00:01:35,710 --> 00:01:37,420
Vamos tentar dividi-los e

25
00:01:37,420 --> 00:01:41,640
entender um pouco sobre cada um disso nesta palestra.

26
00:01:42,640 --> 00:01:49,570
Duas abordagens comuns que são usadas para suportar serviços Web são SOAP,

27
00:01:49,570 --> 00:01:54,720
os serviços web baseados em protocolo de acesso a objetos simples,

28
00:01:54,720 --> 00:01:58,820
que usa a linguagem de descrição de serviços Web para

29
00:01:58,820 --> 00:02:03,150
especificando como os dois pontos finais se comunicam entre si.

30
00:02:03,150 --> 00:02:07,667
E normalmente, soap é baseado em usar XML como

31
00:02:07,667 --> 00:02:12,240
o formato para as mensagens que estão sendo trocadas entre os dois pontos finais.

32
00:02:13,990 --> 00:02:19,910
A transferência de estado de apresentação ou repouso também usa padrões da web, mas a troca

33
00:02:19,910 --> 00:02:24,020
de dados entre os dois pontos de extremidade pode ser XML ou cada vez mais.

34
00:02:25,150 --> 00:02:28,960
Usando JSON como formato.

35
00:02:28,960 --> 00:02:34,960
A maneira REST de interoperabilidade é mais simples em comparação com SOAP e

36
00:02:34,960 --> 00:02:42,940
, portanto, REST encontrou uma implantação muito mais ampla nos serviços web restantes.

37
00:02:43,950 --> 00:02:49,230
Normalmente, a comunicação do servidor cliente é facilitada usando REST

38
00:02:49,230 --> 00:02:54,830
, onde o servidor oferece suporte à API REST e o cliente pode então invocar seus pontos de extremidade da API REST

39
00:02:54,830 --> 00:03:01,000
para obter informações ou carregar informações para o servidor.

40
00:03:01,000 --> 00:03:05,910
Novamente, Eu mencionei a palavra, invocar esse ponto final da API REST.

41
00:03:05,910 --> 00:03:09,290
Então, estes são alguns termos que eu usei.

42
00:03:09,290 --> 00:03:12,460
Vamos esclarecer alguns desses slides nos próximos slides.

43
00:03:13,790 --> 00:03:18,710
Transferência de estado representacional é um estilo de arquitetura de software que

44
00:03:18,710 --> 00:03:23,360
é especialmente projetado para hipermídia distribuída na World Wide Web.

45
00:03:24,770 --> 00:03:30,810
Agora isso foi introduzido pela primeira vez por Roy Fielding em sua tese de doutoramento.

46
00:03:30,810 --> 00:03:33,750
Agora, esta é uma daquelas tese de doutorado que realmente produziu

47
00:03:33,750 --> 00:03:35,970
algo útil para o mundo.

48
00:03:35,970 --> 00:03:44,250
Então, isso encontrou novamente um monte de tração no mundo dos serviços web.

49
00:03:44,250 --> 00:03:50,410
Esta é uma coleção de princípios de rede que descrevem como os recursos podem ser

50
00:03:51,630 --> 00:03:57,060
disponibilizados em servidores, e esses recursos podem ser acessados a partir de clientes

51
00:03:57,060 --> 00:04:02,520
identificando os recursos usando pontos de extremidade da API REST.

52
00:04:02,520 --> 00:04:07,150
Dentro da Transferência de Estado Representacional existem quatro princípios básicos de design.

53
00:04:07,150 --> 00:04:11,310
Em primeiro lugar, REST é construído sobre o protocolo HTTP.

54
00:04:11,310 --> 00:04:17,800
Então ele usa todos os métodos HTTP que já vimos na lição anterior.

55
00:04:17,800 --> 00:04:22,750
Segundo, REST foi projetado para ser apátrida, o que significa que o servidor não armazena

56
00:04:22,750 --> 00:04:27,350
nenhuma informação sobre o estado após a comunicação ser concluída.

57
00:04:27,350 --> 00:04:31,850
Então, quando um servidor recebe a solicitação, o servidor responde e

58
00:04:31,850 --> 00:04:37,020
depois disso, ele não se lembra de nada mais sobre essa conversa

59
00:04:37,020 --> 00:04:39,730
entre o cliente e o servidor.

60
00:04:39,730 --> 00:04:44,620
Em terceiro lugar, a forma REST de fornecer recursos é

61
00:04:44,620 --> 00:04:49,990
expor uma estrutura de diretório como URLs de localizadores de recursos uniformes URLs.

62
00:04:51,090 --> 00:04:57,210
E quarto seu formato para troca de dados é tipicamente JSON ou

63
00:04:57,210 --> 00:05:02,360
XML, ou ambos que podem ser suportados usando REST.

64
00:05:02,360 --> 00:05:07,940
Uma das motivações para subir sugerindo REST como uma forma de apoiar serviços web

65
00:05:07,940 --> 00:05:14,060
é que ele captura tudo o que é bom de toda a World Wide Web.

66
00:05:14,060 --> 00:05:17,130
E isso fez a Word Wide Web bem sucedida.

67
00:05:17,130 --> 00:05:23,240
O uso de Indicadores Uniformes de Recursos ou Localizadores de Recursos Uniformes, URLs,

68
00:05:23,240 --> 00:05:28,660
que permitem que você aborde recursos especificando-os como um URL,

69
00:05:28,660 --> 00:05:35,370
o segundo sendo um protocolo que está no topo do protocolo HTTP.

70
00:05:35,370 --> 00:05:40,820
HTTP já encontrou ampla implantação na Internet.

71
00:05:40,820 --> 00:05:46,370
Terceiro, o ciclo de resposta de solicitação pelo qual HTTP é bem conhecido.

72
00:05:46,370 --> 00:05:51,850
Então você envia uma solicitação, o servidor recebe sua solicitação, processa a solicitação,

73
00:05:51,850 --> 00:05:57,835
envia a resposta para a solicitação, e esse cliente recebe a resposta,

74
00:05:57,835 --> 00:06:00,845
age sobre isso, e pode gerar novas solicitações.

75
00:06:00,845 --> 00:06:06,815
Então, esta abordagem do ciclo de resposta de solicitação é muito bem estabelecida com HTTP

76
00:06:06,815 --> 00:06:14,740
e o protocolo HTTP da Web em todo o mundo como vimos anteriormente,

77
00:06:14,740 --> 00:06:19,670
vamos usar todos os vários verbos que HTTP fornece.

78
00:06:19,670 --> 00:06:23,120
Especificamente, o portão colocar post delete.

79
00:06:23,120 --> 00:06:26,730
Para ser capaz de especificar operações a serem feitas

80
00:06:26,730 --> 00:06:29,680
em recursos que são armazenados no lado do servidor.

81
00:06:29,680 --> 00:06:34,320
Assim, por exemplo, se você fizer uma solicitação HTTP GET, você está pedindo

82
00:06:34,320 --> 00:06:36,180
o servidor para retornar a origem.

83
00:06:36,180 --> 00:06:41,410
Se você fizer uma solicitação POST, você está solicitando que o servidor crie um novo recurso.

84
00:06:41,410 --> 00:06:44,330
Se você fizer uma solicitação PUT, você está solicitando que o servidor atualize

85
00:06:44,330 --> 00:06:48,780
um recurso existente e, se você emitir uma solicitação de exclusão, você está pedindo

86
00:06:48,780 --> 00:06:54,210
o servidor para excluir o recurso identificado por esse URL específico.

87
00:06:54,210 --> 00:06:57,890
Além disso, ele tenta preservar a idempotência.

88
00:06:57,890 --> 00:07:00,970
Algumas operações quando são executadas

89
00:07:00,970 --> 00:07:04,370
Mesmo repetidamente não causarão qualquer alteração de estado.

90
00:07:04,370 --> 00:07:08,160
Algumas outras operações, se você as fizer sucessivamente,

91
00:07:08,160 --> 00:07:11,170
elas podem causar uma mudança de estado.

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

93
00:07:14,780 --> 00:07:16,660
quaisquer consequências prejudiciais.

94
00:07:16,660 --> 00:07:19,570
E que tem que ser feito com muito cuidado.

95
00:07:21,070 --> 00:07:25,530
No mundo REST, muitas vezes você ouve pessoas falando sobre substantivos,

96
00:07:25,530 --> 00:07:28,230
verbos e representações.

97
00:07:28,230 --> 00:07:34,120
Agora vamos esclarecer cada um deles com um pouco mais de detalhes nos próximos slides.

98
00:07:34,120 --> 00:07:36,720
Substantivos, especificamente, eles estão cheios de recursos e

99
00:07:36,720 --> 00:07:42,580
esses recursos geralmente são identificados por seus URLs e estes são irrestritos.

100
00:07:42,580 --> 00:07:48,890
Verbos são restritos e essas ações especificadas devem ser feitas nos recursos.

101
00:07:48,890 --> 00:07:53,200
E as apresentações como vemos quando as informações precisam ser transmitidas de

102
00:07:53,200 --> 00:07:54,560
o servidor para o cliente ou

103
00:07:54,560 --> 00:07:58,150
do cliente para o servidor, como você codifica as informações.

104
00:07:58,150 --> 00:08:02,840
Normalmente usando JSON ou usando XML.

105
00:08:02,840 --> 00:08:08,150
Resource é a abstração chave que o REST trabalha em torno de modo

106
00:08:08,150 --> 00:08:11,787
que as informações são abstraídas no recurso.

107
00:08:11,787 --> 00:08:18,690
E o recurso é identificado especificando-o usando um URI.

108
00:08:18,690 --> 00:08:23,040
Assim, qualquer informação que possa ser encapsulada e

109
00:08:23,040 --> 00:08:26,980
ser disponibilizada pode ser identificada como um recurso.

110
00:08:26,980 --> 00:08:33,145
Uma informação como esse clima atual em Hong Kong pode ser um recurso,

111
00:08:33,145 --> 00:08:35,465
uma imagem pode ser um recurso.

112
00:08:35,465 --> 00:08:39,915
Uma informação sobre o preço das ações pode ser um recurso, e assim por diante.

113
00:08:39,915 --> 00:08:43,905
Portanto, tudo o que você definir como uma informação que um cliente pode estar

114
00:08:43,905 --> 00:08:47,515
interessado, pode ser identificado como um recurso.

115
00:08:47,515 --> 00:08:50,965
Você pode até mesmo lidar com recursos como coleção de recursos

116
00:08:50,965 --> 00:08:55,070
que esse servidor pode enviar para esse cliente.

117
00:08:55,070 --> 00:09:00,380
Um exemplo de como você nomeia recursos é ilustrado aqui.

118
00:09:00,380 --> 00:09:03,898
Então usamos URIs para identificar a fonte.

119
00:09:03,898 --> 00:09:09,575
Uma leitura rápida da especificação ou dos URLs aqui irá

120
00:09:09,575 --> 00:09:16,525
facilmente permitir que você entenda o que estamos nos referindo usando esses URLs.

121
00:09:16,525 --> 00:09:19,675
Assim, por exemplo, algo que termina com pratos/,

122
00:09:19,675 --> 00:09:25,495
você automaticamente assume que isso está se referindo a uma coleção de pratos.

123
00:09:25,495 --> 00:09:28,909
Como pratos/123 por exemplo,

124
00:09:28,909 --> 00:09:34,150
pode significar prato número 123, neste caso e assim por diante.

125
00:09:34,150 --> 00:09:39,530
Portanto, é muito fácil dizer que você pode especificar uma coleção de recursos, e

126
00:09:39,530 --> 00:09:43,800
ser capaz de identificá-los como uma coleção, e depois baixá-los como uma coleção.

127
00:09:43,800 --> 00:09:46,960
Ou você pode identificar um recurso individual e

128
00:09:46,960 --> 00:09:50,070
dizer que deseja esse recurso específico.

129
00:09:50,070 --> 00:09:53,378
Agora esses recursos podem ser organizados em uma hierarquia

130
00:09:53,378 --> 00:09:56,500
que a especificação deste URI.

131
00:09:56,500 --> 00:09:58,860
Então, à medida que você atravessa o caminho,

132
00:09:58,860 --> 00:10:04,460
você vai do mais geral para o mais específico desse recurso.

133
00:10:04,460 --> 00:10:08,260
Esta estrutura de diretórios permite identificar facilmente os recursos que

134
00:10:09,320 --> 00:10:14,170
você fornece do seu site de serviço.

135
00:10:14,170 --> 00:10:17,970
A segunda parte da API REST são as palavras.

136
00:10:17,970 --> 00:10:22,150
Em particular, estamos interessados nos 4 verbos de HTTP para obter,

137
00:10:22,150 --> 00:10:25,320
colocar, postar e excluir.

138
00:10:25,320 --> 00:10:30,310
Neste caso, esses verbos serão cochilados para ações que

139
00:10:30,310 --> 00:10:36,165
queremos que sejam executadas no recurso no lado do servidor.

140
00:10:36,165 --> 00:10:40,760
GetT significaria que você deseja executar uma operação de leitura no recurso, o que significa

141
00:10:40,760 --> 00:10:46,550
que um cliente enviando uma solicitação get está indicando ao servidor que ele deseja

142
00:10:46,550 --> 00:10:52,710
obter essa apresentação da fonte de dados do site do servidor para o site do cliente.

143
00:10:52,710 --> 00:10:56,770
POST significa que você deseja criar um novo recurso e então você vai.

144
00:10:56,770 --> 00:11:01,700
Especifique os detalhes do recurso na representação, mas é usado para

145
00:11:01,700 --> 00:11:02,850
especificar o recurso.

146
00:11:02,850 --> 00:11:05,900
Em seguida, envie as informações para o lado do servidor, para

147
00:11:05,900 --> 00:11:09,590
que o servidor irá criar o recurso em seu nome.

148
00:11:09,590 --> 00:11:12,310
Um PUT seria modificação de recursos, e

149
00:11:12,310 --> 00:11:16,030
delete, como você esperaria, é exclusão das fontes.

150
00:11:16,030 --> 00:11:20,550
Então, como você pode ver os quatro verbos obter, postar, colocar e

151
00:11:20,550 --> 00:11:25,670
delete são mapeados para as quatro operações CRUD que você pode executar

152
00:11:25,670 --> 00:11:30,140
em um banco de dados que armazena esses recursos no lado do servidor.

153
00:11:30,140 --> 00:11:34,130
As operações de leitura, criação, atualização e exclusão.

154
00:11:34,130 --> 00:11:39,140
Elaborando mais, o HTTP GET é uma maneira de especificar.

155
00:11:39,140 --> 00:11:43,560
Que você deseja que as informações ou sua apresentação do recurso sejam

156
00:11:43,560 --> 00:11:46,280
retornadas ao cliente a partir do site do servidor.

157
00:11:46,280 --> 00:11:49,980
Então, quando você emite uma solicitação GET para um endpoint da API REST.

158
00:11:49,980 --> 00:11:54,370
Você está pedindo uma coleção de recursos que são apresentados por

159
00:11:55,890 --> 00:12:01,790
Uri ou um recurso específico que é identificado pelo ID de

160
00:12:01,790 --> 00:12:06,950
que recursos específicos especificados dentro da URL assim como você vê neste exemplo,

161
00:12:06,950 --> 00:12:13,090
se você pratos/452, você está querendo dizer que o prato número 452,

162
00:12:13,090 --> 00:12:16,950
com o id 452 deve ser devolvido ao lado do cliente.

163
00:12:19,370 --> 00:12:24,210
Da mesma forma, a operação de post, como vimos, é usada para criar o recurso.

164
00:12:24,210 --> 00:12:29,940
Então, quando você cria o recurso, o conteúdo de descrever o recurso seria

165
00:12:29,940 --> 00:12:34,830
na forma de uma representação JSON ou uma representação XML, e isso seria

166
00:12:34,830 --> 00:12:40,220
incluído no corpo da mensagem de solicitação que é enviada para o lado do servidor.

167
00:12:40,220 --> 00:12:43,900
Portanto, uma operação de postagem espera uma representação

168
00:12:43,900 --> 00:12:49,040
do recurso no formato JSON ou XML no corpo da mensagem de solicitação.

169
00:12:49,040 --> 00:12:53,250
E o servidor recebe essa mensagem de solicitação, o servidor cria esse recurso

170
00:12:53,250 --> 00:12:58,440
no lado do servidor e retorna uma confirmação ou

171
00:12:58,440 --> 00:13:04,390
um erro para indicar que a criação do recurso falhou.

172
00:13:04,390 --> 00:13:08,820
Da mesma forma ele colocar operação fácil de usar para atualizar um recurso.

173
00:13:08,820 --> 00:13:14,630
Quando você faz uma operação PUT em um recurso no lado do servidor, você pode enviar de volta

174
00:13:14,630 --> 00:13:19,630
a modificação especificando apenas a modificação parcial

175
00:13:19,630 --> 00:13:25,450
que você deseja afetar o recurso específico no corpo da mensagem de resposta.

176
00:13:25,450 --> 00:13:29,370
Ou você pode enviar a representação completa do recurso

177
00:13:29,370 --> 00:13:33,890
no corpo da mensagem, dependendo do arranjo entre o cliente e

178
00:13:33,890 --> 00:13:38,760
o servidor, o servidor espera que as informações sejam

179
00:13:38,760 --> 00:13:43,320
transmitidas no corpo da mensagem de solicitação.

180
00:13:43,320 --> 00:13:48,980
operação DELETE como você esperaria exclui o recurso existente.

181
00:13:48,980 --> 00:13:55,150
Agora, neste caso particular, é claro, uma operação de exclusão seria porque

182
00:13:55,150 --> 00:14:00,220
se você tentar excluir um recurso e o recurso existir, ele será excluído.

183
00:14:00,220 --> 00:14:02,440
Se você estiver tentando excluir um recurso não existente,

184
00:14:02,440 --> 00:14:07,990
ele não causará nenhuma modificação adicional no lado do servidor Exceto

185
00:14:07,990 --> 00:14:11,808
que o servidor responderá com um erro dizendo que o recurso não existe.

186
00:14:11,808 --> 00:14:18,700
Mas, no entanto, é um exemplo de uma operação neste caso.

187
00:14:18,700 --> 00:14:22,810
Da mesma forma, a operação get também funcionará porque não é

188
00:14:22,810 --> 00:14:27,140
fazendo qualquer modificação no recurso no site do servidor.

189
00:14:27,140 --> 00:14:32,740
Entrada de postagem, é claro, vai modificar o recurso no lado do servidor.

190
00:14:32,740 --> 00:14:34,770
Você precisa criar um novo recurso ou

191
00:14:34,770 --> 00:14:40,050
modificar recurso existente no lado do servidor e, claro, apresentações de dados.

192
00:14:40,050 --> 00:14:45,050
Como eu tenho enfatizado, os dois fallbacks comuns para

193
00:14:45,050 --> 00:14:51,570
representando é JSON XML, a última parte

194
00:14:51,570 --> 00:14:57,140
que precisamos enfatizar é que o lado do servidor deve ser completamente apátrida.

195
00:14:57,140 --> 00:15:01,190
O que significa, que o lado do servidor não rastreia o estado do cliente.

196
00:15:01,190 --> 00:15:07,060
Porque, se o servidor precisar rastrear o estado do cliente, ele não será escalável.

197
00:15:07,060 --> 00:15:11,140
Assim, para uma implementação escalável do lado do servidor,

198
00:15:11,140 --> 00:15:15,650
você normalmente usa um servidor sem estado no lado do servidor.

199
00:15:15,650 --> 00:15:19,580
Portanto, se a solicitação dos clientes enviados para o servidor será tratada como

200
00:15:19,580 --> 00:15:25,460
uma solicitação independente, e não refletirá sobre as solicitações

201
00:15:25,460 --> 00:15:30,790
anteriores que já foram tratadas pelo servidor do cliente específico.

202
00:15:30,790 --> 00:15:35,760
Portanto, é responsabilidade do cliente rastrear seu próprio estado.

203
00:15:35,760 --> 00:15:40,770
Ou na forma de usar cookies ou usar um banco de dados do site do cliente.

204
00:15:40,770 --> 00:15:43,780
O que quer que signifique que é adequado.

205
00:15:43,780 --> 00:15:48,760
Agora, essa abordagem em que o cliente rastreia seu próprio estado é muito mais escalável,

206
00:15:48,760 --> 00:15:52,880
porque seu cliente será responsável por rastrear o seu próprio estado.

207
00:15:54,340 --> 00:15:58,880
E é aqui que a configuração do lado do cliente MVC nos ajuda a este respeito.

208
00:16:00,100 --> 00:16:04,920
E, finalmente, ainda não terminamos com REST, veremos mais de

209
00:16:04,920 --> 00:16:10,280
REST nos exercícios que se seguem nesta lição particular.

210
00:16:10,280 --> 00:16:11,563
E então também,

211
00:16:11,563 --> 00:16:17,206
vamos ver mais detalhes sobre o uso REST no resto deste curso.

212
00:16:17,206 --> 00:16:20,509
[MÚSICA]