Une intégration d’API est le code qui permet à un système de transférer des données vers ou depuis un autre système tout en utilisant une API (unapplication pprogrammation jenterface) pour accéder en toute sécurité au système. Certaines intégrations d’API peuvent n’avoir qu’une API d’un côté de l’intégration, tandis que d’autres peuvent utiliser deux API ou plus.
Les développeurs créent des intégrations d’API pour différentes raisons, mais ces intégrations entrent généralement dans l’une des deux catégories suivantes :
- Ils sont soit destinés à être exécutés à l’intérieur d’une entreprise pour automatiser les flux de travail internes.
- Ils sont destinés à connecter des systèmes de différentes entreprises pour le partage de données externes.
Étant donné que nous travaillons avec des éditeurs de logiciels qui ont besoin de créer des intégrations natives connectant leurs produits aux autres systèmes utilisés par leurs clients, notre exemple couvrira un scénario de partage de données externes, mais les concepts s’appliquent également aux intégrations internes.
Nous allons présenter cet exemple comme suit :
- Les besoins de l’entreprise d’intégration (le pourquoi).
- Exigences techniques d’intégration (le quoi).
- Détails d’intégration pour l’exécution (le comment).
Besoins commerciaux d’intégration
Pour cet exemple d’intégration d’API, votre entreprise fournit un produit SaaS pour surveiller la sécurité des bâtiments. Entre autres choses, votre application enregistre régulièrement les niveaux de température et d’humidité à partir de capteurs installés aux points critiques de chacun des bâtiments de vos clients. Votre client a besoin d’une intégration pour exporter quotidiennement ces valeurs de température et d’humidité de votre produit vers son application de maintenance des bâtiments (StructManager). Le client déterminera alors s’il existe des corrélations entre les niveaux de température et d’humidité et les tickets de maintenance non planifiés.
Exigences techniques d’intégration
Lors de la création d’une intégration, vous souhaiterez commencer par les exigences techniques. Voici les questions de base auxquelles vous devrez répondre avant de commencer :
- Quelles données seront transférées ? (Données)
- S’agit-il d’une intégration unidirectionnelle ou bidirectionnelle ? (Direction)
- À quelle fréquence l’intégration s’exécutera-t-elle ? (Fréquence)
- Quelles API seront utilisées ? (API)
- Quels protocoles de transfert seront utilisés ? (Protocole)
- Quelles langues de transport seront utilisées ? (Langue)
- Comment l’authentification sera-t-elle gérée ? (Authentique)
Remplissons tous ces éléments pour notre exemple d’intégration d’API :
- Données: relevés d’humidité et de température par bâtiment pour la veille (période de 24 heures).
- Direction: Export unidirectionnel de votre produit vers StructManager.
- Fréquence: Une fois par jour à 7 h 00, heure locale du bâtiment.
- API: Votre produit utilise une API SOAP. StructManager utilise une API REST.
- Protocole: Les deux API prennent en charge HTTP.
- Langue: Votre produit génère SOAP XML. StructManager accepte JSON en entrée.
- Authentification: L’API SOAP et l’API REST utilisent OAuth.
De plus, alors que les données d’humidité sont fournies en points de pourcentage d’humidité relative (et sont les mêmes dans les deux applications), les données de température provenant de votre produit utilisent Celsius, tandis que StructManager est configuré pour utiliser Fahrenheit. Enfin, les données de température et d’humidité sont collectées une fois par minute par votre produit, mais StructManager n’a besoin de connaître les valeurs que toutes les 15 minutes.
Ainsi, pour cet exemple d’intégration d’API, nous avons deux API, deux formats de données, deux échelles pour les valeurs de température et bien plus de données que nécessaire. On dirait que nous devrons faire plus que simplement récupérer les données d’une API et les transmettre à l’autre.
Détails d’intégration pour l’exécution
À 7 h 00, heure locale, le déclencheur d’intégration entraîne l’envoi par l’intégration d’une requête à l’API SOAP de votre produit demandant les enregistrements du client spécifié par bâtiment au cours des dernières 24 heures. Heureusement, votre API SOAP prend en charge OAuth, qui est intégré à la chaîne de connexion. Une fois que l’API SOAP reçoit la demande, elle renvoie XML via HTTP avec tous les enregistrements correspondants.
Un seul enregistrement envoyé depuis votre produit SaaS ressemble à ceci :
<environmental>
<customer_id>AA8312</customer_id>
<building_id>H265<building_id/>
<sensor_id>1323</sensor_id>
<sensor_loc>5W2NAB</sensor_loc>
<timestamp>10:30</timestamp>
<temperature>27.3</temperature>
<humidity>55</humidity>
</environmental>L’intégration effectue d’abord une conversion de format de données pour tout traduire de XML à JSON, nous donnant le modèle suivant pour un seul enregistrement :
{
"environmental": {
"customer_id": "AA8312",
"building_id": "H265",
"sensor_id": 1323,
"sensor_loc": "5W2NAB",
"timestamp": "10:30",
"temperature": 27.3,
"humidity": 55
}
}Pour l’exemple de client, qui dispose de trente capteurs répartis dans un seul bâtiment, l’exportation quotidienne depuis votre API SOAP comprendra 43 200 enregistrements, mais l’intégration n’a besoin d’en envoyer que 2 880 à StructManager. Par conséquent, nous aurons besoin de l’intégration pour filtrer les 43 200 enregistrements et supprimer tous les enregistrements qui n’ont pas de valeurs d’horodatage correspondant aux modèles suivants : hh:00, hh:15, hh:30et hh:45. Et oui, nous pourrions trouver un moyen de demander uniquement ces enregistrements à l’API SOAP en premier lieu, mais il est plus propre dans ce cas d’obtenir le sur-ensemble de données et de partir de là.
Une fois que l’ensemble de données réduit ne contient que les enregistrements que nous voulons conserver, l’intégration devra parcourir les données une fois de plus pour convertir les valeurs de température de Celsius en Fahrenheit en utilisant un peu de calcul simple. Nos exemples de données correspondent désormais au format que StructManager doit importer :
{
"environmental": {
"customer_id": "AA8312",
"building_id": "H265",
"sensor_id": 1323,
"sensor_loc": "5W2NAB",
"timestamp": "10:30",
"temperature": 81.1,
"humidity": 55
}
}À ce stade, les 2 880 enregistrements, encodés en JSON, sont intégrés dans une requête HTTP pour l’API REST StructManager. Encore une fois, l’intégration utilise OAuth pour se connecter à l’API avant de soumettre les données.
Notre exemple d’intégration d’API s’est exécuté avec succès et attendra jusqu’à demain à 7 h 00 pour sa prochaine exécution.
Ressources d’intégration d’API supplémentaires
Bien sûr, un exemple peut difficilement rendre justice à un sujet aussi complexe que les intégrations d’API. Dans cet esprit, voici quelques ressources pour vous aider à mieux comprendre les concepts d’intégration d’API :
- API par technologie (REST, XML-RPC, SOAP et GraphQL).
- API par type d’accès (privé, partenaire, public et ouvert).
- Protocoles de transfert d’intégration et langages de transport.
- Types de média d’intégration (anciennement appelés types mime).
- Ce qui se passe au milieu d’une intégration.
Tout est dans les outils
Les API sont extrêmement utiles pour créer des intégrations de données entre les produits SaaS. Mais disposer des bons outils pour travailler avec ces API est essentiel. En tant qu’éditeur de logiciels fournissant des intégrations dans l’application, ces outils peuvent faire la différence entre la mise en œuvre des intégrations minimales qui répondent aux besoins de vos clients et la mise en œuvre d’intégrations qui font tellement partie de votre produit SaaS que vos clients ne peuvent pas le dire. où votre produit s’arrête et où l’intégration commence. L’un de ces outils est une plate-forme d’intégration intégrée.