‫Instructor: Ahora que sabemos qué es Express,
‫estamos casi listos para comenzar a construir nuestra API.
‫Pero antes de
‫hacer eso, necesito hablar rápidamente sobre las API en un
‫nivel superior y, lo que
‫es más importante, presentarles la Arquitectura REST,
‫que es la arquitectura API más utilizada en la actualidad.
‫De esta manera, realmente sabremos lo que estamos construyendo.
‫Por lo tanto, es extremadamente importante comprender el
‫contenido de este video antes de
‫continuar, para que sepamos realmente lo que estamos construyendo
‫durante el resto del curso.
‫En primer
‫lugar, API significa Interfaz de programación de aplicaciones y, en
‫un nivel muy alto, es
‫básicamente una pieza de software que puede ser utilizada
‫por otra pieza de software para
‫permitir que las aplicaciones se comuniquen entre sí.
‫De hecho, hemos hablado antes de
‫las API, más específicamente, de las API web,
‫en las que simplemente creamos una aplicación que
‫envía datos a un cliente cada vez que entra una solicitud.
‫Imagina que tenemos nuestra aplicación ejecutándose en un servidor
‫y tenemos un cliente.
‫Entonces, de hecho, efectivamente tenemos dos piezas de software
‫hablando entre sí, ¿verdad?
‫Y este es el tipo de API que crearemos en este curso.
‫Y supongo que es el tipo de API más utilizado que existe.
‫Pero, de hecho, las API no solo se utilizan para enviar datos y
‫no siempre están relacionadas con el desarrollo web o JavaScript.
‫La aplicación en API en realidad puede
‫significar muchas cosas diferentes siempre que el
‫software sea relativamente independiente.
‫Tomemos, por
‫ejemplo, el sistema de archivos de nodo o los módulos HTTP.
‫Podemos decir que son pequeñas piezas de
‫software y
‫podemos usarlas, podemos interactuar con ellas usando su API.
‫Por
‫ejemplo, cuando usamos la función readfile del módulo FS,
‫en realidad estamos usando la API FS.
‫Y es por eso que a veces escuchará el término API de nodo.
‫Y eso generalmente se refiere simplemente a los módulos de nodo central
‫con los que podemos interactuar.
‫O cuando hacemos manipulación DOM en el navegador,
‫no estamos realmente usando el lenguaje JavaScript en sí,
‫sino la API DOM que el navegador nos expone, por lo que
‫nos da acceso a ella.
‫O incluso otro ejemplo, digamos
‫que creamos una clase en cualquier lenguaje de programación
‫como Java y luego le agregamos algunos métodos
‫públicos o propiedades.
‫Estos métodos serán la API de cada objeto creado
‫a partir de esa clase porque estamos
‫dando a otras piezas de software la
‫posibilidad de interactuar con nuestra pieza inicial de software, los
‫objetos, en este caso.
‫Verá, API tiene en realidad un significado más amplio
‫que simplemente crear API web.
‫¿Bien? De todos modos, una API web es
‫lo más importante para nosotros en el contexto de la nota.
‫Echemos ahora un vistazo a la arquitectura REST
‫para crear API.
‫REST, que significa Representational States Transfer, es básicamente una forma
‫de construir API web de una manera lógica, haciéndolas
‫fáciles de consumir porque
‫recuerde, creamos una API para nosotros o para
‫que otros la consuman, ¿de acuerdo?
‫Queremos que el proceso de utilizar la API sea lo más
‫sencillo posible para el usuario.
‫Ahora, para construir API RESTful,
‫lo que significa API siguiendo la Arquitectura REST, solo
‫necesitamos seguir un par de principios.
‫Primero, necesitamos separar nuestra API en recursos lógicos.
‫Luego, estos recursos deben exponerse, lo
‫que significa que deben
‫estar disponibles mediante URL estructuradas y basadas en recursos.
‫Para realizar diferentes acciones
‫en los datos, como leer, crear o eliminar
‫datos, la API debe usar los métodos HTP correctos y no la URL.
‫Ahora, los datos que realmente enviamos al cliente
‫o que recibimos del cliente
‫generalmente deben usar el formato de datos
‫JSON, donde se le aplica algún estándar de formato.
‫Finalmente, otro principio importante de las API
‫REST es que deben ser apátridas.
‫Así que esta es una descripción general muy amplia.
‫Comencemos ahora a hablar sobre estos principios
‫uno por uno, comenzando con los recursos y usando la API
‫de Nators que vamos a construir en este
‫curso como un ejemplo aquí.
‫La abstracción clave de información en REST es un recurso
‫y, por lo tanto, todos los
‫datos que queremos compartir en la API deben dividirse en recursos lógicos.
‫Ahora bien, ¿qué es realmente un recurso?
‫Bueno, en el contexto
‫de REST, es un objeto o una representación
‫de algo que tiene algunos datos asociados.
‫Por ejemplo,
‫tours, o usuarios, o reseñas en el
‫caso del ejemplo que estamos siguiendo.
‫Entonces, básicamente, cualquier información que se pueda nombrar
‫puede ser un recurso, ¿de acuerdo?
‫Sin embargo, solo tiene que ser un nombre, no un verbo.
‫Ahora, necesitamos exponer,
‫lo que significa poner a
‫disposición, los datos utilizando algunas URL estructuradas a las
‫que el cliente puede enviar una solicitud.
‫Por ejemplo, algo como esto.
‫Esta dirección completa se llama URL
‫y este / addNewTour se llama API Endpoint.
‫Nuestra API tendrá muchos puntos finales diferentes al
‫igual que estos puntos finales ficticios que tengo
‫aquí, cada uno de los cuales enviará datos diferentes al
‫cliente o también realizará diferentes acciones.
‫Ahora, en realidad, hay algo
‫muy mal con estos puntos finales aquí porque realmente
‫no siguen la tercera regla que dice que
‫solo debemos usar los métodos HTTP para realizar acciones en los datos.
‫Por lo tanto, los puntos finales solo deben contener nuestros recursos
‫y no las acciones que se pueden realizar
‫en ellos porque rápidamente se convertirán en una pesadilla de mantener.
‫¿Cómo deberíamos utilizar estos métodos HTTP en la práctica?
‫Bueno, veamos cómo deberían
‫verse realmente estos puntos finales al comenzar con / getTour.
‫Entonces, este punto final / getTour es para obtener datos sobre un recorrido.
‫Entonces, simplemente deberíamos nombrar el punto final / recorridos y enviar
‫los datos cada vez que se realiza una solicitud
‫de obtención a este punto final.
‫En otras palabras,
‫cuando un cliente usa un método GET HTTP
‫para acceder al punto final.
‫Y así,
‫solo tenemos recursos en el punto
‫final o en la URL y no verbos porque
‫el verbo ahora está en el método HTTP, ¿verdad?
‫Y, por
‫cierto, es una práctica común usar siempre el nombre
‫del recurso en plural, por lo que tengo / tours aquí y no / tour.
‫Ahora, la convención es que al llamar a ese punto
‫final, recuperamos todos los recorridos que están en una base de datos, ¿de acuerdo?
‫Pero si solo queremos la gira con un yo. D. digamos siete, agregamos
‫ese siete después de otra barra o en una consulta de búsqueda.
‫O también podría ser el nombre de una gira en lugar del I. D. o algún otro identificador único.
‫El detalle realmente no importa en este punto, ¿de acuerdo?
‫Más adelante, les mostraré lo
‫fácil que es implementar este tipo de lógica con
‫Express porque aquí es donde Express realmente brilla.
‫El primer método HTTP o verbo
‫al que podemos responder es GET y se usa para
‫realizar la operación de lectura en los datos.
‫Siguiente parada, si el cliente
‫desea crear un nuevo recurso en nuestra base de datos,
‫en este ejemplo, un
‫nuevo recorrido, se debe utilizar el método POST.
‫Entonces, aprendimos anteriormente que una solicitud
‫POST se puede usar para enviar datos
‫al servidor, por lo que tiene sentido usar POST para
‫crear nuevos recursos, ¿verdad?
‫Ahora, en este caso, normalmente no yo. D. se enviará porque
‫el servidor debería averiguar automáticamente el
‫I. D. para el nuevo recurso.
‫De todos modos, lo que es realmente importante tener en cuenta aquí es cómo el nombre del punto final es exactamente
‫el mismo nombre que antes.
‫La única diferencia es realmente
‫el método HTP que se utiliza para la solicitud.
‫Si se accede al punto final / tours con
‫GET, enviamos datos al cliente.
‫Pero si se accede al mismo punto final con POST, esperamos
‫que los datos ingresen con
‫una solicitud, de modo que podamos crear un
‫nuevo recurso en el lado del servidor.
‫Así que esa es realmente la belleza de usar solo métodos HTTP en lugar de
‫jugar con verbos en los nombres de los extremos.
‫Una vez más, se volvería realmente inmanejable muy rápido.
‫Muy bien, a continuación, también
‫debería existir la posibilidad de actualizar los recursos.
‫Y para eso, se debe realizar
‫una solicitud PUT o PATCH al punto
‫final.
‫La diferencia entre ellos es que con
‫PUT, se supone que el cliente
‫envía todo el objeto actualizado, mientras que
‫con PATCH, se supone que envía solo la parte del objeto que
‫se ha cambiado.
‫Pero ambos tienen la capacidad de
‫enviar datos al servidor.
‫Un poco como POST, en realidad, pero con una intención diferente.
‫Entonces, POST es crear
‫un nuevo recurso, mientras que PUT o PATCH se usan para
‫actualizar un recurso existente y, por
‫lo tanto, hace toda la diferencia.
‫Y finalmente, para el recurso
‫de basura, está el método DELETE HTTP.
‫Una vez más, el I. D. o algún otro identificador único del recurso
‫que se va a eliminar debe formar parte de
‫la URL.
‫Ahora, por lo general, para
‫poder realizar este tipo
‫de solicitud, el cliente debe estar autenticado.
‫Entonces, básicamente, inicie sesión en su aplicación, ¿de acuerdo?
‫Pero ese es, por supuesto, un tema para mucho más tarde.
‫Entonces, estos son los cinco métodos HTTP a
‫los que podemos y debemos responder
‫cuando construimos nuestras API RESTful para que
‫el cliente pueda realizar
‫las cuatro operaciones CRUD básicas.
‫Entonces CRUD significa Crear, Leer, Actualizar y Eliminar.
‫Y verá este término todo
‫el tiempo relacionado con API y bases de datos.
‫Y verá que estos métodos HTTP
‫se asignan bastante bien a las operaciones CRUD básicas.
‫Ahora bien, puede haber
‫acciones que no sean CRUD, y en ese caso,
‫solo necesitamos ser creativos con nuestras aportaciones.
‫Por ejemplo, un inicio
‫de sesión o una operación de búsqueda, estos no
‫están realmente
‫relacionados con un recurso en particular y
‫tampoco son operaciones CRUD, pero aún podemos crear puntos finales para ellos.
‫Por ejemplo, como / login o / search.
‫Pero hablaremos más sobre estos casos más adelante en la práctica.
‫Y solo para terminar esta parte ahora, recuerde
‫que teníamos otros dos nombres de puntos finales locos en
‫la última diapositiva que
‫involucraban dos recursos al mismo tiempo, ¿verdad?
‫Y eso tampoco es un problema con REST.
‫Entonces, / getToursByUser simplemente se
‫puede traducir a / users /
‫tours, en este caso, el usuario número tres.
‫Entonces, este punto final en particular aquí podría
‫enviar datos sobre todos los recorridos que el
‫usuario número tres ha reservado.
‫¿Tiene sentido?
‫O en el caso de eliminar, podría haber una
‫solicitud de eliminación
‫para el mismo punto final o uno
‫muy similar, solicitando que el tour número nueve se elimine
‫del usuario número tres, ¿de acuerdo?
‫Entonces, realmente hay un montón
‫de posibilidades de combinar recursos como este.
‫Pero, por supuesto, no tenemos que implementar todas
‫estas combinaciones en nuestra API.
‫Solo implementamos lo que tiene
‫sentido en el caso de nuestra aplicación y
‫el cliente que quiere consumir nuestra API.
‫Entonces, así es como
‫usamos los métodos HTTP para crear URL fáciles de usar
‫y bien estructuradas que son fáciles y lógicas de consumir para el cliente.
‫Ahora, sobre los datos que el cliente realmente
‫recibe, o que el servidor recibe
‫del cliente, usualmente usamos el formato de datos JSON.
‫Entonces, aprendamos brevemente qué es JSON en realidad
‫y cómo formatear nuestras respuestas API.
‫JSON es un formato de intercambio de datos
‫muy ligero que es muy
‫utilizado por las API web codificadas en cualquier lenguaje de programación.
‫Así que simplemente no está relacionado con JavaScript.
‫Y es tan ampliamente utilizado hoy en
‫día porque es realmente fácil para los humanos y
‫las computadoras entender y escribir JSON.
‫Así que probablemente ya estés notando que JSON se parece un poco
‫a un objeto JavaScript normal, ¿verdad?
‫Con todos estos pares clave-valor.
‫Sin embargo, existen algunas diferencias y la más
‫importante es que todas las claves
‫deben ser cadenas.
‫También es muy típico que los valores también sean
‫cadenas, pero pueden ser
‫otras cosas como números, valores verdaderos o
‫falsos, otro objeto o incluso matrices de otros valores.
‫De hecho, es bastante sencillo.
‫Y a partir de este ejemplo, puede ver
‫cómo se vería un JSON típico.
‫Digamos que estos
‫son datos que tenemos en nuestra base de datos para una solicitud
‫GET a esta URL, por lo que el recorrido con I. D. de cinco.
‫Ahora, podríamos devolverlo así al cliente, pero generalmente
‫hacemos un
‫formato de respuesta simple antes de enviarlo.
‫Hay un par de estándares para esto y usaremos uno
‫muy simple llamado Jsend.
‫Simplemente creamos un nuevo objeto, luego
‫le agregamos un mensaje de estado para informar al cliente
‫si la solicitud
‫fue exitosa, fallida o errónea,
‫y luego colocamos nuestros datos originales en
‫un nuevo objeto llamado Datos, ¿de acuerdo?
‫Y podemos desarrollar esto
‫un poco más, pero esta es realmente la forma
‫más sencilla de formatear con Jsend.
‫Y, por cierto, empaquetar los
‫datos en un objeto adicional como lo hicimos
‫aquí se
‫llama Enveloping, y es una práctica común para
‫mitigar algunos problemas de seguridad y otros problemas.
‫Además, existen otros
‫estándares para el formato de respuesta que puede consultar, como Jsend: API
‫o el protocolo Odata JSON.
‫Muy bien, y finalmente, una
‫API RESTful siempre debe ser sin estado.
‫Entonces, ¿qué significa realmente apátrida?
‫Bueno, en una API RESTful sin estado, todo
‫el estado se maneja en
‫el cliente y no en el servidor.
‫Y el estado simplemente se refiere a un dato en la
‫aplicación que puede cambiar con el tiempo.
‫Por ejemplo, si un determinado usuario está conectado
‫o en una página con una lista con
‫varias
‫páginas, cuál es la página actual.
‫Ahora bien, el hecho de que el estado deba manejarse
‫en el cliente significa que
‫cada solicitud debe contener toda la
‫información necesaria para procesar una determinada solicitud en el servidor, ¿de acuerdo?
‫¿Tiene sentido?
‫Por lo tanto, el servidor nunca debería
‫tener que
‫recordar la solicitud anterior para procesar la solicitud actual.
‫Tomemos como ejemplo la lista con varias páginas.
‫Y digamos eso de forma
‫recurrente en la página cinco y queremos pasar a la página seis.
‫Entonces podríamos tener un punto final simple llamado /
‫tours / nextPage y enviarle una solicitud, ¿verdad?
‫Pero el servidor tendría que averiguar cuál es la
‫página actual y, basándose en eso, enviar
‫la página siguiente al cliente.
‫En otras palabras, el servidor debería
‫recordar la solicitud anterior.
‫Tendría que manejar
‫el lado del servidor de estado y eso es exactamente lo
‫que queremos evitar en las API RESTful, ¿de acuerdo?
‫En su lugar, en este caso, deberíamos
‫crear un punto final de / tours /
‫page y pegarle el
‫número seis para solicitar la página número seis.
‫De esta manera, luego indicaríamos en el
‫cliente porque en un cliente, ya sabríamos que estamos
‫en la página cinco, por lo que todo lo
‫que teníamos que
‫hacer es agregar uno y luego solicitar la página número seis.
‫Entonces, el servidor no tiene que recordar
‫nada en este caso.
‫Todo lo que tiene que hacer
‫es enviar los datos de la página número seis como lo solicitamos.
‫Y por cierto, la apatridia y
‫la estatalidad, que es lo contrario, son conceptos
‫muy importantes en la informática y el diseño
‫de aplicaciones en general.
‫Por lo tanto, es una buena idea comprender qué es
‫una API sin estado y cómo funciona.
‫De todos modos, esta fue una gran conferencia,
‫pero también una de las más importantes.
‫No puedo enfatizar eso lo suficiente y de hecho
‫creo que puedes ver eso, ¿verdad?
‫De todos modos, regresemos finalmente a nuestro código.