En la conferencia anterior,
aprendimos acerca de la API REST.
Ha visto cómo los extremos de la API REST
admiten una forma de que una aplicación cliente pueda recuperar
datos del servidor o cargar datos en el servidor mediante las diversas operaciones HTTP.
En esta conferencia y ejercicio que sigue a esta conferencia,
veremos específicamente qué tipo de soporte
admite Express para diseñar e implementar un servidor basado en API REST.
En particular, también veremos el router Express,
y cómo nos permite subdividir nuestra aplicación y
luego organizarla en múltiples aplicaciones tipo mini Express,
que se combinan para formar la aplicación Express,
específicamente cuando estamos tratando con varias API REST y partes.
Así que para resumir, en la conferencia anterior,
examinamos REST en detalle.
También analizamos cómo cada extremo es identificado por un URI,
y cómo podemos especificar las diversas operaciones que se deben realizar en
cada extremo utilizando el verbo HTTP apropiado,
GET, PUT, POST o DELETE.
Ahora, en esta conferencia,
veremos cómo Express soporta el desarrollo de un servidor de API REST.
Vamos a ver el soporte de Express para varios asuntos como app.all,
app.get, put, post y delete,
y cómo estos métodos se pueden usar para construir un servidor API REST.
Dentro de Express, los distintos grupos de aplicaciones se pueden definir mediante la aplicación,.
y los diversos métodos.
Por lo tanto, la app.all especifica una operación que debe hacerse en todos los diversos verbos,
on, in, and part.
Así, por ejemplo, en este ejemplo,
vemos que el endpoint está definido por /dish,
y por lo tanto la app.all, lo que se especifique en la función que se da para app.all,
se aplicará a todas las solicitudes entrantes.
App.get especifica lo que hay que hacer para las solicitudes GET y, en
consecuencia, para las
solicitudes POST, PUT y DELETE que se envían al extremo /dish,
como se muestra en este ejemplo.
Express también admite la definición de los endpoints con parámetros.
Así, por ejemplo, puede especificar un ID de plato específico si lo desea,
y luego dejar que la operación se realice para
ese punto final específico refiriéndose a ese plato específico con un ID de plato dado.
Entonces, en este caso, el ID de plato se
especifica como parámetro y el patrón utilizado para eso es,
como puede ver en este ejemplo,
/dishes/: y luego especificaría el parámetro aquí.
Para que nos sea fácil de entender,
nombré el parámetro como DISHID allí.
Puede usar cualquier nombre de parámetro que elija, pero de nuevo,
usar un nombre significativo para un parámetro hace que sea más fácil entender el código.
Así que en este ejemplo,
The:DISHID significa que si emitimos una solicitud a un punto final,
digamos por ejemplo, /dishes/23,
entonces el parámetro DIShiD nos permite extraer este número 23 para que
podamos operar en el plato número 23 dentro de
la función que se especifica dentro de este método aquí.
Entonces, allí, el parámetro,
el parámetro DISHID en sí se puede obtener utilizando el objeto request en el que
la propiedad params admitió y
la propiedad params admite todos los parámetros de solicitud entrante,
y DISHID, en particular,
es uno de esos parámetros de solicitud que ,
como se muestra en el código aquí.
Cuando envía una solicitud PUT o POST desde el cliente al servidor,
suele incluir los datos en el cuerpo del mensaje que se envía al servidor.
Ahora, lo que significa que necesitamos un método para
extraer información del cuerpo del mensaje.
Entonces, aquí es donde el middleware del analizador corporal para Express es muy útil.
Por lo tanto, el analizador del cuerpo nos permite analizar la información del cuerpo del mensaje.
Para usar el analizador corporal, como era de esperar,
instalaríamos el módulo de nodo body-parser,
y luego lo necesitaríamos dentro de nuestra aplicación Express,
y luego especificamos app.use (BodyParser).
Y si el cuerpo contiene datos en el formato JSON,
puede decir BodyParser.json,
lo que significa que esto solo analizará los datos que están en
formato JSON que está encerrado en el cuerpo de ese mensaje de solicitud.
En particular, en el ejercicio,
vamos a analizar los datos entrantes que se envían en forma de una cadena JSON.
El analizador de cuerpo, como era de esperar,
analiza el cuerpo del mensaje y rellena la propiedad req.body.
Por lo tanto, en la solicitud,
la propiedad body contendrá lo que se analiza desde
el cuerpo del mensaje de solicitud por el analizador de cuerpo.
Si está implementando una aplicación Express
que admite múltiples puntos finales de API REST,
entonces tiene sentido subdividir el código en
varios módulos y luego hacer uso de ellos para construir la aplicación Express general.
Entonces aquí donde el enrutador Express viene en nuestra ayuda.
Un router Express define muchas aplicaciones Express,
y dentro de esas muchas aplicaciones Express,
puede, por ejemplo,
tratar con un punto final de API REST en particular con más detalle,
o un patrón particular de extremo API REST con más detalle.
Entonces, por ejemplo, podemos definir un DishRouter como express.Router,
y luego el DishRouter puede manejar los puntos finales.
Así que cuando expresas algo como express.Router,
es compatible con el punto final de la ruta.
Una de las razones para usar el router Express,
como se daría cuenta,
es que si usamos los
métodos GET, PUT, POST y DELETE de la aplicación estándar,
para cada uno de estos métodos, es
necesario especificar explícitamente los extremos de la API REST.
Una ventaja de usar el router Express es que si
dice el router.Route y luego especifica el punto final,
ese extremo se aplicará a todos los métodos y todos los diversos
métodos relacionados con GET, PUT, POST y DELETE se pueden encadenar
juntos en la ruta en la definición del código para nuestra aplicación.
Vamos a ver más detalles de esto en el ejercicio que sigue a esta conferencia.
Con esta rápida comprensión de cómo Express soporta endpoint API REST,
pasemos al ejercicio en el que construiremos
su soporte para el endpoint de la API REST.
Como parte de la primera asignación,
ampliará aún más
esta aplicación Express para admitir puntos finales de API REST adicionales,
incluyendo /promotions y /leaders.
Si ha tomado los cursos anteriores en la especialización,
inmediatamente comenzará a ver por qué estamos soportando
todos estos diferentes extremos de la API REST en el otro lado del servidor.