Partager via


Partie 7 : Point de terminaison de l’API d’application principale

Partie précédente : code de démarrage de l’application principale

Le chemin d’URL de l’application /api/v1/getcode pour l’API génère une réponse JSON qui contient un code alphanumérique et un horodatage.

Tout d’abord, le décorateur @app.route indique à Flask que la fonction get_code gère les requêtes à l’URL /api/v1/getcode.

@app.route('/api/v1/getcode', methods=['GET'])
def get_code():

Ensuite, l’application appelle l’API tierce, dont l’URL se trouve dans number_url, fournissant la clé d’accès qu’elle récupère à partir du coffre de clés dans l’en-tête.

headers = {
    'Content-Type': 'application/json',
    'x-functions-key': access_key
    }

r = requests.get(url = number_url, headers = headers)

if (r.status_code != 200):       
    return "Could not get you a code.", r.status_code

L’exemple d’API tierce est déployé dans l’environnement serverless d’Azure Functions. La propriété x-functions-key dans l’en-tête est la façon dont Azure Functions s’attend à ce qu’une clé d’accès apparaisse dans un en-tête. Pour plus d’informations, consultez Déclencheur HTTP Azure Functions - Clés d’autorisation. Si l’appel de l’API échoue pour une raison quelconque, le code retourne un message d’erreur et le code d’état.

En supposant que l’appel d’API réussit et retourne une valeur numérique, l’application construit ensuite un code plus complexe à l’aide de ce nombre plus de caractères aléatoires (à l’aide de sa propre fonction random_char).

data = r.json()
chars1 = random_char(3)
chars2 = random_char(3)
code_value = f"{chars1}-{data['value']}-{chars2}"
code = { "code": code_value, "timestamp" : str(datetime.utcnow()) }

La variable code contient ici la réponse JSON complète de l’API de l’application, qui inclut la valeur du code et un horodatage. Un exemple de réponse serait {"code":"ojE-161-pTv","timestamp":"2020-04-15 16:54:48.816549"}.

Avant de renvoyer cette réponse, elle écrit toutefois un message dans la file d'attente de stockage à l'aide de la méthode send_message du client de file d'attente :

queue_client.send_message(code)

return jsonify(code)

Traitement des messages de file d’attente

Les messages stockés dans la file d’attente peuvent être affichés et gérés via le portail Azure, avec la commande az storage message get Azure CLI ou l’Explorateur Stockage Azure. L’exemple de référentiel inclut un script (test.cmd et test.sh) pour demander un code à partir du point de terminaison de l’application, puis vérifier la file d’attente des messages. Il existe également un script pour effacer la file d’attente à l’aide de la commande az storage message clear.

En règle générale, une application comme celle de cet exemple aurait un autre processus qui extrait de manière asynchrone les messages de la file d’attente pour un traitement ultérieur. Comme mentionné précédemment, la réponse générée par ce point de terminaison d’API peut être utilisée ailleurs dans l’application avec l’authentification utilisateur à deux facteurs. Dans ce cas, l’application doit invalider le code après une certaine période de temps, par exemple 10 minutes. Une méthode simple pour effectuer cette tâche consiste à conserver une table de codes d’authentification à deux facteurs valides, qui sont utilisés par sa procédure de connexion utilisateur. L’application aurait ensuite un processus de surveillance de file d’attente simple avec la logique suivante (en pseudo-code) :

pull a message from the queue and retrieve the code.

if (code is already in the table):
    remove the code from the table, thereby invalidating it
else:
    add the code to the table, making it valid
    call queue_client.send_message(code, visibility_timeout=600)

Ce pseudo-code utilise le paramètre send_message facultatif de la méthode visibility_timeout, qui spécifie le nombre de secondes avant que le message ne soit visible dans la file d’attente. Étant donné que le délai d’expiration par défaut est égal à zéro, les messages initialement écrits par le point de terminaison d’API deviennent immédiatement visibles dans le processus de surveillance de la file d’attente. Par conséquent, ce processus les stocke immédiatement dans la table de code valide. Le processus met à nouveau le même message en file d'attente, accompagné du délai d'expiration, pour qu'il reçoive le code à nouveau 10 minutes plus tard, moment où il est supprimé de la table.

Implémentation du point de terminaison d’API d’application principal dans Azure Functions

Le code présenté précédemment dans cet article utilise l’infrastructure web Flask pour créer son point de terminaison d’API. Étant donné que Flask doit s’exécuter avec un serveur web, ce code doit être déployé sur Azure App Service ou sur une machine virtuelle.

Une autre option de déploiement est l’environnement serverless d’Azure Functions. Dans ce cas, tout le code de démarrage et le code de point de terminaison de l’API sont contenus dans la même fonction liée à un déclencheur HTTP. Comme avec App Service, vous utilisez paramètres d’application de fonction pour créer des variables d’environnement pour votre code.

Une partie de l’implémentation qui devient plus facile est de s'authentifier avec le stockage de files d'attente. Au lieu d’obtenir un objet QueueClient à l’aide de l’URL de la file d’attente et d’un objet d’informations d’identification, vous créez une liaison de stockage de file d’attente pour la fonction. La liaison gère toute l’authentification en arrière-plan. Avec une telle liaison, votre fonction reçoit un objet client prêt à l’emploi en tant que paramètre. Pour obtenir plus d’informations et un exemple de code, consultez Connecter Azure Functions à Stockage File d’attente Azure.

Étapes suivantes

Dans ce tutoriel, vous avez appris comment les applications s’authentifient auprès d’autres services Azure à l’aide d’une identité managée et comment les applications peuvent utiliser Azure Key Vault pour stocker les autres secrets nécessaires pour les API tierces.

Le même modèle illustré ici avec Azure Key Vault et stockage Azure s’applique à tous les autres services Azure. L’étape cruciale consiste à attribuer le rôle approprié pour l’application dans la page de ce service sur le portail Azure ou via Azure CLI. (Consultez Comment affecter des rôles Azure). Veillez à consulter la documentation du service pour savoir si vous devez configurer d’autres stratégies d’accès.

N’oubliez pas que vous devez attribuer les mêmes rôles et stratégies d’accès à n’importe quel principal de service que vous utilisez pour le développement local.

En bref, après avoir effectué cette procédure pas à pas, vous pouvez appliquer vos connaissances à n’importe quel nombre d’autres services Azure et à n’importe quel nombre d’autres services externes.

L’un des sujets que nous n’avons pas abordés dans ce tutoriel est l’authentification de utilisateurs. Pour explorer ce domaine pour les applications web, commencez par authentifier et autoriser des utilisateurs de bout en bout dans Azure App Service.

Voir aussi