Neste módulo na primeira lição,
aprendemos como construir um servidor API REST completo usando o express.
Assim, podemos atender as
solicitações GET, PUT, POST e DELETE que chegam aos vários pontos finais da API REST.
Mas, o próprio servidor estava simplesmente retornando
uma mensagem simples em resposta a essas solicitações.
Em um servidor de API REST real,
qualquer solicitação de entrada implicará uma operação correspondente a ser executada na parte traseira
do banco de dados, talvez para recuperar dados para responder a uma solicitação GET,
ou talvez para modificar dados existentes no servidor em resposta a uma solicitação PUT.
Agora, no resto deste módulo,
temos estudado sobre como podemos interagir a partir de um aplicativo nó com um servidor MongoDB,
seja usando o driver MongoDB ou usando Mangusto.
Agora, um servidor API REST completo que é capaz de lidar com
a solicitação de ponta a ponta só será possível quando combinarmos os dois juntos.
Ou seja, um servidor baseado em expressa que faz
todo o processamento de lógica de negócios e, ao mesmo tempo, emitirá
as solicitações de banco de dados para o MongoDB
usando o driver Mongoose nó ou usando o Mongoose.
Então, como combinamos os dois juntos?
Então é isso que vamos olhar nesta lição em particular,
e os dois exercícios que faremos como parte desta lição.
Agora aprendemos como construir
um servidor de API REST usando o Express
e atender as várias solicitações que chegam aos pontos finais da API REST.
Nós também vimos como podemos interagir com o banco de dados do nosso aplicativo nó.
Agora, dado que você tem uma solicitação GET entrando no servidor como um exemplo,
para lidar com essa solicitação GET de ponta a ponta,
uma solicitação GET proveniente do cliente significa que o cliente deseja recuperar
dados do servidor e usar esses dados.
Assim, uma solicitação GET entrando no servidor terá que ser
tratada através dos vários processamento feito por, por exemplo,
o servidor Express e uma vez que o processamento é feito, a
lógica de negócios do servidor Express percebe que ele precisa
executar uma operação de consulta no banco de dados.
Então, isso pode iniciar uma consulta para o banco de dados, a fim de
buscar um conjunto de documentos do banco de dados,
e, em seguida, os dados recuperados serão
transformados em uma mensagem de resposta e, em seguida, enviados de volta para o servidor.
Portanto, este tratamento de ponta a ponta da solicitação e resposta envolve duas partes.
Um, claro, fazendo a lógica de negócios
no servidor Express e, em seguida, fazendo a interação com
o banco de dados do aplicativo nó do servidor Express, que é
um aplicativo de nó usando driver Mongoose ou Mongoose.
Vamos usar Mangusto nos exercícios.
Da mesma forma, uma solicitação POST chegando
ao ponto final da API REST no servidor significa que
a solicitação POST traz alguns dados no corpo da mensagem.
Então, essas informações precisam ser processadas no servidor Express
e as informações que precisam ser armazenadas no
banco de dados devem ser recuperadas do corpo da solicitação POST de entrada e, em seguida, a
solicitação de criação correspondente precisa
ser criada ou iniciada a partir do servidor Express para o banco de dados MongoDB,
e na solicitação de criação,
as informações que foram recuperadas do corpo
da solicitação POST serão enviadas para
o banco de dados para criar um novo documento em uma coleção específica no banco de dados.
E, em seguida, o resultado desta operação será enviado de
volta para o cliente na mensagem de resposta.
Assim, qualquer operação que é feita em um ponto final da API REST seja um GET,
um PUT, um POST
ou uma operação DELETE,
como você pode ver nesses dois exemplos,
iniciará uma operação de banco de dados correspondente nos bastidores.
Então, tendo entendido essa interação,
o que percebemos é que uma solicitação HTTP chegando a
um ponto final da API REST deve ser mapeada em uma operação de banco de dados correspondente.
Assim, cada solicitação de entrada, o GET, PUT, POST
ou DELETE significa que um recurso específico no banco de dados pode ser acessado,
pode ser recuperado ou um grupo de recursos pode ser
recuperado do banco de dados e, em seguida, enviado de volta para o servidor,
ou um recurso pode ser modificado em resposta a um PUT ou um POST
ou até mesmo uma solicitação DELETE chegando ao servidor de API REST.
Portanto, cabe à lógica do servidor Express,
a lógica de negócios implementada no servidor de API REST Express,
lidar com essa tradução da solicitação de entrada seja uma solicitação GET,
PUT, POST ou DELETE na operação de banco de dados correspondente.
Então, vejamos um exemplo disso com um pouco mais de detalhes.
Então, chegando à combinação do roteador Express mais
MongoDB mais Mongoose atuando como o ODM entre,
as operações a serem executadas do banco de dados devem ser iniciadas
dentro do roteador que criamos para cada ponto final da API REST.
Então, dentro do roteador,
até mesmo o método GET,
o PUT ou o método POST.
A ação correspondente a ser executada no banco de dados se é uma solicitação GET
causando um método de localização de pratos a ser executado ou
uma solicitação POST causando um método de criação de pratos
a ser executado, terá que ser feita pelo nosso servidor Express resultando
na operação correspondente sendo iniciado no banco de dados MongoDB.
Então, com essa compreensão de
como as solicitações são traduzidas em operações de banco de dados correspondentes,
vamos prosseguir para os dois exercícios onde vamos olhar para lidar com a
solicitação GET, PUT, POST, e DELETE chegando aos pontos de extremidade /Dishes/:DISHID e
também para modificar comentários que estão
nos sub-documentos fechados dentro do documento prato.