إنتقل إلى المحتوى الرئيسي

إنشاء خادم وهمي لـ Postman

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

المتطلبات الأساسية​

  • Postman (إصدار سطح المكتب أو الويب).

  • ثلاثة ملفات JSON مضمنة في هذا المشروع:

    الملفالغرض
    DataPipeline-Environment.jsonيحدد المتغيرات القابلة لإعادة الاستخدام: dd_site وmock_base_url وdd_api_key.
    DataPipeline-postman-collection.jsonيرسل طلبات حقيقية إلى واجهة برمجة تطبيقات استيعاب سجلات Datadog (/api/v2/logs).
    DataPipeline-MockServer-Collection.jsonيهيئ استجابات وهمية لنقاط النهاية نفسها باستخدام خادم وهمي لـ Postman.

قم بتنزيل الملفات الثلاثة: تنزيل ملفات Postman.

1. استيراد الملفات إلى Postman​

  1. افتح Postman وانقر على استيراد.
  2. حدد جميع ملفات JSON الثلاثة التي تم تنزيلها دفعة واحدة.
  3. من قائمة البيئة في أعلى اليمين، حدد بيئة خط أنابيب البيانات.

بعد استيراد الملفات، تظهر العناصر التالية:

  • مشروع وثائق خط أنابيب البيانات (مجموعة API حقيقية).
  • خط أنابيب البيانات — مجموعة الخادم الوهمي.
  • بيئة خط أنابيب البيانات.

2. إنشاء الخادم الوهمي​

  1. في Postman، انتقل إلى الخوادم الوهمية في الشريط الجانبي الأيسر.
  2. انقر على إنشاء خادم وهمي.
  3. حدد خط أنابيب البيانات — مجموعة الخوادم الوهمية.
  4. احتفظ بالإعدادات الافتراضية وانقر على إنشاء خادم وهمي.

يقوم Postman بإنشاء عنوان خادم وهمي فريد، على سبيل المثال: https://a12b34cd-1234-5678.mock.pstmn.io

3. تحديث متغير البيئة​

  1. انتقل إلى Environments > Data Pipeline Environment.
  2. ابحث عن متغير mock_base_url.
  3. استبدل العنصر النائب بعنوان الخادم الوهمي الذي تم إنشاؤه:
# قبل
https://mock-server-url-from-postman.io

# بعد
https://a12b34cd-1234-5678.mock.pstmn.io
  1. احفظ البيئة.

4. أرسل أول طلب وهمي​

  1. افتح POST /api/v2/logs داخل مجموعة الخادم الوهمي.
  2. تأكد من أن بيئة خط أنابيب البيانات نشطة في القائمة العلوية اليمنى.
  3. انقر على إرسال.

يعرض الخادم الوهمي استجابة محاكاة 202 Accepted، مما يعكس استجابة Datadog الحقيقية: HTTP/1.1 202 Accepted

ملاحظة: تعرض واجهة برمجة تطبيقات استيعاب سجلات Datadog الحقيقية استجابة 202 Accepted بدون نص الاستجابة. تعرض المجموعة الوهمية كائن JSON بسيط لتسهيل القراءة أثناء الاختبار:

{
  "status": "accepted",
  "message": "Log event received by mock server."
}

5. اختبار استجابة الخطأ​

لاختبار استجابة 400 bad request، قم بإزالة حقل message من نص الطلب. هذا الحقل مطلوب في واجهة برمجة تطبيقات استيعاب سجلات Datadog.

يعرض الخادم الوهمي JSON التالي:

{
  "errors": ["Invalid JSON"]
}

يمكنك أيضًا اختبار استجابة 401 unauthorized عن طريق إزالة رأس DD-API-KEY من الطلب.

6. التبديل بين الاختبار المباشر والاختبار الوهمي​

تستخدم كلتا المجموعتين نفس ملف البيئة. للتبديل بين الاختبار الحقيقي والاختبار الوهمي ، قم بتغيير المجموعة التي تستخدمها:

الهدفالمجموعةمتغير العنوان الأساسي
الاختبار باستخدام Datadog الحقيقيDataPipeline-postman-collection.json{{dd_site}} → datadoghq.com
الاختبار محليًا أو دون اتصال بالإنترنتDataPipeline-MockServer-Collection.json{{mock_base_url}} → عنوانك الوهمي

يتيح لك هذا النهج التحقق من تنسيقات الطلبات والاستجابات قبل إرسال البيانات الحية إلى حساب Datadog الخاص بك.

تصور تدفق الطلبات​

تدفق طلبات خادم Postman الوهمي

لماذا هذا مهم​

يوضح إعداد الخادم الوهمي هذا نفس نمط التحقق الذي تستخدمه عند تطوير أو توثيق تكامل API حقيقي:

  • تحقق من بنية الطلب والرؤوس المطلوبة (DD-API-KEY، Content-Type) قبل إرسال حركة المرور الحية.
  • تأكد من أن حمولات JSON تتطابق مع المخطط المتوقع — مصفوفة من كائنات السجل، كل منها يحتوي على حقل message.
  • اختبر معالجة الأخطاء (400، 401، 429) دون استهلاك حصة واجهة برمجة التطبيقات أو تلويث فهرس سجل الإنتاج.
  • تطوير أمثلة التوثيق والتحقق منها مقابل نقطة نهاية مستقرة وقابلة للتكرار.

ينطبق النمط نفسه عند توثيق مجموعة أدوات تطوير البرامج (SDK) لـ Galileo. يمكنك اختبار الوظائف المُجهزة في دفق سجل dev قبل ترقيتها إلى production، مع التأكد من تكوين مقاييس التقييم بشكل صحيح قبل تدفق حركة مرور المستخدمين الحقيقية.