تصف الأمثلة أدناه العديد من الطلبات الشائعة بما في ذلك المصادقة وإنشاء الجهاز والمهام والحصول على قائمة بالأنظمة الأساسية والحصول على معلومات الجهاز باستخدام Postman (راجع أيضا كيفية استخدام Postman لاختبار التحميل).

للبدء بواجهة برمجة تطبيقات Dotcom-Monitor، يجب أن يحتوي رأس HTTP/HTTPS على نوع المحتوى مضبوطا على
التطبيق/json
.

للحصول على تفاصيل أسلوب واجهة برمجة التطبيقات، راجع المقالة المقابلة من فئة الأساليب .

تسجيل الدخول

للمصادقة ، استخدم POST URI “/login“. عند تسجيل الدخول عبر مكالمة “/login“، تبدأ جلسة عمل عميل جديدة. تنتهي صلاحية الجلسات تلقائيا بعد فترة محددة مسبقا من عدم النشاط. الافتراضي هو دقيقة واحدة. إذا أجريت مكالمة API، إعادة تعيين مؤقت عدم النشاط إلى الصفر.

عند انتهاء صلاحية جلستك، يتم إرجاع رمز خطأ HTTP الاستثناء، “401 – غير مصرح به”. إذا حدث ذلك، يجب عليك تسجيل الدخول مرة أخرى.

يوصى باستخدام UID الخاص بالتكامل لتسجيل الدخول (UID لتكامل > الحساب>).

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

{ 
"UID":"0E206D45650A4ACD8EB689B8CC25FA7F"
}

احصل على المنصات

للحصول على قائمة منصات المراقبة ، استخدم GET URI “/platform

“. إذا نجح الطلب، يستجيب الخادم برمز حالة HTTP وقائمة بجميع الأنظمة الأساسية المتاحة. يوصى بحفظ الاستجابة لاستخدام تفاصيل حسابك (معرف الحزمة ، معرف النظام الأساسي ، معرف الجهاز ، إلخ) في الطلبات اللاحقة.

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

إنشاء جهاز

استخدم البيانات المستلمة في استجابة “GET Platform” لإنشاء طلب JSON. سيتم تعيين معلمات الجهاز غير المحددة في الطلب إلى الوضع الافتراضي.

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"
}

إنشاء مهمة

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"
}

الحصول على معلومات الجهاز وتحريرها

لتحرير معلومات الجهاز، أولا، أرسل طلب GET مع معرف الجهاز في عنوان URI لتلقي استجابة الخادم.

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

بعد ذلك ، استخدم نص الاستجابة لتعديل معلمات الجهاز وإعادة إرسال طلب JSON بقيم جديدة.

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"
}

تتوفر معلومات إضافية حول كيفية إنشاء أجهزة باستخدام واجهات برمجة تطبيقات Dotcom-Monitor على موقع Wiki الخاص بنا.

  • اختبار واجهات برمجة التطبيقات مع شرح ساعي البريد

    ما هي واجهة برمجة التطبيقات؟

    واجهة برمجة التطبيقات تعني واجهة برمجة التطبيقات – وهي واجهة تسمح للتطبيقات بالتواصل. تتيح واجهة برمجة التطبيقات لمطوري البرامج إرسال المعلومات مباشرة من تطبيق إلى آخر ، متجاوزين واجهة المستخدم.

    لاختبار وتطوير واجهة برمجة التطبيقات ، يتم استخدام الأدوات الخاصة التي تسمح بإرسال بيانات الإدخال في طلب والتحقق مما إذا كانت بيانات الإخراج صحيحة على نطاق واسع. ساعي البريد هو واحد من أدوات مثل هذه.

    لماذا تستخدم ساعي البريد؟

    Postman هي أداة اختبار وتطوير API مصممة لإرسال الطلبات من جانب العميل إلى خادم الويب وتلقي استجابة من الواجهة الخلفية. يتم تحديد المعلومات الواردة مع الرد من خلال البيانات المرسلة مع الطلب. وبالتالي ، يتم استخدام Postman كعميل API للتحقق من طلبات خادم العميل للتأكد من أن كل شيء يعمل على جانب الخادم كما هو متوقع. يدعم ساعي البريد الطلبات إلى خدمات الويب Restful و SOAP و GraphQL.

    تجعل الواجهة الرسومية Postman أداة سهلة الاستخدام في عملية اختبار وتطوير واجهة برمجة التطبيقات.

    يمكنك تنزيل ساعي البريد من https://www.postman.com/downloads/.

    لاختبار خدمات الويب المريحة ، يستخدم Postman طلبات HTTP لإرسال معلومات إلى واجهة برمجة التطبيقات. طلب HTTP هو رسالة HTTP يرسلها عميل إلى خادم HTTP. بشكل عام، يحتوي طلب HTTP على سطر بداية ومجموعة من رؤوس HTTP ونص.

    يحتوي سطر بداية طلب HTTP على طريقة HTTP وعنوان URI للمورد الهدف وإصدار بروتوكول HTTP وله البنية التالية:

    طريقة HTTP / إصدار URI / HTTP المستهدف

    تحدد أساليب HTTP الإجراء الذي يجب تنفيذه على المورد. يتم وصف معنى طرق HTTP بواسطة مواصفات البروتوكول. لا تحد مواصفات بروتوكول HTTP من عدد الطرق المختلفة التي يمكن استخدامها. ومع ذلك ، يتم استخدام بعض الطرق الأكثر شيوعا فقط لدعم التوافق مع مجموعة واسعة من التطبيقات.

    بعض طرق HTTP التي يمكن استخدامها في استدعاءات واجهة برمجة التطبيقات هي:

    • GET – للحصول على (قراءة) البيانات (على سبيل المثال، قائمة مستخدمين).
    • POST – لإنشاء بيانات جديدة.
    • PUT / PATCH – لتحديث البيانات.
    • حذف – لحذف البيانات.
    • الخيارات – للحصول على وصف كامل لطرق API المتاحة على الخدمة.

    يحتوي الرأس على بيانات تعريف للسماح للعميل بتمرير معلومات توضيحية وخدمة حول طلب HTTP مثل معلومات الترميز ومعلمات التفويض وما إلى ذلك.

    يتم تمرير المعلومات التي تريد نقلها عبر الشبكة في النص. النص اختياري ويمكن تركه فارغا (اعتمادا على طرق HTTP ورؤوسها).

    استجابة HTTP هي البيانات التي تعود من خادم واجهة برمجة التطبيقات. إلى جانب البيانات الموجودة في النص الأساسي ، يحتوي رأس الاستجابة على رمز HTTP للحالة لاستجابة الخادم. على سبيل المثال، يمكنك تلقي رموز الحالة التالية في رأس الاستجابة:

    • 200 – النجاح ؛
    • 400 – طلب سيئ ؛
    • 401 – غير مصرح به.

    العمل مع الطلبات في ساعي البريد

    باستخدام واجهة Postman الرسومية ، ليست هناك حاجة لمطوري الويب لكتابة التعليمات البرمجية الخاصة بهم لاختبار ميزات واجهة برمجة التطبيقات.

    يتضمن العمل مع الطلبات في Postman التسلسل التالي من الخطوات:

    • إضافة طلب HTTP جديد باستخدام واجهة ساعي البريد.
    • تخصيص الطلب (تحديد طريقة HTTP والرأس والنص الأساسي ومعلمات المصادقة).
    • تنفيذ الطلب.
    • حفظ الطلب (على سبيل المثال، في مجلد أو مجموعة).

    اختبارات في ساعي البريد

    لمعالجة الاستجابة من الخادم ، يمكن للمرء إنشاء اختبارات مختلفة في Postman. الاختبار في Postman هو رمز جافا سكريبت يتم تنفيذه تلقائيا بعد أن يتلقى العميل استجابة للطلب. بمعنى آخر ، يتم تطبيق اختبارات ساعي البريد على نتيجة الطلب المنفذ.

    يقدم ساعي البريد العديد من مقتطفات التعليمات البرمجية الجاهزة للاستخدام التي يمكنك إضافتها إلى اختبارك. هنا يمكنك العثور على مقتطفات للتحقق من صحة رموز ومحتوى الاستجابات، وتحليل القيم وحفظها لمتغيرات البيئة أو المتغيرات العمومية، والتحقق من توافقها مع القيم المحددة، وما إلى ذلك. على سبيل المثال، يمكنك التحقق من أن رمز الحالة الخاص بالاستجابة لطلب GET هو 200. يمكن تطبيق الاختبارات ليس فقط على طلب واحد ولكن يمكن نقلها إلى مستوى المجموعة.

    مجموعات ساعي البريد

    لتنفيذ طلبات متعددة واحدة تلو الأخرى تلقائيا ، يتم استخدام مجموعة من الطلبات في Postman. يمكنك تشغيل المجموعات المليئة بالطلبات والاختبارات باستخدام Collection Runner واستخدامها كاختبارات واجهة برمجة تطبيقات تلقائية. لتشغيل مجموعة، يمكنك تحديد البيئة وعدد التكرارات في التشغيل والتأخير بين الطلبات. علاوة على ذلك ، يدعم ساعي البريد تسجيل الطلبات وتخزين المتغيرات وملفات تعريف الارتباط.

    بمجرد إنشاء مجموعة من الطلبات ، يمكن تصديرها إلى ملف لاستخدامه في تطبيق تابع لجهة خارجية. على سبيل المثال ، يدعم Dotcom-Monitor استيراد مجموعة ساعي البريد لاستخدامها في إعداد اختبار المراقبة والتحميل.

    لاحظ أنه في حال كنت بحاجة إلى استدعاء واجهة برمجة تطبيقات تتطلب المصادقة، يجب أن تتضمن مجموعة الطلبات إلى واجهة برمجة التطبيقات هذه طلب POST إلى خدمة المصادقة المقابلة لتفويض العميل على الخادم.

    بالإضافة إلى ميزات Postman الموصوفة، يمكنك تحديد معلمات طلباتك وإضافة نقطة توقف إلى مكالمات واجهة برمجة التطبيقات وإنشاء بيئات مختلفة لطلباتك. لمعرفة المزيد حول العمل مع ساعي البريد، راجع موقع مركز ساعي البريد التعليمي https://learning.postman.com/.

    كيف يمكن أن تساعدك واجهة برمجة تطبيقات ساعي البريد الخاصة ب Dotcom-Monitor

    باستخدام برامج وظائف واجهة برمجة التطبيقات الخاصة بنا ، يمكن لمطوري البرامج التفاعل مع بيانات مراقبة Dotcom-Monitor وتحميل الاختبار والاستفادة من نتائج اختبارات Dotcom-Monitor في تطبيق تابع لجهة خارجية. يتم تكوين تكامل Dotcom-Monitor مع التطبيقات الأخرى من خلال واجهة برمجة تطبيقات REST ، وهي الواجهة التي تسمح لمطوري البرامج بإنشاء البيانات وقراءتها وتحديثها في نظامنا.

    لإعداد التكامل مع خدمات Dotcom-Monitor ، يحتاج المرء إلى استخدام عميل Rest لإنشاء طلبات إلى واجهة برمجة التطبيقات الخاصة بنا. في هذه الحالة ، يوصى باستخدام Postman كعميل Rest لاختبار استدعاءات HTTP إلى واجهة برمجة تطبيقات Dotcom-Monitor بطريقة سهلة وسريعة. بشكل عام ، يتم إجراء الإعدادات الأساسية باستخدام واجهة رسومية لا تتطلب معرفة عميقة بلغات البرمجة أو خبرة في تطوير البرمجيات.

    بمجرد اختبار التكامل ، يمكنك تنفيذ النتائج في عميل Rest مخصص أو استخدام cURL أو المتابعة باستخدام Postman.