Module 4 : Comprendre et

utiliser les API

Contenu Pédagogique d l'instructeur

DevNet Associate v1.0

Contenu pédagogique de l'instructeur - Guide de planification du
module 4
Cette présentation PowerPoint est divisée en deux parties :
• Guide de planification de l'enseignant
• Informations pour vous aider à vous familiariser avec le module
• Outils pédagogiques
• Présentation en classe pour l'instructeur
• Diapositives facultatives que vous pouvez utiliser en classe
• Commence à la diapositive 11
Remarque : supprimez le guide de planification de cette présentation avant de la partager.
Pour obtenir de l'aide et des ressources supplémentaires, consultez la page d'accueil de
l'instructeur et les ressources du cours pour ce cours. Vous pouvez également visiter le
site de développement professionnel sur [Link], la page Facebook officielle
de Cisco Networking Academy ou le groupe FB Instructor Only.
© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 2
À quoi s'attendre dans ce module
Pour faciliter l'apprentissage, les caractéristiques suivantes peuvent être incluses dans ce module :

Fonctionnalité Description
Travaux Pratiques Travaux Pratiques conçus pour travailler avec des équipements physiques.
Questionnaires sur le Des évaluations automatiques qui intègrent les concepts et les compétences
module acquises tout au long de la série de rubriques présentées dans le module.
Résumé du module Récapte brièvement le contenu du module.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 3
Vérifiez vos connaissances

• Les activités Vérifiez votre compréhension sont conçues pour permettre aux élèves de
déterminer rapidement s'ils comprennent le contenu et s'ils peuvent poursuivre ou s'ils ont
besoin de revoir.
• Les exercices du module Vérifiez votre compréhension ne sont pas comptés dans la note
finale des candidats.
• Il n'existe aucune diapositive distincte pour ces exercices dans le fichier PPT. Ils sont
répertoriés dans les notes de la diapositive qui apparaissent avant ces exercices.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 4
Module 4 : Activités
Quelles sont les activités associées à ce module?

N° de page Type d'exercice Nom de l'exercice Facultatif ?

Recommandati
4.5.5 Travaux pratiques Explorez les API REST avec le simulateur d'API et le facteur
on
Recommandati
4.9.2 Travaux pratiques Intégration d'une API REST avec Python
on

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 5
Module 4 : Meilleures pratiques
Avant d'enseigner le module 4, l'instructeur doit:
• Passez en revue les activités et les évaluations de ce module.
• Essayez d'inclure autant de questions que possible pour maintenir l'intérêt des élèves
pendant la présentation en classe.

Rubrique 4.1
• Définir l'interface de programmation d'application (API).
• Demandez à la classe quel est le but d'utiliser une API?

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 6
Module 4 : Meilleures pratiques (suite)
Rubrique 4.2
• Discutez la différence entre les API asynchrones et synchrones. Demandez aux élèves de
fournir des exemples d'API asynchrones et synchrones et d'avoir une discussion à ce sujet.
• Discutez les avantages des API asynchrones et synchrones.

Rubrique 4.3
• Discutez les styles architecturaux d'API : RPC, SOAP et REST.
• Fournissez des exemples de RPC, SOAP et REST à la classe. Demandez-leur de
réfléchir sur les exemples et d'identifier le style architectural approprié.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 7
Module 4 : Meilleures pratiques (suite)
Rubrique 4.4
• Expliquez les six principes du style architectural REST : client-serveur, sans état, cache,
interface uniforme, système en couches, code à la demande.
• Discutez les quatre principaux composants des requêtes d'API REST : Uniform Resource
Identifier, HTTP Méthode, Header, body.
• Fournissez une URL et demandez aux étudiants de catégoriser le schéma, l'autorité, le
chemin d'accès et la requête.
• Demandez à la classe si elle est au courant des erreurs HTTP courantes. Discutez les
codes d'état HTTP courants.
• Demandez aux élèves de rechercher les différents exemples de codes d'état et de les
partager avec la classe en effectuant les erreurs sur l'ordinateur.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 8
Module 4 : Meilleures pratiques (suite)
Rubrique 4.5
• Introduisez l'authentification et l'autorisation avec différents scénarios.
• Discutez les mécanismes d'authentification
• Expliquez le terme 'flux (flow)' dans les versions d'autorisation.

Rubrique 4.6
• Fournir un aperçu du ‘Rate limit’.
• Expliquez les modèles d'algorithme de limite de taux avec des exemples
• Discutez les causes du dépassement de la limite tarifaire.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 9
Module 4 : Meilleures pratiques (suite)
Rubrique 4.7
• Familiariser les apprenants avec Webhook.
• Expliquez comment Webhook aide à recevoir des notifications.

Rubrique 4.8
• Différenciez entre l'erreur côté client et l'erreur côté serveur ainsi que ses causes
profondes et ses résolutions.
• Liste les codes d'état 2xx, 4xx et 5xx ainsi que ses catégories.
• Fournir des exemples de codes d'état aux élèves et leur demander d'identifier les erreurs
et de fournir des solutions.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 10
Module 4 : Comprendre et
utiliser les API

DevNet Associate v1.0

Objectifs du module
Titre du module : Comprendre et utiliser les API

Objectif du module : Créer des requêtes API REST sur HTTPS pour intégrer des services de manière
sécurisée.
Titre du Rubrique Objectif du Rubrique
Introduction des API Expliquer l'utilisation des API.
Styles de conception de l'API Comparer les styles de conception des API synchrones et asynchrones.
Styles d'architecture API Décrire les styles d'architecture des API courantes.
Introduction aux API REST Expliquer les fonctions des API REST.
Créer des demandes d'API REST via HTTPS pour intégrer les services en
Authentification d'une API REST
toute sécurité.
API limitation de débit (Rate limits) Expliquer l'objectif des limites de débit API
Travailler avec Webhooks Expliquer l'utilisation des webhooks.
Dépannage des appels API Expliquer comment dépanner les API REST

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 12
4.1 Présentation des API

© 2016 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 13
Comprendre et utiliser les API
Qu'est-ce qu'une API ?
• Une interface de programmation
d'application (API)permet à un
logiciel de parler à un autre.
Exemple de différents types d'intégrations d'API
• Il utilise des interactions ou des
protocoles de communication
Web communs et ses propres
normes propriétaires.
• Une API détermine le type de
données, de services et de
fonctionnalités que l'application
expose à des tiers.
• En fournissant des API, les
applications peuvent contrôler ce
qu'elles exposent de manière © 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
sécurisée. confidentielles de Cisco 14
Comprendre et utiliser les API
Pourquoi utiliser les API ?
• Les API sont conçues pour être consommées par programmation par d'autres applications
et peuvent également être utilisées par des humains qui veulent interagir avec l'application
manuellement.
Les cas d'utilisation des API sont les suivants :
• Tâches d'automatisation : créez un script qui exécute des tâches manuelles
automatiquement et par programme.
• Intégration de données — Une application peut consommer des données fournies par
une autre application ou y réagir.
• Fonctionnalité — Une application peut intégrer les fonctionnalités d'une autre application
dans son produit.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 15
Comprendre et utiliser les API
Pourquoi les API sont-elles si populaires ?
• Les API existent depuis des décennies, mais l'exposition et la consommation des API ont
augmenté de façon exponentielle au cours des dix dernières années environ.
• La plupart des API modernes sont conçues dans le produit et sont soigneusement testées.

• Des langages de codage simplifiés tels que Python ont permis aux ingénieurs non logiciels
de créer des applications et de consommer des API.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 16
4.2 Les styles de conception
des API

© 2016 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 17
Styles de conception des API
Types de styles de conception
• L'ensemble d'API d'un produit peut consister à la fois en conceptions synchrones et
asynchrones, où la conception de chaque API est indépendante des autres.
• L'application qui utilise l'API gère la réponse différemment en fonction de la conception
de l'API.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 18
Styles de conception des API
API synchrones
• Les API synchrones répondent directement à une
API synchrones
demande en fournissant des données
immédiatement.
Quand les API sont-elles synchrones ?
• Les API sont synchrones lorsque les données de
la requête sont facilement disponibles.
Avantages d'une conception d'API synchrone
• Les API synchrones permettent à l'application de
recevoir des données immédiatement. Si l'API est
conçue correctement, les performances de
l'application seront meilleures.
Traitement côté client Les billets sont vendus en ordre premier
• L'application qui effectue la demande d'API doit arrivé, premier servi. C'est un processus
attendre la réponse avant d'effectuer des tâches synchrone.
supplémentaires d'exécution de code. © 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 19
Styles de conception des API
API Asynchrones
• Les API asynchrones fournissent une réponse (sans
données) indiquant que la demande a été reçue.
Quand les API sont-elles asynchrones ?
• Les API sont asynchrones lorsque la requête prend un
API synchrones
certain temps pour le serveur ou si les données ne sont
pas facilement disponibles.
Avantage de la conception d'API asynchrone
• Les API asynchrones permettent à l'application de
continuer l'exécution sans être bloquée jusqu'à ce que
le serveur traite la requête, ce qui améliore les
performances.
Traitement côté client
• Avec le traitement asynchrone, la conception de l'API
côté serveur définit l'exigence du côté client.
© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 20
4.3 Styles architecturaux
des API

© 2016 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 21
Styles architecturaux API
Styles architecturaux communs
• Il existe certains standards, protocoles et styles architecturaux spécifiques qui facilitent
l'apprentissage et la compréhension de l'API par les utilisateurs de l'API.
• Les trois types les plus populaires de styles architecturaux API sont :

• RPC

• SOAP

• REST

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 22
Styles architecturaux API
Appel de procédure à distance (RPC)
• Remote Procedure Call (RPC) est un modèle
requête-réponse qui permet à une application Procédure distante Appeler modèle de
d'effectuer un appel de procédure à une autre requête/réponse client-serveur
application.

• Lorsque RPC est appelé à un client, la méthode

est exécutée et les résultats sont renvoyés.

• RPC est un style d'API qui peut être appliqué à

différents protocoles de transport tels que :
• XML-RPC
• JSON-RPC
• NFS (Network File System)
• Protocole d'accès aux objets simples (SOAP)

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 23
Styles architecturaux API
Protocole SOAP (Simple Object Access Protocol)
• Le protocole SOAP (Simple Object Access Protocol) est un protocole de messagerie basé sur XML. Il est
utilisé pour la communication entre des applications sur différentes plates-formes ou construit avec différents
langages de programmation.

SOAP est :
• Indépendante (Independent) : toutes les applications peuvent communiquer entre elles et fonctionner sur
différents systèmes d'exploitation
• Extensible : ajoutez des fonctionnalités telles que la fiabilité et la sécurité
• Neutre (Neutral) : Peut être utilisé sur n'importe quel protocole, y compris HTTP, SMTP, TCP, UDP ou JMS
Un message SOAP est un document XML qui peut contenir les quatre éléments suivants :
• Enveloppe (Envelope) : élément racine du document XML.
• En-tête (Header) - contient des informations spécifiques à l'application telles que l'autorisation, les attributs
spécifiques à SOAP, etc.
• Corps (Body) - contient les données à transporter vers le destinataire
• Faute (Fault) - fournit des informations d'erreur et/ou d'état.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 24
Styles architecturaux API
Protocole SOAP (Simple Object Access Protocol) (suite)
• La capture d'écran suivante est un exemple de message SOAP :

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 25
Styles architecturaux API
Transfert d'état de représentation (REST)
• Representational State Transfer (REST) est un style architectural rédigé par Roy
Thomas Fielding.
• Roy a établi six contraintes qui peuvent être appliquées à n'importe quel protocole
dans REST.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 26
Styles architecturaux API
Transfert d'état de représentation (REST)
client-serveur
Modèle client-serveur REST
• Le client et le serveur doivent être
indépendants les uns des autres.
• Cela permettra au client d'être construit pour
plusieurs plates-formes, ce qui simplifiera les
composants côté serveur.

Statique Modèle sans état REST

• Les demandes du client au serveur doivent

contenir le modèle client-serveur REST et
toutes les informations dont le serveur a
besoin pour effectuer la demande.
• Le serveur ne peut pas contenir d'états de
session. © 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 27
Styles architecturaux API
Transfert d'état de représentation (REST)
Modèle de cache :
Modèle de cache REST
• Les réponses du serveur doivent indiquer si la réponse
est mise en cache ou non en cache.

• S'il est possible de mettre en cache, le client peut utiliser

les données de la réponse pour les demandes
ultérieures.
Interface uniforme :

L'interface entre le client et le serveur respecte les quatre

principes suivants :
• Identification des ressources
• Manipulation des ressources par des représentations
• Messages auto-descriptifs
• Hypermedia comme moteur de l'état de l'application.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 28
Styles architecturaux API
Transfert d'état de représentation (REST)
Système en couches :
Modèle de système en couches REST
• Le système Layered se compose de
différentes couches hiérarchiques dans
lesquelles chaque couche fournit des
services uniquement à la couche au-
dessus.
• Par conséquent, il consomme les
services de la couche ci-dessous.
Code à la demande :
• Les informations renvoyées par un service REST peuvent inclure du code exécutable
(par exemple, javascript) ou des liens destinés à étendre utilement les fonctionnalités du
client.
• La contrainte est facultative car l'exécution de codes tiers présente des risques de
sécurité potentiels. © 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 29
4.4 Introduction aux API REST

© 2016 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 30
Introduction aux API REST
API du service web REST
• Une API de service Web REST (REST
API) est une interface de
programmation qui communique via
HTTP. Modèle de requête/réponse API REST (REST API
request/response model)
• Les API REST utilisent les mêmes
concepts que le protocole HTTP qui
sont les suivants :
• Requêtes/réponses HTTP (HTTP
requests/responses)
• Verbes HTTP (HTTP verbs)

• Codes d'état HTTP (HTTP status

codes)

• Entêtes/corps HTTP (HTTP

headers/body) © 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 31
Introduction aux API REST
Requêtes API REST
• Les requêtes d'API REST sont des requêtes HTTP qui permettent à une application (client)
de demander au serveur d'exécuter une fonction.
• Les requêtes d'API REST sont composées de quatre composants principaux :

• Identificateur de ressources uniformes (URI)

• Méthode HTTP

• En-tête

• Corps

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 32
Introduction aux API REST
Requêtes API REST (suite)
L'URI (Uniform Resource Identifier), également appelé Uniform Resource Locator (URL),
identifie la ressource que le client souhaite manipuler. Les composants d'un URI sont :
• Schéma (Scheme): spécifie quel protocole HTTP doit être utilisé, http ou https.

• Autorité (Authority): se compose de deux parties, à savoir l'hôte et le port.

• Chemin d'accès (Path): représente l'emplacement de la ressource, des données ou de

l'objet, à manipuler sur le serveur.
• Requête (Query): fournit des détails supplémentaires sur la portée, le filtrage ou la
clarification d'une demande.

Différents composants d'un URI

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 33
Introduction aux API REST
Requêtes API REST (suite)
Méthode HTTP:
• Les API REST utilisent les méthodes HTTP standard pour communiquer avec les services
Web pour lesquels une action est demandée pour la ressource donnée.
• Le mappage suggéré de la méthode HTTP à l'action est le suivant :

Méthode HTTP Action Description

POST Create Créez un nouvel objet ou une nouvelle ressource.
GET Pour en savoir Récupérez les détails des ressources à partir du système.
PUT Mettre à jour Remplacer ou mettre à jour une ressource existante.
Mettez à jour certains détails à partir d'une ressource
PATCH Mise à jour partielle
existante.
DELETE Supprimer Supprimer une ressource du système.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 34
Introduction aux API REST
Requêtes API REST (suite)
En-tête :
• Les en-têtes HTTP sont formatés en paires nom-valeur qui sont séparées par deux points ( :), [name] :
[value].

Deux types d'en-têtes :

• En-têtes de requête - Inclure des informations supplémentaires qui ne sont pas liées au contenu du
message.

Clé Exemple de valeur Description

Autorisation Basic dmFncmFudDp2YWdyYW Fournir des informations d'identification pour
autoriser la demande

• En-têtes des entités- Informations supplémentaires décrivant le contenu du corps du message.

Clé Exemple de valeur Description

Type de
application/json Spécifier le format des données dans le corps
contenu © 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 35
Introduction aux API REST
Requêtes API REST (suite)
Corps:

• Le corps de la requête API REST contient les données relatives à la ressource que le client
souhaite manipuler.

• Les requêtes d'API REST qui utilisent la méthode HTTP POST, PUT et PATCH incluent
généralement un corps.

• Le corps est facultatif en fonction de la méthode HTTP.

• Si les données sont fournies dans le corps, le type de données doit être spécifié dans l'en-
tête à l'aide de la clé Content-Type.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 36
Introduction aux API REST
Requêtes API REST
• Les réponses API REST sont des réponses HTTP qui communiquent les résultats de la
requête HTTP d'un client.
• Les réponses API REST sont composées de trois composants principaux :

• État HTTP

• En-tête

• Corps

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 37
Introduction aux API REST
Réponses aux API REST (suite)
État HTTP
• Le code d'état HTTP aide le client à déterminer la raison de l'erreur et peut parfois fournir des
suggestions pour résoudre le problème.
• Les codes d'état HTTP se composent de trois chiffres, où le premier chiffre correspond à la
catégorie de réponse et les deux autres chiffres sont affectés par ordre numérique.
• Il existe cinq catégories différentes de codes d'état HTTP :
• 1xx — Information — à titre informatif, les réponses ne contiennent pas de corps
• 2xx — Succès — le serveur a reçu et accepté la demande
• 3xx — Redirection — le client a une action supplémentaire à effectuer pour terminer la
demande
• 4xx — Erreur du client — la requête contient une erreur telle qu'une mauvaise syntaxe ou
une entrée non valide
• 5xx — Erreur du serveur — impossible de répondre aux demandes valides.
© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 38
Introduction aux API REST
Réponses aux API REST (suite)
Les codes d'état HTTP courants sont les suivants :
Code d'état HTTP Messages d'état Description
La requête a été réussie et contient généralement une charge utile
200 OK
(corps)
201 Created La demande a été exécutée et la ressource demandée a été créée
202 Accepted La demande a été acceptée pour traitement et est en cours
La demande ne sera pas traitée en raison d'une erreur avec la
400 Bad Request
demande
La requête n'a pas d'informations d'identification d'authentification
401 Unauthorized
valides pour effectuer la demande
403 Forbidden La demande a été comprise mais a été rejetée par le serveur
Impossible d'exécuter la demande car le chemin de ressource de la
404 Not Found
demande n'a pas été trouvé sur le serveur
La demande ne peut pas être traitée en raison d'une erreur de
500 Internal Server Error
serveur © 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 39

La demande ne peut pas être traitée car actuellement le serveur ne

Introduction aux API REST
Réponses aux API REST (suite)
• En-tête - L'en-tête de la réponse est de fournir des informations supplémentaires entre le serveur et le client dans le format
de paire nom-valeur qui est séparé par deux points ( : ), [name] : [value] .Il existe deux types d'en-têtes : les en-têtes de
réponse et les en-têtes d'entité.
• En-têtes de réponse— Il contient des informations supplémentaires qui ne sont pas liées au contenu du message. Les
en-têtes de réponse typiques pour une requête d'API REST incluent :
Clé Exemple de valeur Description
Utilisé pour envoyer des cookies à partir
Set-Cookie JSESSIONID=30A9DN810FQ428P; Path=/
du serveur
Spécifier les directives qui DOIVENT
Contrôle du
Cache-Control: max-age=3600, public être respectées par tous les
cache
mécanismes de mise en cache
• En-têtes d'entité— Il s'agit d'informations supplémentaires qui décrivent le contenu du corps du message. Un en-tête
d'entité commun spécifie le type de données renvoyées :

Clé Exemple de valeur Description

Type de
application/ json Spécifier le format des données dans le corps
contenu © 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 40
Introduction aux API REST
Réponses aux API REST (suite)
Pagination de réponse
• La pagination des réponses permet de diper les données en morceaux.
• La plupart des API qui implémentent la pagination utilisent le paramètre de requête pour
spécifier la page à renvoyer dans la réponse.
Données de réponse compressées
• Les données compressées réduisent une grande quantité de données qui ne peuvent
pas être paginées
• Pour demander une compression de données, la demande doit ajouter le champ Accept-
Encoding à l'en-tête de la demande. Les valeurs acceptées sont les suivantes :
• gzip
• compress
• deflate
• br
• identité
© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
• * confidentielles de Cisco 41
Introduction aux API REST
Utilisant les diagrammes de séquence avec l'API REST
• Les diagrammes de séquence sont
Diagramme de séquence de requête/réponse API
utilisés pour expliquer une séquence
d'échanges ou d'événements.

• Le diagramme de séquence de requête

API comporte trois séquences distinctes :
• Créer une session- la demande de
démarrage est étiquetée comme
HTTPS : Créer une session
w/informations d'identification.
• Obtenir des appareils - demandez
une liste d'appareils à partir de la plate-
forme.
• Créer un périphérique : commence
par une requête POST pour créer un
périphérique.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 42
4.5 Authentification à une API
REST

© 2016 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 43
Authentification à une API REST
Authentification REST API
• Les API REST nécessitent une authentification afin que les utilisateurs aléatoires ne puissent
pas accéder, créer, mettre à jour ou supprimer des informations de manière incorrecte ou
malveillante.
• Certaines API qui ne nécessitent pas d'authentification sont en lecture seule et ne
contiennent aucune information critique ou confidentielle.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 44
Authentification à une API REST
Authentication Vs. Autorisation
Authentification :

• L'authentification prouve l'identité de l'utilisateur.

• Par exemple, lorsque vous vous rendez à l'aéroport, vous devez

présenter votre pièce d'identité délivrée par le gouvernement ou
utiliser des données biométriques pour prouver que vous êtes la
personne que vous prétendez être.

Autorisation :

• L'autorisation définit l'accès utilisateur.

• C'est l'acte où l'utilisateur s'avère avoir des autorisations pour

effectuer l'action demandée sur cette ressource.

• Par exemple, lorsque vous allez à un concert, tout ce que vous

avez besoin de montrer est votre billet pour prouver que vous êtes
autorisé à y entrer.
© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 45
Authentification à une API REST
Mécanismes d'authentification
Les types courants de mécanismes d'authentification sont les suivants :
• Authentification de base : Elle transmet les informations d'identification sous forme de
paires nom d'utilisateur/mot de passe séparées par un deux-points ( :) et encodées en
Base64.
• Authentification au porteur : elle utilise un jeton porteur, qui est une chaîne générée par
un serveur d'authentification tel qu'un service d'identité (ID).
• Clé API : Il s'agit d'une chaîne alphanumérique unique générée par le serveur et attribuée
à un utilisateur. Les deux types de clés API sont publiques et privées.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 46
Authentification à une API REST
Mécanismes d'autorisation
• Oauth (Open Authorization) combine authentification et autorisation.

• Oauth a été développé comme une solution aux mécanismes d'authentification non
sécurisés.
• Oauth a augmenté la sécurité par rapport à d'autres options.

• Il existe deux versions d'Oauth - OAuth 1.0 et OAuth 2.0, où OAuth 2.0 n'est pas
rétrocompatible.
• L'infrastructure d'autorisation OAuth 2.0 permet à une application tierce d'obtenir un accès
limité à un service HTTP.
• OAuth permet à l'utilisateur de fournir des informations d'identification directement au
serveur d'autorisation [Identity Provider (IdP) ou à un service d'identité (ID)], afin d'obtenir
un jeton d'accès à partager avec l'application.
• Le processus d'obtention du jeton est appelé un flux.
© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 47
Authentification à une API REST
Travaux pratiques - Explorez les API REST avec le simulateur
d'API et Postman
Au cours de ces travaux pratiques, vous aborderez les points suivants :
• Partie 1: Lancer la DEVASC VM

• Partie 2: Explorer la documentation de l'API à l'aide du simulateur d'API

• Partie 3: Utiliser Postman pour effectuer des appels d'API au simulateur d'API

• Partie 4: Utiliser Python pour ajouter 100 livres au simulateur API

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 48
4.6 Les limites de débit
des API

© 2016 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 49
Limites de débit d'API
Que sont les limites de débit ?
• Une limite de débit API est un moyen pour un service Web de contrôler le nombre de
demandes qu'un utilisateur ou une application peut faire par unité de temps définie.
• La limitation des débits aide à :

• éviter une surcharge de serveur à partir d'un trop grand nombre de demandes à la fois

• offrir un meilleur service et un meilleur temps de réponse à tous les utilisateurs

• se protéger contre une attaque par déni de service (DoS)

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 50
Limites de débit d'API
Algorithmes de limite
Seau qui fuit (Leaky bucket) Représentation visuelle de Exemple d'algorithme de seau qui fuit
l'algorithme de seau qui fuit
• Cet algorithme place toutes
les demandes entrantes dans
une file d'attente dans l'ordre
dans lequel elles ont été
reçues.
• Les demandes entrantes
peuvent entrer à tout prix,
mais le serveur traitera les
demandes de la file d'attente à
un taux fixe.
• Si la file d'attente est pleine, la
demande est rejetée
© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 51
Limites de débit d'API
Algorithmes de limite de débit (suite)
Seau à jetons (Token bucket)
• Cet algorithme donne à chaque utilisateur un nombre défini de jetons qu'il peut utiliser dans un certain
incrément de temps.
• Lorsque le client fait une demande, le serveur vérifie le compartiment pour s'assurer qu'il contient au moins
un jeton. Si c'est le cas, il supprime ce jeton et traite la demande. S'il n'y a pas de jeton disponible, il rejette la
demande.
• Le client doit calculer le nombre de jetons qu'il a actuellement pour éviter les demandes rejetées.

Modèle d'algorithme de compartiment de jeton Exemple d'algorithme de token bucket

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 52
Limites de débit d'API
Algorithmes de limite de débit (suite)
Compteur de fenêtre fixe
• Dans l'algorithme de compteur de Exemple d'algorithme de Fixed Window Counter
fenêtre fixe, une fenêtre de temps fixe
est affectée à un compteur pour
représenter le nombre de demandes
pouvant être traitées pendant cette
période.
• Lorsque le serveur reçoit une demande,
le compteur de la fenêtre de temps
actuelle doit être zéro.
• Lorsque la demande est traitée, le
compteur est déduit. Si la limite pour
cette période est respectée, toutes les
demandes subséquentes dans cette
période seront rejetées.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 53
Limites de débit d'API
Algorithmes de limite de débit (suite)
Compteur de fenêtre coulissante
(Sliding window counter)
Exemple d'algorithme de Sliding window counter
• Cet algorithme permet d'effectuer un
nombre fixe de demandes dans une
durée définie.
• Lorsqu'une nouvelle demande est faite,
le serveur compte le nombre de
demandes déjà effectuées depuis le
début de la fenêtre jusqu'à l'heure
actuelle pour déterminer si la demande
doit être traitée ou rejetée.
• Le client doit s'assurer que la limite
tarifaire ne dépasse pas au moment de
la demande.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 54
Limites de débit d'API
Connaître la limite de débit
• De nombreuses API limitant le débit ajoutent des détails sur la limite de débit dans l'en-tête
de la réponse.
• Les clés de limite de taux couramment utilisées comprennent :
• X-Rate Limit-Limit - Nombre maximal de demandes pouvant être effectuées dans une
unité de temps spécifiée.
• X-Rate Limit-Remaining - Nombre de demandes en attente que le demandeur peut
effectuer dans la fenêtre Limite de taux en cours
• X-Rate Limit-Reset - Heure de réinitialisation de la fenêtre de limite de taux.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 55
Limites de débit d'API
Dépassement de la limite de débit
• Lorsque la limite de débit est dépassée, le serveur rejette automatiquement la demande et
renvoie une réponse HTTP à l'utilisateur.
• La réponse contenant l'erreur « limite de débit dépassé » inclut également un code d'état
HTTP significatif.
• Les codes d'état HTTP les plus couramment utilisés sont 429: Too Many Requests ou 403: Forbidden.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 56
4.7 Travailler avec Webhooks

© 2016 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 57
Travailler avec Webhooks
Qu'est-ce qu'un Webhook ?
• Un Webhook est un rappel HTTP, ou un HTTP POST, vers une URL spécifiée qui notifie
l'application lorsqu'une activité ou un événement particulier se produit dans les ressources.
• Avec les webhooks, les applications sont plus efficaces car les mécanismes d'interrogation ne
sont pas requis.
• Les webhooks sont également appelés API inversées, car les applications s'abonnent à un
serveur webhook en s'inscrivant auprès du fournisseur webhook.
• Plusieurs applications peuvent s'abonner à un seul serveur webhook.
Exemples :
• La plate-forme Cisco DNA Center fournit des webhooks qui permettent aux applications
tierces de recevoir des données réseau lorsque des événements spécifiés se produisent.
• Vous pouvez créer un webhook pour que Cisco Webex Teams vous informe des nouveaux
messages publiés dans une pièce particulière.
© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 58
Travailler avec Webhooks
Consommation d'un webhook
• Afin de recevoir une notification d'un fournisseur de webhook, l'application doit répondre à
certaines exigences :
• L'application doit être en cours d'exécution à tout moment pour recevoir des requêtes
HTTP POST.
• L'application doit enregistrer un URI sur le fournisseur webhook.
• En outre, l'application doit gérer les notifications entrantes du serveur webhook.

• Utilisez des outils en ligne gratuits pour vous assurer que l'application reçoit des
notifications d'un webhook.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 59
4.8 Dépannage des appels API

© 2016 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 60
Dépannage des appels API
Dépannage des demandes d'API REST
• Il y aura des cas où vous ferez une requête d'API mais n'obtiendrez pas la réponse
attendue. Par conséquent, apprendre à résoudre les problèmes les plus courants de l'API
REST est important.
• Ayez toujours à portée de main le guide de référence de l'API et les informations
d'authentification de l'API lors de la résolution des problèmes de l'API

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 61
Dépannage des appels API
Pas de réponse et code d'état HTTP du serveur API
• Parfois, les serveurs API ne peuvent pas être atteints ou ne parviennent pas à répondre. Vous pouvez
identifier ce qui s'est mal passé à partir des messages d'erreur reçus à la suite de la demande.
Conseils de dépannage pour les erreurs côté client :
• Erreur de l'utilisateur: Erreur de saisie de l'URI lors de la première utilisation de l'API.

• Exemple d'URI non valide — Pour tester la condition d'URI non valide, exécutez un script qui envoie la
demande à un URI qui manque le schéma.

La traçabilité sera la suivante :

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 62
Dépannage des appels API
Pas de réponse et de code d'état HTTP à partir du serveur API
(suite)
Exemple de nom de domaine incorrect — Pour tester la mauvaise condition de nom de domaine,
exécutez un script qui fait simplement la demande à un URI qui a le mauvais nom de domaine.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 63
Dépannage des appels API
Pas de réponse et de code d'état HTTP à partir du serveur API
(suite)
Problèmes de connectivité

• Y a-t-il des problèmes de proxy, de pare-feu ou de VPN ?

• Y a-t-il une erreur SSL ?

Exemple de certificat non valable

• Ce problème ne peut se produire que si l'URI de l'API REST utilise une connexion sécurisée (HTTPS).
• Lorsque le système de l'URI est HTTPS, la connexion effectue une connexion SSL entre le client et le
serveur. S'il échoue, corrigez le certificat non valide
Traceback:

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 64
Dépannage des appels API
Pas de réponse et de code d'état HTTP à partir du serveur API
(suite)
• Toutefois, si vous travaillez dans un environnement de laboratoire où les certificats ne sont
pas encore valides, vous pouvez désactiver le paramètre de vérification des certificats.
• Pour la désactiver pour la bibliothèque de requêtes en Python, ajoutez le paramètre verify à
la requête.

Résolution :
• Résoudre le problème en identifiant la cause première.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 65
Dépannage des appels API
Pas de réponse et de code d'état HTTP à partir du serveur API
(suite)
Conseils de dépannage pour les erreurs côté serveur :
• Fonctionnement du serveur API : mise hors tension, problèmes de câblage, changement de nom
de domaine, panne du réseau.
• Pour tester si l'adresse IP est accessible, exécutez un script qui envoie la requête à l'URL et attend
une réponse.

• Si le serveur API ne fonctionne pas, vous obtiendrez un long silence suivi d'une trace qui sera la
suivante :

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 66
Dépannage des appels API
Pas de réponse et de code d'état HTTP à partir du serveur API
(suite)
Y a-t-il un problème de communication entre le serveur API et le client ?
• Utilisez un outil de capture réseau pour voir si la réponse du serveur API est perdue dans la
communication entre le serveur API et le client.
• Si vous y avez accès, jetez un oeil aux journaux du serveur d'API si la demande a été
reçue.
Résolution :
• Les problèmes côté serveur ne peuvent pas être résolus à partir du client API.

• Contactez l'administrateur du serveur API pour résoudre ce problème.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 67
Dépannage des appels API
Interprétation des codes d'état
• Le code d'état fait partie de la norme HTTP/1.1 (RFC 7231), où le premier chiffre définit la classe de la
réponse et les deux derniers chiffres n'ont aucun rôle de classe ou de catégorisation.
• Les cinq catégories de codes de statut sont les suivantes :
• 1xx: Informational - Demande reçue, poursuite du traitement.
• 2xx: Succès - The action was successfully received, understood, and accepted.
• 3xx: Redirection - Des mesures supplémentaires doivent être prises pour compléter la demande.
• 4xx: Erreur du client - La requête contient une syntaxe incorrecte ou ne peut pas être exécutée.
• 5xx: Erreur de serveur - Le serveur n'a pas réussi à répondre à une demande apparemment valide.
• Étapes à suivre pour résoudre les erreurs :
• Vérifier le code de retour - Il peut aider à sortir le code de retour dans le script pendant la phase de
développement.
• Vérifier le corps de la réponse - Sortie le corps de la réponse pendant le développement
• Utiliser la référence du code d'état — Si les problèmes ne peuvent pas être résolus en vérifiant le
code de retour et le corps de la réponse.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 68
Dépannage des appels API
2xx et 4xx codes d'état
• 2xx – Erreur de succès: reçu, compris et accepté avec succès

• 4xx – Erreur côté client: l'erreur est côté client.

Dépannage des erreurs courantes 4xx :

400 – Bad request
La requête n'a pas pu être comprise par le serveur en raison d'une syntaxe mal formée, qui est
principalement due à :
• Mauvaise orthographe des ressources
• Problème de syntaxe dans l'objet JSON.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 69
Dépannage des appels API
2xx et 4xx codes d'état (suite)
Exemple : Cet exemple renvoie un code d'état 400.

Le côté serveur vous indique également « Aucun champ id fourni », car l'id est obligatoire
pour cette requête API.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 70
Dépannage des appels API
2xx et 4xx codes d'état (suite)
401 – Unauthorized:
• Ce message d'erreur signifie que le serveur n'a pas pu authentifier la demande.
• Vérifiez vos informations d'identification, y compris votre nom d'utilisateur, mot de passe, clé API, jeton,
URI de demande
Exemple

L'authentification auth= (« person1", "great ») doit être ajoutée dans le code

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 71
Dépannage des appels API
2xx et 4xx codes d'état (suite)
403 – Forbidden
• Le serveur reconnaît les informations d'identification d'authentification, mais le client n'est
pas autorisé à exécuter la demande.
• Exemple : Le code d'état 403 n'est pas un problème d'authentification ; c'est juste que l'utilisateur
n'a pas suffisamment de privilèges pour utiliser cette API particulière.

L'authentification doit être modifiée pour utiliser person2/super au lieu de person1/great.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 72
Dépannage des appels API
2xx et 4xx codes d'état (suite)
407 - Proxy Authentication Required
• Ce code est similaire à 401 (Non autorisé), mais il indique que le client doit d'abord
s'authentifier avec le proxy.
• Dans ce scénario, il existe un serveur proxy entre le client et le serveur, et le code de
réponse 407 indique que le client doit d'abord s'authentifier auprès du serveur proxy.
409- The request could not be completed due to a conflict with the current state of the
target resource.
• Par exemple, un conflit de modification dans lequel une ressource est modifiée par
plusieurs utilisateurs provoquerait une erreur 409.
• Une nouvelle tentative de la demande peut aboutir, tant que le conflit est résolu par le
serveur.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 73
Dépannage des appels API
2xx et 4xx codes d'état (suite)
415 - Unsupported Media Type

• Dans ce cas, le client a envoyé un corps de requête dans un format que le serveur ne prend pas en charge.

• Exemple : Si le client envoie XML à un serveur qui accepte uniquement JSON, le serveur renvoie une
erreur 415.

L'omission de l'en-tête ou l'ajout d'un en-tête{"content-type » :"application/ json "}fonctionnera.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 74
Dépannage des appels API
Codes d'état 5xx
• 500 - Internal Server Error
• The server encountered an unexpected condition that prevented it from fulfilling the request.
• 501 - Not Implemented
• Le serveur ne prend pas en charge les fonctionnalités requises pour répondre à cette demande
• 502 - Bad Gateway
• The server (acting as gateway or proxy) received an invalid response from an inbound server.
• 503 - Service Unavailable
• Le serveur est actuellement incapable de traiter la demande en raison d'une surcharge ou d'une
maintenance planifiée.
• 504 - Gateway Timeout
• Le serveur (agissant comme une passerelle ou un proxy) n'a pas reçu de réponse en temps utile de
la part d'un serveur en amont.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 75
4.9 Résumé de la
compréhension et de l'utilisation
des API

© 2016 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 76
Dépannage des appels API
Qu'ai-je appris dans ce module ?
• L'API définit la manière dont les utilisateurs, les développeurs et les autres applications
peuvent interagir avec les composants d'une application.
• Une API peut utiliser des interactions Web ou des protocoles de communication communs
et ses propres normes propriétaires.
• Les API peuvent être livrées de manière synchrone (ou) asynchrone.

• Les trois types les plus populaires de styles architecturaux API sont RPC, SOAP et REST.

• Une API de service Web REST (REST API) est une interface de programmation qui
communique via HTTP tout en respectant les principes du style architectural REST.
• L'authentification est l'acte qui consiste à vérifier l'identité de l'utilisateur. Les types courants
de mécanismes d'authentification incluent Basic, Bearer et API Key.
• L'autorisation est l'acte où l'utilisateur s'avère être autorisé à effectuer l'action demandée
sur cette ressource.
© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations
confidentielles de Cisco 77
Dépannage des appels API
Qu'ai-je appris dans ce module ? (suite)
• Une limite de débit d'API est un moyen pour un service Web de contrôler le nombre de
demandes qu'un utilisateur ou une application peut effectuer par unité de temps définie.
• Un webhook est un rappel HTTP, ou un HTTP POST, vers une URL spécifiée qui notifie
votre application en cas d'activité ou d'événement dans l'une de vos ressources sur la
plate-forme.
• Le guide de référence de l'API et les informations d'authentification de l'API doivent être
pratiques avant de procéder au dépannage.
• Les erreurs côté client incluent une erreur utilisateur, un URI incorrect, un domaine
incorrect, un problème de connectivité et un certificat non valide.
• Erreur côté serveur inclut des problèmes de communication entre le serveur et le client.

• Les codes 4xx sont des erreurs côté client et les codes 5xx sont des erreurs côté serveur.

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 78
Dépannage des appels API
Travaux pratiques - Intégration d'une API REST avec Python
Au cours de ces travaux pratiques, vous aborderez les points suivants :
• Partie 1: Lancer la DEVASC VM

• Partie 2: Démonstration de l'application MapQuest Directions

• Partie 3: Obtenir une clé API MapQuest

• Partie 4: Construire l'application MapQuest Direction de base

• Partie 5: Améliorer l'application MapQuest Directions avec plus de fonctionnalités

• Partie 6: Test de la fonctionnalité de l'application complète

© 2020 Cisco et/ou ses filiales. Tous droits réservés. Informations

confidentielles de Cisco 79