Les exemples ci-dessous décrivent plusieurs demandes courantes, notamment l’authentification, la création d’appareils et de tâches, l’obtention d’une liste de plates-formes et l’obtention d’informations sur les appareils à l’aide de Postman (voir également comment utiliser Postman pour les tests de charge).

Pour commencer avec l’API Dotcom-Monitor, l’en-tête HTTP/HTTPS doit avoir Content-Type défini sur
application/json
.

Pour plus d’informations sur la méthode API, consultez l’article correspondant de la catégorie Méthodes.

connectez-vous

Pour l’authentification, utilisez l’URI POST “/login«. Lorsque vous vous connectez via l’appel “/login«, une nouvelle session client commence. Les sessions expirent automatiquement après une durée d’inactivité prédéterminée. La valeur par défaut est d’une minute. Si vous faites un appel API, la mise à zéro de la mise à zéro de la mise à zéro de la mise à zéro de la mise à l’heure de la période d’inactivité.

Lorsque votre session expire, le code d’erreur HTTP d’exception « 401 – Non autorisé » est renvoyé. Si cela se produit, vous devez vous connecter à nouveau.

Il est recommandé d’utiliser votre UID d’intégration pour vous connecter ( > Account Integration > UID).

POST /config_api_v1/login HTTP/1.1
Host: api.dotcom-monitor.com
Content-Type: application/json

{ 
"UID":"0E206D45650A4ACD8EB689B8CC25FA7F"
}

Obtenir des plateformes

Pour obtenir la liste des plates-formes de surveillance, utilisez GET URI “
/platforms
. Si la demande réussit, le serveur répond avec un code d’état HTTP et la liste de toutes les plates-formes disponibles. Il est recommandé d’enregistrer la réponse afin d’utiliser les détails de votre compte (ID de package, ID de plateforme, ID d’appareil, etc.) dans les demandes ultérieures.

GET /config_api_v1/platforms HTTP/1.1
Host: api.dotcom-monitor.com
Content-Type: application/json

Créer un appareil

Utilisez les données reçues dans la réponse « Get Platforms » pour créer une requête JSON. Les paramètres de périphérique qui ne sont pas spécifiés dans la demande seront définis par défaut.

POST /config_api_v1/devices?verb=PUT HTTP/1.1
Host: api.dotcom-monitor.com
Content-Type: application/json

{ 
"Postpone":"true",
"Frequency":60,
"Package_Id":465,
"Platform_Id":12,
"Locations":{2,4,6,18,68},
"Name":"TESTDEVICE 9.23.2019"
}

Créer une tâche

Post /config_api_v1/tasks?verb=PUT HTTP/1.1
Host: api.dotcom-monitor.com
Content-Type: application/json

{
"Name":"testname",
"Url":"https://dotcom-monitor.com",
"Device_Id":123456,
"RequestType":"GET",
"Task_Type_Id":2,
"DNSResolveMode":"Device Cached"
}

Obtenir et modifier les informations sur l’appareil

Pour modifier les informations sur l’appareil, envoyez d’abord une requête GET avec l’ID de l’appareil dans l’URI pour recevoir la réponse du serveur.

GET /config_api_v1//device/193403 HTTP/1.1
Host: api.dotcom-monitor.com
Content-Type: application/json

Ensuite, utilisez le corps de la réponse pour modifier les paramètres du périphérique et renvoyer la requête JSON avec de nouvelles valeurs.

POST /config_api_v1//device/193403 HTTP/1.1
Host: api.dotcom-monitor.com
Content-Type: application/json

{
    "Avoid_Simultaneous_Checks": false,
    "Alert_Silence_Min": 0,
    "False_Positive_Check": false,
    "Locations": [
        1,
        2,
        3,
        4,
        6,
        11,
        13,
        14,
        15,
        18,
        19,
        23,
        43,
        68,
        97,
        113,
        118,
        138,
        153,
        233
    ],
    "Send_Uptime_Alert": false,
    "Status_Description": "POSTPONED",
    "Postpone": true,
    "Owner_Device_Id": 0,
    "Frequency": 10800,
    "Filter_Id": 7791,
    "Scheduler_Id": 0,
    "Notifications": {
        "E_Mail_Flag": false,
        "E_Mail_Address": null,
        "E_Mail_TimeInterval_Min": 5,
        "WL_Device_Flag": false,
        "WL_Device_Email_Address": null,
        "WL_Device_TimeInterval_Min": 15,
        "Pager_Flag": false,
        "Pager_Area_Code": null,
        "Pager_Phone": null,
        "Pager_Num_Code": null,
        "Pager_TimeInterval_Min": 15,
        "Phone_Flag": false,
        "Phone_Area_Code": null,
        "Phone_Phone": null,
        "Phone_TimeInterval_Min": 15,
        "SMS_Flag": false,
        "SMS_Phone": null,
        "SMS_TimeInterval_Min": 15,
        "Script_Flag": false,
        "Script_Batch_File_Name": null,
        "Script_TimeInterval_Min": 0,
        "SNMP_TimeInterval_Min": 0,
        "Notification_Groups": []
    },
    "Id": 193403,
    "Number_Of_Tasks": 1,
    "WaitingForApproval": false,
    "Platform_Id": 12,
    "Package_Id": 465,
    "Name": "Under_Task"
}

Des informations supplémentaires sur la création d’appareils avec les API Dotcom-Monitor sont disponibles sur notre Wiki.

  • Test des API avec Postman Explained

    Qu’est-ce qu’une API ?

    Une API signifie Application Programming Interface – une interface qui permet aux applications de communiquer. L’API permet aux développeurs de logiciels d’envoyer des informations directement d’une application à une autre, en contournant une interface utilisateur.

    Pour les tests et le développement d’API, des outils spéciaux permettant d’envoyer des données d’entrée dans une requête et de vérifier si les données de sortie sont correctes sont largement utilisés. Postman est l’un des outils comme celui-ci.

    Pourquoi utiliser Postman?

    Postman est un outil de test et de développement d’API conçu pour envoyer des requêtes du côté client au serveur Web et recevoir une réponse du backend. Les informations reçues avec la réponse sont déterminées par les données envoyées avec la demande. Ainsi, Postman est utilisé comme client API pour vérifier les requêtes client-serveur afin de s’assurer que tout fonctionne côté serveur comme prévu. Postman prend en charge les demandes adressées aux services Web Restful, SOAP et GraphQL.

    Une interface graphique fait de Postman un outil facile à utiliser dans le processus de test et de développement d’API.

    Vous pouvez télécharger Postman à partir de https://www.postman.com/downloads/.

    Pour tester les services Web Restful, Postman utilise des requêtes HTTP pour envoyer des informations à une API. Une requête HTTP est un message HTTP qu’un client envoie à un serveur HTTP. En règle générale, une requête HTTP contient une ligne de départ, un ensemble d’en-têtes HTTP et un corps.

    Une ligne de démarrage de requête HTTP contient la méthode HTTP, l’URI de la ressource cible et la version du protocole HTTP et a la structure suivante :

    Méthode HTTP / URI cible / Version HTTP

    Les méthodes HTTP déterminent l’action qui doit être effectuée sur la ressource. La signification des méthodes HTTP est décrite par la spécification du protocole. La spécification du protocole HTTP ne limite pas le nombre de méthodes différentes pouvant être utilisées. Cependant, seules certaines des méthodes les plus standard sont utilisées pour prendre en charge la compatibilité avec un large éventail d’applications.

    Certaines des méthodes HTTP qui peuvent être utilisées dans les appels d’API sont les suivantes :

    • GET – pour obtenir des données (lues) (par exemple, une liste d’utilisateurs).
    • POST – pour créer de nouvelles données.
    • PUT / PATCH – pour mettre à jour les données.
    • DELETE – pour supprimer des données.
    • OPTIONS – pour obtenir une description complète des méthodes API disponibles sur le service.

    L’en-tête contient des métadonnées pour permettre à un client de transmettre des informations de clarification et de service sur la requête HTTP telles que des informations de codage, des paramètres d’autorisation, etc.

    Les informations que vous souhaitez transférer sur le réseau sont transmises dans le corps. Le corps est facultatif et peut être laissé vide (en fonction des méthodes HTTP et des en-têtes).

    HTTP-response est la donnée qui revient du serveur API. Outre les données dans le corps, l’en-tête de réponse contient un code HTTP d’état de la réponse du serveur. Par exemple, vous pouvez recevoir les codes d’état suivants dans l’en-tête de réponse :

    • 200 – Succès;
    • 400 – Mauvaise demande;
    • 401 – Non autorisé.

    Utilisation des demandes dans Postman

    En utilisant l’interface graphique Postman, il n’est pas nécessaire que les développeurs Web écrivent leur propre code pour tester les fonctionnalités de l’API.

    L’utilisation des demandes dans Postman comprend la séquence d’étapes suivante :

    • Ajout d’une nouvelle requête HTTP à l’aide de l’interface Postman.
    • Personnalisation de la requête (spécification d’une méthode HTTP, d’un en-tête, d’un corps, de paramètres d’authentification).
    • Exécution de la demande.
    • Enregistrement de la demande (par exemple, dans un dossier ou une collection).

    Tests en facteur

    Pour traiter la réponse du serveur, on peut créer différents tests dans Postman. Le test dans Postman est un code JavaScript qui est exécuté automatiquement après que le client a reçu une réponse à la demande. En d’autres termes, les tests Postman sont appliqués au résultat de la requête exécutée.

    Postman propose de nombreux extraits de code prêts à l’emploi que vous pouvez ajouter à votre test. Vous trouverez ici des extraits pour valider les codes et le contenu des réponses, analyser et enregistrer des valeurs dans des variables d’environnement ou des variables globales, vérifier leur conformité avec les valeurs spécifiées, etc. Par exemple, vous pouvez vérifier que le code d’état de la réponse à la requête GET est 200. Les tests peuvent être appliqués non seulement à une seule demande, mais aussi à un niveau de collection.

    Collections postier

    Pour exécuter automatiquement plusieurs requêtes une par une, une collection de requêtes est utilisée dans Postman. Vous pouvez exécuter des collections remplies de demandes et de tests avec Collection Runner et les utiliser comme tests d’API automatisés. Pour exécuter une collection, vous pouvez sélectionner l’environnement, le nombre d’itérations dans l’exécution et un délai entre les demandes. De plus, Postman prend en charge l’enregistrement des demandes et le stockage des variables et des cookies.

    Une fois qu’une collection de requêtes a été créée, elle peut être exportée vers un fichier pour être utilisée dans une application tierce. Par exemple, Dotcom-Monitor prend en charge l’importation de Postman Collection à utiliser dans la configuration de la surveillance et des tests de charge.

    Notez que si vous devez appeler une API qui nécessite une authentification, la collecte des demandes adressées à cette API doit inclure une demande POST au service d’authentification correspondant pour autoriser le client sur le serveur.

    En plus des fonctionnalités Postman décrites, vous pouvez paramétrer vos demandes, ajouter un point d’arrêt aux appels d’API et créer différents environnements pour vos demandes. Pour en savoir plus sur l’utilisation de Postman, consultez le site Web Postman Learning Center https://learning.postman.com/.

    Comment l’API Postman de Dotcom-Monitor peut vous aider

    Grâce à notre fonctionnalité API, les développeurs de logiciels peuvent interagir avec leurs données de surveillance et de test de charge Dotcom-Monitor et exploiter les résultats des tests Dotcom-Monitor dans une application tierce. L’intégration de Dotcom-Monitor avec d’autres applications est configurée via l’API REST, l’interface qui permet aux développeurs de logiciels de créer, lire et mettre à jour des données dans notre système.

    Pour configurer l’intégration avec les services Dotcom-Monitor, il faut utiliser le client Rest pour créer des demandes à notre API. Dans ce cas, il est recommandé d’utiliser Postman comme client Rest pour tester les appels HTTP à l’API Dotcom-Monitor de manière simple et rapide. En général, les paramètres de base sont effectués à l’aide d’une interface graphique qui ne nécessite pas une connaissance approfondie des langages de programmation ou une expérience en développement de logiciels.

    Une fois l’intégration testée, vous pouvez implémenter les résultats dans un client Rest personnalisé, utiliser cURL ou continuer à l’aide de Postman.