Na palestra anterior,
aprendemos sobre REST API.
Você viu como os pontos finais da API REST
suportam uma maneira de um aplicativo cliente ser capaz de recuperar
dados do servidor ou carregar dados para o servidor usando as várias operações HTTP.
Nesta palestra e exercício que se segue a esta palestra,
analisaremos especificamente o tipo de suporte que o Express
suporta para projetar e implementar um servidor baseado em API REST.
Em particular, também vamos olhar para o roteador Express,
e como ele nos permite subdividir nosso aplicativo e
depois organizá-lo em vários aplicativos mini Express-like,
que se combinam para formar o aplicativo Express,
especificamente quando estamos lidando com várias API REST e peças.
Então, para resumir, na palestra anterior,
examinamos o REST em detalhes.
Também analisamos como cada endpoint é identificado por um URI
e como podemos especificar as várias operações a serem feitas em
cada endpoint usando o verbo HTTP apropriado, o
GET, PUT, POST ou DELETE.
Agora, nesta palestra,
veremos como o Express suporta o desenvolvimento de um servidor de API REST.
Vamos olhar para o suporte do Express para vários assuntos como app.all,
app.get, put, post e delete,
e como esses métodos podem ser usados para construir um servidor de API REST.
No Express, os vários grupos de aplicativos podem ser definidos usando o aplicativo,.
e os vários métodos.
Então, o app.all especifica uma operação que precisa ser feita em todos os vários verbos,
on, in, e parte.
Assim, por exemplo, neste exemplo,
vemos que o endpoint é definido por /dish,
e assim o app.all, o que for especificado na função que é dada para app.all,
será aplicado a todas as solicitações recebidas.
O app.get especifica o que precisa ser feito para solicitações GET e,
correspondentemente, para as
solicitações POST, PUT e DELETE que são enviadas para o endpoint /dish,
como mostrado neste exemplo. O
Express também suporta a definição de endpoints com parâmetros.
Assim, por exemplo, você pode especificar um ID de prato específico, se desejar,
e então deixar a operação ser executada para
esse ponto final específico referente a esse prato específico com um dado ID de prato.
Então, neste caso, o ID do prato em si é
especificado como um parâmetro e o padrão usado para isso é,
como você vê neste exemplo,
/dishes/: e então você especificaria o parâmetro aqui.
Para facilitar a compreensão,
nomeei o parâmetro como DishID lá.
Você pode usar qualquer nome de parâmetro que escolher, mas novamente,
usar um nome significativo para um parâmetro torna mais fácil entender o código.
Então, neste exemplo,
o:DISHID significa que se emitirmos uma solicitação
para um endpoint, digamos, por exemplo,
/dishes/23, então o parâmetro DISHID nos permite extrair esse número 23 para que
possamos operar no prato número 23 dentro
da função especificada dentro deste método aqui.
Então lá, o parâmetro,
o próprio parâmetro DishID pode ser obtido usando o objeto request no qual
a propriedade params que você suportou e
a propriedade params suporta todos os parâmetros de solicitação de entrada,
e DISHID, em particular,
é um desses parâmetros de solicitação que pode ser acessado,
como mostrado no código aqui.
Quando você envia uma solicitação PUT ou POST do cliente para o servidor,
você geralmente está anexando os dados no corpo da mensagem que é enviada para o servidor.
Agora, o que significa que precisamos
de um método para extrair informações do corpo da mensagem.
Então é aqui que o middleware do analisador de corpo para Express é muito útil.
Assim, o analisador de corpo nos permite analisar as informações do corpo da mensagem.
Para usar o analisador de corpo, como seria de esperar,
nós instalaríamos o módulo do nó corpo-parser
e, em seguida, exigi-lo dentro do nosso aplicativo Express
e, em seguida, especificar app.use (BodyParser).
E se o corpo contém dados no formato JSON,
você pode dizer bodyParser.json, o
que significa que isso irá analisar apenas os dados que estão no
formato JSON que está incluído no corpo da mensagem de solicitação.
Em particular, no exercício,
estaremos analisando dados recebidos que são enviados na forma de uma string JSON.
O analisador de corpo, como seria de esperar,
analisa o corpo da mensagem e preenche a propriedade req.body.
Assim, na solicitação,
a propriedade body conterá o que for analisado
a partir do corpo da mensagem de solicitação pelo analisador de corpo.
Se você estiver implementando um aplicativo Express
que suporta vários pontos finais da API REST,
então faz sentido subdividir o código em
vários módulos e, em seguida, fazer uso deles para construir o aplicativo Express geral.
Então é aqui que o roteador Express vem em nosso auxílio.
Um roteador Express define muitos aplicativos Express,
e dentro de muitos aplicativos Express,
você pode, por exemplo,
lidar com um ponto de extremidade da API REST em particular com mais detalhes,
ou um padrão específico do ponto de extremidade da API REST com mais detalhes.
Então, por exemplo, podemos definir um DishRouter como Express.Router
e, em seguida, o DishRouter pode lidar com os endpoints.
Então, quando você expressa algo como Express.Router,
ele suporta o endpoint de rota.
Uma das razões para usar o roteador Express,
como você perceberia,
é que se usarmos o aplicativo padrão GET,
PUT, POST e DELETE métodos,
para cada um desses métodos,
você precisa especificar explicitamente os pontos finais da API REST.
Uma vantagem de usar o roteador Express é que se você
disser o roteador.Route e, em seguida, especificar o
endpoint, esse endpoint será aplicado a todos os métodos e todos os vários
métodos relacionados ao verbo GET, PUT, POST e DELETE podem ser encadeados
juntos na rota na definição do código para a nossa aplicação.
Analisaremos mais detalhes sobre isso no exercício que se segue a esta palestra.
Com essa compreensão rápida de como o Express suporta o ponto final da API REST,
vamos passar para o exercício onde construiremos
seu suporte para o endpoint da API REST /meals.
Como parte da primeira atribuição,
você estará estendendo ainda mais
este aplicativo Express para suportar endpoints adicionais da API REST,
incluindo /promotions e /leaders.
Se você fez os cursos anteriores na especialização,
você começará imediatamente a ver por que estamos dando suporte a
todos esses diferentes pontos de extremidade da API REST em outro lado do servidor.