‫Instructeur : Maintenant que nous savons ce qu'est
‫Express, nous sommes presque prêts à commencer à créer notre API.
‫Mais avant de
‫faire cela, je dois parler rapidement des API à
‫un niveau supérieur et,
‫plus important encore, vous présenter l'architecture
‫REST, qui est l'architecture d'API la plus utilisée aujourd'hui.
‫De cette façon, nous saurons réellement ce que nous construisons.
‫Il est donc extrêmement important de comprendre le
‫contenu de cette vidéo avant de poursuivre,
‫afin que nous sachions réellement ce que nous construisons
‫tout au long du cours.
‫Tout d'abord,
‫API signifie Application Programming Interface et à un niveau
‫très élevé, il s'agit
‫essentiellement d'un logiciel qui peut être utilisé par
‫un autre logiciel afin de
‫permettre aux applications de communiquer entre elles.
‫Nous avons en fait déjà parlé
‫des API, plus précisément des API Web,
‫où nous avons simplement créé une application qui
‫envoie des données à un client chaque fois qu'une demande arrive.
‫Imaginez que notre application fonctionne sur un serveur et que
‫nous ayons un client.
‫Donc, en fait, nous avons effectivement deux logiciels qui
‫se parlent, n'est-ce pas ?
‫Et c'est le genre d'API que nous allons construire dans ce cours.
‫Et je suppose que c'est le type d'API le plus largement utilisé.
‫Mais en fait, les API ne sont pas seulement utilisées pour envoyer des données et
‫ne sont pas toujours liées au développement Web ou à JavaScript.
‫L'application dans l'API peut en fait signifier
‫beaucoup de choses différentes tant que le
‫logiciel est relativement autonome.
‫Prenez, par
‫exemple, le système de fichiers de nœuds ou les modules HTTP.
‫Nous pouvons dire que ce sont de petits logiciels
‫et nous pouvons
‫les utiliser, nous pouvons interagir avec eux en utilisant leur API.
‫Par
‫exemple, lorsque nous utilisons la fonction readfile du module
‫FS, nous utilisons en fait l'API FS.
‫Et c'est pourquoi vous entendrez parfois le terme d'API de nœuds.
‫Et cela fait généralement simplement référence aux modules de nœud de base
‫avec lesquels nous pouvons interagir.
‫Ou lorsque nous faisons de la manipulation DOM
‫dans le navigateur, nous n'utilisons pas vraiment le langage
‫JavaScript lui-même, mais plutôt l'API DOM que le navigateur nous expose, donc
‫il nous y donne accès.
‫Ou même un autre exemple,
‫disons que nous créons une classe dans n'importe quel langage
‫de programmation comme Java, puis y ajoutons des méthodes
‫ou des propriétés publiques.
‫Ces méthodes seront alors l'API de chaque objet
‫créé à partir de cette classe
‫car nous donnons à d'autres logiciels
‫la possibilité d'interagir avec notre logiciel initial, les objets,
‫dans ce cas.
‫Vous voyez, l'API a en fait un sens plus large que
‫la simple création d'API Web.
‫Bien? Quoi qu'il en soit, une API Web est ce
‫qui est le plus important pour nous dans le contexte de la note.
‫Jetons maintenant un coup d'œil à l'architecture REST pour
‫créer des API.
‫REST, qui signifie Representational States Transfer, est essentiellement un moyen de
‫créer des API Web de manière logique, ce qui les
‫rend faciles à utiliser,
‫car rappelez-vous, nous créons une API pour nous-mêmes
‫ou pour d'autres à consommer, d'accord ?
‫Nous voulons rendre le processus d'utilisation de l'API aussi fluide
‫que possible pour l'utilisateur.
‫Maintenant, pour créer des API
‫RESTful, c'est-à-dire des API suivant l'architecture REST, il
‫nous suffit de suivre quelques principes.
‫Tout d'abord, nous devons séparer notre API en ressources logiques.
‫Ces ressources doivent ensuite être exposées, ce
‫qui signifie être rendues
‫disponibles à l'aide d'URL structurées et basées sur les ressources.
‫Pour effectuer différentes actions sur
‫des données telles que la lecture ou la création
‫ou la suppression de données, l'API doit utiliser les bonnes méthodes HTP et non l'URL.
‫Désormais, les données que nous renvoyons réellement au
‫client ou que nous avons
‫reçues du client doivent généralement utiliser le format
‫de données JSON, auquel une norme de formatage s'applique.
‫Enfin, un autre principe important des API REST
‫est qu'elles doivent être sans état.
‫C'est donc une vue d'ensemble très large.
‫Commençons maintenant à parler de ces principes
‫un par un en commençant par les ressources et en utilisant
‫l'API Nators que nous allons construire dans ce
‫cours à titre d'exemple ici.
‫L'abstraction clé des informations dans REST est une ressource, et
‫donc toutes les données que
‫nous voulons partager dans l'API doivent être divisées en ressources logiques.
‫Maintenant, qu'est-ce qu'une ressource ?
‫Eh bien, dans le contexte
‫de REST, c'est un objet ou une représentation de
‫quelque chose auquel des données sont associées.
‫Par exemple,
‫des visites, ou des utilisateurs, ou des avis dans
‫le cas de l'exemple que nous suivons.
‫Donc, fondamentalement, toute information pouvant être nommée peut
‫être une ressource, d'accord ?
‫Il doit juste être un nom, cependant, pas un verbe.
‫Maintenant, nous devons
‫exposer, c'est-à-dire rendre disponibles,
‫les données en utilisant des URL structurées auxquelles
‫le client peut envoyer une requête.
‫Par exemple, quelque chose comme ça.
‫Cette adresse entière est appelée l'URL et
‫ce /addNewTour est appelé un point de terminaison d'API.
‫Notre API aura de nombreux points de terminaison
‫différents, tout comme ces points de terminaison fictifs
‫que j'ai ici, dont chacun renverra des données différentes au
‫client ou effectuera également différentes actions.
‫Maintenant, il y a en fait quelque
‫chose qui ne va pas avec ces points de terminaison ici, car
‫ils ne suivent vraiment pas la troisième règle qui dit que
‫nous ne devons utiliser les méthodes HTTP que pour effectuer des actions sur les données.
‫Ainsi, les endpoints ne doivent contenir que nos ressources et
‫non les actions qui peuvent être effectuées
‫sur eux car ils deviendront rapidement un cauchemar à maintenir.
‫Comment devrions-nous utiliser ces méthodes HTTP en pratique ?
‫Eh bien, voyons à quoi
‫devraient ressembler ces points de terminaison en commençant par /getTour.
‫Donc, ce point de terminaison /getTour sert à obtenir des données sur une visite.
‫Et donc nous devons simplement nommer le point de terminaison /tours et
‫envoyer les données chaque fois qu'une demande d'obtention est
‫faite à ce point de terminaison.
‫Donc, en d'autres
‫termes, lorsqu'un client utilise une méthode GET HTTP pour
‫accéder au point de terminaison.
‫Et juste comme
‫ça, nous n'avons que des ressources dans le
‫point de terminaison ou dans l'URL et pas de verbes car le
‫verbe est maintenant dans la méthode HTTP, n'est-ce pas ?
‫Et au
‫fait, c'est une pratique courante de toujours utiliser le
‫nom de la ressource au pluriel, c'est pourquoi j'ai /tours ici et non /tour.
‫Maintenant, la convention est que lors de l'appel de ce point
‫de terminaison, nous récupérons toutes les visites qui se trouvent dans une base de données, d'accord ?
‫Mais si nous voulons seulement la tournée avec un seul I. RÉ. disons sept, nous ajoutons
‫que sept après une autre barre oblique ou dans une requête de recherche.
‫Ou cela pourrait aussi être le nom d'une tournée au lieu du I. RÉ. ou un autre identifiant unique.
‫Les détails n'ont pas vraiment d'importance à ce stade, d'accord ?
‫Plus tard, je vous montrerai à
‫quel point il est facile d'implémenter ce type de logique
‫avec Express, car c'est en fait là qu'Express brille vraiment.
‫La première méthode ou verbe
‫HTTP auquel nous pouvons répondre est GET et est utilisé
‫pour effectuer l'opération de lecture sur les données.
‫Prochain arrêt, si le client
‫souhaite créer une nouvelle ressource dans notre base de données,
‫dans cet exemple, une
‫nouvelle tournée, la méthode POST doit être utilisée.
‫Nous avons donc appris plus tôt qu'une
‫requête POST peut être utilisée pour envoyer des données
‫au serveur, et il est donc logique d'utiliser POST afin de créer
‫de nouvelles ressources, n'est-ce pas ?
‫Maintenant, dans ce cas, généralement pas de I. RÉ. sera envoyé car
‫le serveur devrait automatiquement trouver le
‫I. RÉ. pour la nouvelle ressource.
‫Quoi qu'il en soit, ce qui est vraiment important à noter ici, c'est que le nom du point de terminaison est
‫exactement le même nom qu'avant.
‫La seule différence est vraiment
‫la méthode HTP utilisée pour la requête.
‫Si le point de terminaison /tours est accessible avec GET, nous
‫envoyons des données au client.
‫Mais si le même point de terminaison est accessible avec POST, nous
‫nous attendons à ce que
‫les données arrivent avec une demande, afin que nous
‫puissions ensuite créer une nouvelle ressource côté serveur.
‫C'est donc vraiment la beauté de n'utiliser que des méthodes HTTP plutôt que de jouer
‫avec les verbes dans les noms de points de terminaison.
‫Encore une fois, cela deviendrait vraiment ingérable très rapidement.
‫D'accord, ensuite, il devrait également y
‫avoir la possibilité de mettre à jour les ressources.
‫Et pour cela, une demande PUT
‫ou PATCH doit être faite au point
‫de terminaison.
‫La différence entre eux est qu'avec PUT,
‫le client est censé envoyer l'intégralité
‫de l'objet mis à jour, tandis qu'avec
‫PATCH, il est censé envoyer uniquement la partie de l'objet qui
‫a été modifiée.
‫Mais les deux ont la possibilité d'envoyer
‫des données au serveur.
‫Un peu comme POST, en fait, mais avec une intention différente.
‫Donc POST consiste à
‫créer une nouvelle ressource, tandis que PUT ou PATCH sont utilisés pour
‫mettre à jour une ressource existante et
‫donc cela fait alors toute la différence.
‫Et enfin, à la ressource litière,
‫il y a la méthode HTTP DELETE.
‫Encore une fois, le I. RÉ. ou un autre identifiant unique de
‫la ressource à supprimer doit faire partie de
‫l'URL.
‫Or, généralement, pour pouvoir réellement
‫effectuer ce type
‫de requête, le client doit être authentifié.
‫Donc en gros, connectez-vous à votre application, d'accord ?
‫Mais c'est, bien sûr, un sujet pour beaucoup plus tard.
‫Ce sont donc les cinq méthodes HTTP auxquelles
‫nous pouvons et devons répondre lors de
‫la création de nos API RESTful afin
‫que le client puisse effectuer
‫les quatre opérations CRUD de base.
‫CRUD signifie donc créer, lire, mettre à jour et supprimer.
‫Et vous verrez ce terme tout
‫le temps lié aux API et aux bases de données.
‫Et vous voyez que ces méthodes
‫HTTP correspondent assez bien aux opérations CRUD de base.
‫Maintenant, il peut y avoir des
‫actions qui ne sont pas CRUD, et dans ce cas, nous
‫devons juste faire preuve de créativité avec nos entrées.
‫Par exemple, une connexion
‫ou une opération de recherche, celles-ci ne sont pas vraiment liées
‫à une ressource
‫particulière et ce ne sont pas non plus
‫des opérations CRUD, mais nous pouvons toujours créer des points de terminaison pour elles.
‫Par exemple, comme /login ou /search.
‫Mais nous parlerons davantage de ces cas plus tard dans la pratique.
‫Et juste pour terminer cette partie maintenant, rappelez-vous que nous
‫avions deux autres noms de points de terminaison fous dans la dernière
‫diapositive qui impliquaient en quelque
‫sorte deux ressources en même temps, n'est-ce pas ?
‫Et ce n'est pas non plus un problème avec REST.
‫Ainsi, /getToursByUser peut
‫simplement être traduit en /users/tours,
‫dans ce cas, l'utilisateur numéro trois.
‫Ainsi, ce point de terminaison particulier ici pourrait
‫envoyer des données sur toutes les visites que
‫l'utilisateur numéro trois a réservées.
‫Logique?
‫Ou dans le cas d'une suppression, il pourrait y avoir
‫une demande de
‫suppression au même point de terminaison ou à un
‫point de terminaison très similaire, demandant à la tournée numéro neuf d'être
‫supprimée de l'utilisateur numéro trois, d'accord ?
‫Il y a donc vraiment des tonnes
‫de possibilités de combiner des ressources comme celle-ci.
‫Mais bien sûr, nous n'avons pas à implémenter
‫toutes ces combinaisons dans notre API.
‫Nous implémentons uniquement ce qui a
‫du sens dans le cas de notre application et
‫du client qui souhaite consommer notre API.
‫C'est ainsi que nous
‫utilisons les méthodes HTTP pour créer des URL
‫conviviales et bien structurées, faciles et logiques à utiliser pour le client.
‫Maintenant, à propos des données que le client reçoit
‫réellement ou que le serveur reçoit du
‫client, nous utilisons généralement le format de données JSON.
‫Et apprenons donc brièvement ce qu'est réellement JSON
‫et comment formater nos réponses API.
‫JSON est un format d'échange de données très
‫léger qui est largement utilisé
‫par les API Web codées dans n'importe quel langage de programmation.
‫Donc, ce n'est tout simplement pas lié à un JavaScript.
‫Et il est si largement utilisé aujourd'hui
‫parce qu'il est vraiment facile pour les humains et les
‫ordinateurs de comprendre et d'écrire JSON.
‫Vous avez donc probablement déjà remarqué que JSON ressemble un peu à
‫un objet JavaScript normal, n'est-ce pas ?
‫Avec toutes ces paires clé-valeur.
‫Il existe cependant quelques différences, et la plus importante
‫est que toutes les clés doivent
‫être des chaînes.
‫Il est également très courant que les valeurs soient également des
‫chaînes, mais il peut s'agir d'autres
‫éléments tels que des nombres, des valeurs vraies
‫ou fausses, un autre objet ou même des tableaux d'autres valeurs.
‫C'est assez simple, en fait.
‫Et à partir de cet exemple, vous pouvez en quelque
‫sorte voir à quoi pourrait ressembler un JSON typique.
‫Disons qu'il s'agit
‫d'une donnée que nous avons dans notre base de données pour une
‫requête GET vers cette URL donc la tournée avec I. RÉ. des cinq.
‫Maintenant, nous pourrions le renvoyer comme ceci au client, mais
‫nous effectuons
‫généralement un formatage de réponse simple avant de l'envoyer.
‫Il existe quelques normes pour cela et nous allons en utiliser
‫une très simple appelée Jsend.
‫Nous créons simplement un nouvel objet, puis
‫y ajoutons un message d'état afin d'informer le client si la
‫demande a été un
‫succès, un échec ou une
‫erreur, puis nous mettons nos données d'origine
‫dans un nouvel objet appelé Data, d'accord ?
‫Et nous pouvons développer cela
‫encore un peu plus loin, mais c'est vraiment le moyen
‫le plus simple de formater avec Jsend.
‫Et, soit dit en passant,
‫envelopper les données dans un objet supplémentaire comme
‫nous l'avons
‫fait ici s'appelle Envelopper, et c'est une pratique courante
‫pour atténuer certains problèmes de sécurité et d'autres problèmes.
‫En outre, il existe
‫d'autres normes de formatage des réponses que vous pouvez examiner, telles que Jsend:API
‫ou le protocole Odata JSON.
‫D'accord, et enfin, une
‫API RESTful doit toujours être sans état.
‫Alors, que signifie réellement apatride ?
‫Eh bien, dans une API RESTful sans état, tous
‫les états sont gérés sur
‫le client et non sur le serveur.
‫Et l'état fait simplement référence à un élément de données dans l'application
‫qui peut changer au fil du temps.
‫Par exemple, si un certain utilisateur est connecté
‫ou sur une page avec une liste de
‫plusieurs
‫pages, quelle est la page actuelle.
‫Maintenant, le fait que l'état doit être géré sur le
‫client signifie que chaque
‫requête doit contenir toutes les informations
‫nécessaires pour traiter une certaine requête sur le serveur, d'accord ?
‫Cela a-t-il du sens?
‫Ainsi, le serveur ne devrait jamais avoir
‫à se souvenir
‫de la requête précédente pour traiter la requête en cours.
‫Prenons comme exemple la liste de plusieurs pages.
‫Et disons que de manière récurrente
‫à la page cinq et que vous souhaitez passer à la page six.
‫Nous pourrions donc avoir un point de terminaison simple appelé
‫/tours/nextPage et lui soumettre une demande, n'est-ce pas ?
‫Mais le serveur devrait alors déterminer quelle est la page
‫actuelle et, en fonction de cela, envoyer
‫la page suivante au client.
‫En d'autres termes, le serveur devrait se
‫souvenir de la requête précédente.
‫Il devrait gérer
‫le côté serveur d'état et c'est exactement ce que nous
‫voulons éviter dans les API RESTful, d'accord ?
‫Au lieu de cela, dans ce cas,
‫nous devons créer un point de terminaison /tours/page
‫et y coller le
‫numéro six afin de demander la page numéro six.
‫De cette façon, nous indiquerions ensuite sur
‫le client car sur un client, nous saurions déjà que
‫nous sommes à la page cinq et donc tout ce que
‫nous avions à faire
‫était d'en ajouter un et ensuite de demander la page numéro six.
‫Le serveur n'a donc rien à
‫retenir dans ce cas.
‫Tout ce qu'il a à faire est
‫de renvoyer les données pour la page numéro six comme nous l'avons demandé.
‫Et au fait, l'apatridie et
‫l'état d'état, qui est le contraire, sont
‫des concepts très importants en informatique et en
‫conception d'applications en général.
‫C'est donc une bonne idée de comprendre ce qu'est une
‫API sans état et comment elle fonctionne.
‫Quoi qu'il en soit, ce fut une conférence
‫énorme, mais aussi l'une des plus importantes.
‫Je ne saurais trop insister là-dessus et je pense en fait
‫que vous pouvez le voir, n'est-ce pas ?
‫Quoi qu'il en soit, revenons enfin à notre code.