Précédent

Suivant

REST et routes de fonction

Effectué

Vous avez créé une formidable API. Elle ne fait pas grand-chose, mais enfin, elle a le mérite d’exister, et tout ceux qui n’ont jamais créé d’API ne peuvent pas en dire autant.

Migration vers des API RESTful

Vous avez des points de terminaison appelés CreateProduct, GetProducts, UpdateProduct et DeleteProduct. Ces points de terminaison suivent le modèle de nommage traditionnel pour les API : Action/Ressource.

Le modèle de nommage Action/Ressource est parfait pour les petites API. Mais n’oubliez pas que dans cette simulation, Tailwind Traders est un géant de l’Internet. L’API Products peut donc très vite échapper à votre contrôle. Par exemple, vous pouvez avoir une méthode appelée « GetProductByIdAndQuantityAndDate ». Non seulement ce type de noms de méthode est long, mais il donne l’impression que le code qui les consomme est encombré. Les noms verbeux compliquent également la tâche des développeurs qui tentent de comprendre comment utiliser l’API dans leurs projets.

Vous devez donc nettoyer cette API et la rendre plus intuitive. Pour cela, vous utilisez le modèle REST.

Routes et méthodes de demande HTTP dans Azure Functions

Par défaut, dans Azure Functions, toute fonction de déclencheur HTTP répond aux requêtes GET et POST. Elle définit également l’URL de votre fonction sur le nom de cette fonction, préfixé de « /api ». Vous allez configurer ces deux éléments pour passer à un modèle RESTful de déplacement.

Applications d’entreprise

La définition HTTP d’une API dans le modèle de programmation Azure Functions v4 dans cet exemple d’application se trouve à ./api/src/index.ts et suit le modèle suivant :

const { app } = require('@azure/functions');

app.http('FunctionName',{
    methods: ['GET', 'POST'], 
    authLevel: 'anonymous', 
    route: 'routeName',
    handler: handlerFunction
});

La fonction de gestionnaire est distincte de la définition du déclencheur HTTP. Cela vous permet beaucoup de flexibilités dans la façon dont vous définissez vos fonctions. Vous pouvez définir la fonction de gestionnaire dans un fichier distinct et l’importer dans le fichier index.ts. Ce format est plus facile à gérer ou à générer pour la documentation OpenAPI ou Swagger.

Applications plus petites

Des applications plus petites peuvent être mieux prises en charge en intégrant le code du gestionnaire directement dans l’appel app, à l’aide de la méthode de l’application pour spécifier la méthode HTTP. Vous pouvez toujours scinder la fonction de gestionnaire ou intégrer le code.

Utilisez la méthode app.get pour spécifier la méthode HTTP et la fonction de gestionnaire.

const { app } = require('@azure/functions');

app.get('FunctionName', handlerFunction);

Un autre format, idéal pour les applications de fonction avec une fonction unique, consiste à intégrer le code du gestionnaire directement dans l’appel app, à l’aide de la méthode de l’application pour spécifier la méthode HTTP. Par exemple :

const { app } = require('@azure/functions');

app.get('helloWorld',{
    handler: (request: HttpRequest, context: InvocationContext) => {
        return {
            status: 200,
            body: "Hello World"
        }
    }
}

Paramètres de routage

Vous pouvez également utiliser des paramètres d’itinéraire pour définir un itinéraire acceptant un paramètre. Par exemple, le code suivant définit un itinéraire acceptant un paramètre name :

route: "products"

La définition de l’itinéraire complet est la suivante :

app.http('GetProducts', {
    methods: ['GET', 'POST'],
    route: 'products',          // <- route: /api/products
    authLevel: 'anonymous',
    handler: GetProducts
});

La spécification d’une route change tout le code qui se trouve après la section api de l’URL. Dans le fichier de configuration précédent, la route vers la fonction GetProducts est maintenant http://localhost:7071/api/products.

Vous pouvez passer des paramètres avec une route. Les paramètres se présentent sous la forme {parameterName}. Cela signifie que pour passer un paramètre appelé id au point de terminaison product, vous devez spécifier la route suivante.

route: "products/{id}"

Fort de ces nouvelles connaissances sur REST et de votre aptitude à l’implémenter dans Azure Functions, vous pouvez à présent transformer cette API Products complexe en une API RESTful. C’est exactement ce que vous allez faire dans le prochain exercice.

Continuer