Générer une API avec Azure Functions
Il est temps de créer une API pour votre application de liste d’achats.
Azure Functions
L’un des principaux avantages d’Azure Static Web Apps est qu’il héberge votre application web et une API générée avec Azure Functions. 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 de configurer ni de gérer un serveur complet pour votre front-end ou votre back-end. Cette fonctionnalité est le point fort d’Azure Static Web Apps : vous pouvez facilement publier votre application et 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 pouvez trouver dans 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 :
| Méthodes | Points de terminaison de route | Point de terminaison d’API complet |
|---|---|---|
| GET | products |
api/products |
| POST | products |
api/products |
| PUT | products/:id |
api/products/:id |
| DELETE | products/:id |
api/products/:id |
Notez que vos demandes HTTP GET routent 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 allez bientôt ajouter une API et la connecter à votre application front-end. Votre dépôt a un projet Api qui contient un projet Azure Functions incomplet et des points de terminaison HTTP pour les opérations 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, puis connectez votre API à votre application web front-end.
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. Vous apportez plusieurs modifications en complétant l’API pour votre application. Vous devez donc créer une branche pour ces modifications.
Une fois les modifications effectuées, vous voulez les voir s’exécuter avant de décider de fusionner les modifications. Une fois que vous avez créé une demande de tirage de votre nouvelle branche vers la branche main, GitHub Action génère votre application et votre API, puis les déploie sur une URL d’aperçu. Cette URL d’aperçu vous permet de laisser votre application web s’exécuter avec Azure Static Web Apps, mais également d’afficher une deuxième URL avec les résultats issus de votre demande de tirage.
Configurer la communication entre votre application web et l’API
Lorsque vous exécutez votre API localement, elle s’exécute sur le port 7071, par défaut. Votre application web s’exécute sur un autre port local. Quand votre application web tente d’exécuter une requête HTTP à partir de son port vers le port 7071 de votre API, on parle de partage des 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.