Générer une API avec Azure Functions
Il est temps de créer une API pour votre application de liste d’achats.
Les fonctions Azure
L’un des principaux avantages d’Azure Static Web Apps est qu’il héberge votre application web et une API créée avec Azure Functions ensemble. Azure Static Web Apps distribue globalement les ressources statiques de votre application web et héberge votre API dans Azure Functions. Avec cette configuration, vous bénéficiez de la disponibilité et de la vitesse propres à une distribution globale de vos ressources d’application web.
Ce que vous n’obtenez pas a également son importance.
Vous n’avez pas besoin d’un serveur complet pour configurer et entretenir votre front-end ou votre back-end. Avec Azure Static Web Apps, vous atteignez le bon endroit : vous bénéficiez de la facilité de publication de votre application et de votre API avec une configuration et une maintenance minimales.
Azure Functions dessert vos points de terminaison de route, ne nécessite pas un serveur back-end complet à configurer et entretenir, et permet un scale-out et un scale-in automatiques en fonction de la demande. Cette fonctionnalité fait d’Azure Functions un partenaire d’API de premier rang pour votre application web de liste d’achats qui dessert les ressources statiques.
Azure Static Web Apps génère une URL unique pour votre site, que vous trouverez sous l’onglet Vue d’ensemble du portail. L’API est disponible via cette même URL en ajoutant /api à l’URL.
API de la liste d’achats
Votre application de liste d’achats permet aux utilisateurs d’obtenir, d’ajouter, de mettre à jour et de supprimer des éléments dans leur liste. Il est donc logique que votre API ait des points de terminaison correspondant à ces besoins.
Voici les quatre points de terminaison que vous créez :
| Méthodes | Points de terminaison de route | Point de terminaison d’API complet |
|---|---|---|
| GET | products |
api/products |
| PUBLIER | products |
api/products |
| PUT | products/:id |
api/products/:id |
| Supprimer | products/:id |
api/products/:id |
Notez que vos requêtes HTTP GET sont acheminées vers api/products. Le préfixe api est réservé à vos points de terminaison d’API dans l’application. Vous pouvez définir d’autres routes éventuelles pour répondre aux besoins de votre site, mais api pointe toujours vers l’application Azure Functions.
Créer une API pour l’application web
Jusqu’à présent, vous avez utilisé un framework front-end. Vous pouvez bientôt ajouter une API et la connecter à votre application frontale. Votre référentiel contient un dossier qui contient un api-starter projet Azure Functions incomplet et des points de terminaison HTTP pour PUT, POST et DELETE de vos produits.
La fonction HTTP GET est manquante dans l’API. Terminez l’API du projet Azure Functions et ajoutez la fonction manquante. Ensuite, connectez votre API à votre application web frontale.
Aperçu des modifications apportées à votre application web
Avant d’apporter des modifications à une application, une bonne pratique consiste à créer une nouvelle branche pour ces modifications. Étant donné que vous apportez plusieurs modifications pour terminer l’API de votre application, vous devez créer une branche pour ces modifications.
Après avoir apporté les modifications, vous souhaiterez les voir en cours d’exécution avant de décider de fusionner les modifications. Une fois que vous avez créé une pull request de votre nouvelle branche vers la branche principale, GitHub Actions génèrent votre application et votre API, et les déploient sur une URL d’aperçu. Cette fonctionnalité vous permet de laisser votre application web s’exécuter avec Azure Static Web Apps, mais également d’afficher une deuxième instance d’aperçu avec les résultats de votre demande de tirage.
Communication entre votre application web et votre API
Lorsque vous exécutez votre API localement avec Azure Functions, elle s’exécute sur le port 7071 par défaut. Votre application web s’exécute sur un autre port local. Lorsque votre application web tente d’effectuer une requête HTTP à partir de son port vers le port 7071 de votre API, la requête est appelée partage de ressources cross-origin (CORS). Votre navigateur empêche la requête HTTP de se terminer à moins que le serveur d’API autorise l’exécution de la requête.
Vous n’avez pas à vous soucier du partage CORS lorsque vous publiez dans Azure Static Web Apps. Azure Static Web Apps configure automatiquement votre application afin qu’elle puisse communiquer avec votre API sur Azure à l’aide d’un proxy inverse. Un proxy inverse permet à votre application web et à l’API de sembler provenir du même domaine web. Par conséquent, vous devez configurer le partage CORS seulement si vous effectuez une exécution locale.
Étapes suivantes
Vous êtes maintenant prêt à créer votre API et à configurer vos points de terminaison HTTP pour votre application de liste d’achats.