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 d’un serveur complet pour configurer et entretenir votre front-end ou votre back-end. Avec Azure Static Web Apps, vous trouvez l’équilibre idéal : 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 que vous allez créer :
| 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 requête HTTP GET acheminent 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 pouvoir ajouter une API et la connecter à votre application front-end. Votre référentiel a un dossier api-starter qui contient un projet Azure Functions incomplet et des points de terminaison HTTP pour les méthodes PUT, POST et DELETE de vos produits.
La fonction HTTP GET est manquante dans l’API. Complétez l’API du projet Azure Functions et ajoutez la fonction manquante. Ensuite, 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. Étant donné que vous apportez plusieurs modifications pour compléter l’API pour votre application, vous devriez 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 (pull request) de votre nouvelle branche vers la branche primaire, l’action GitHub génère votre application et votre API, puis les déploie sur une URL d’aperçu. Cette fonctionnalité vous permet de laisser votre application web s’exécuter avec Azure Static Web Apps tout en affichant une deuxième instance préliminaire avec les résultats de votre demande de tirage.
Communication entre l’application web et l’API
Lorsque vous exécutez votre API localement avec Azure Functions, elle s’exécute par défaut sur le port 7071. 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, la requête est appelée « 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.