DEV Community

Cover image for ما هو واجهة برمجة تطبيقات وهمية؟ شرح واضح ومبسط
Yusuf Khalidd
Yusuf Khalidd

Posted on • Originally published at apidog.com

ما هو واجهة برمجة تطبيقات وهمية؟ شرح واضح ومبسط

واجهة برمجة التطبيقات الوهمية (Mock API) هي واجهة مزيفة تتصرف مثل واجهة حقيقية: تقبل نفس الطلبات، وتُرجع استجابات بنفس الشكل، وتعمل عبر عنوان URL يمكنك استدعاؤه. الفرق أن ما خلف هذا العنوان ليس قاعدة بيانات أو منطق عمل أو خدمة فعلية؛ بل استجابة قمت بتعريفها مسبقًا.

جرّب Apidog اليوم

الفائدة العملية من Mock API هي أنك تستطيع بناء الواجهة الأمامية، كتابة الاختبارات، وتجربة حالات الخطأ قبل أن تكون الخدمة الحقيقية جاهزة، أو عندما تكون بطيئة، مكلفة، أو غير مستقرة للاستخدام المتكرر.

ما هي واجهة برمجة التطبيقات الوهمية (Mock API) عمليًا؟

بأبسط صورة، الواجهة الوهمية هي خريطة من طلب إلى استجابة:

  1. يصل طلب HTTP.
  2. تتم مطابقته مع قواعد حددتها مسبقًا.
  3. تُرجع الواجهة استجابة مناسبة.

مثال:

GET /users/1001
Enter fullscreen mode Exit fullscreen mode

يرجع:

{
  "id": "1001",
  "name": "Sara Ahmed",
  "email": "sara@example.com"
}
Enter fullscreen mode Exit fullscreen mode

لا يتم جلب هذا المستخدم من قاعدة بيانات. الاستجابة معرفة مسبقًا أو مولدة وفق قاعدة.

تتكون Mock API عادة من ثلاثة أجزاء:

  • الواجهة: المسارات، الطرق، المعاملات، والرؤوس.
  • تعريف الاستجابة: جسم الاستجابة، رمز الحالة، والرؤوس.
  • منطق المطابقة: كيف تختار الواجهة الاستجابة المناسبة لكل طلب.

مثال عملي لقواعد بسيطة:

GET /users/1001  -> 200 OK
GET /users/404   -> 404 Not Found
POST /users      -> 201 Created
Enter fullscreen mode Exit fullscreen mode

لأن الواجهة الوهمية تستخدم نفس العقد الذي ستستخدمه الواجهة الحقيقية، يستطيع العميل تبديل baseURL فقط:

const api = axios.create({
  baseURL: process.env.API_BASE_URL
});
Enter fullscreen mode Exit fullscreen mode

أثناء التطوير:

API_BASE_URL=https://mock.example.com
Enter fullscreen mode Exit fullscreen mode

وفي الإنتاج:

API_BASE_URL=https://api.example.com
Enter fullscreen mode Exit fullscreen mode

لإنشاء واحدة خطوة بخطوة، راجع هذا الدليل حول إنشاء واجهة برمجة تطبيقات وهمية للاختبار.

ما ليست عليه Mock API

من المهم عدم خلط Mock API مع مفاهيم قريبة:

  • ليست Cache: التخزين المؤقت يحتفظ باستجابات حقيقية، أما الواجهة الوهمية فتُرجع استجابات مصطنعة.
  • ليست Sandbox: بيئة الاختبار الخاصة بالمورد قد تشغل منطقًا حقيقيًا مبسطًا، بينما الواجهة الوهمية لا تشغل منطق العمل الحقيقي.
  • ليست Staging: بيئة التجهيز هي نشر كامل أو شبه كامل للنظام الحقيقي.

Mock API أخف من كل ذلك: نقطة HTTP أمامية مع استجابات محددة مسبقًا.

Mock مقابل Stub

في الاختبار، يستخدم المطورون مصطلحي mock وstub أحيانًا بالتبادل، لكن الفرق مهم.

Stub يُرجع قيمة جاهزة فقط:

function getUserStub() {
  return {
    id: "1001",
    name: "Sara Ahmed"
  };
}
Enter fullscreen mode Exit fullscreen mode

لا يهتم stub بعدد مرات استدعائه أو بالوسائط التي استُخدم بها.

أما Mock فيمكنه أيضًا التحقق من التفاعل:

expect(api.getUser).toHaveBeenCalledWith("1001");
expect(api.getUser).toHaveBeenCalledTimes(1);
Enter fullscreen mode Exit fullscreen mode

الخلاصة:

  • stub يجيب.
  • mock يجيب ويراقب.

في تطوير واجهات برمجة التطبيقات، مصطلح Mock API غالبًا يشمل الاثنين: استجابات جاهزة، وأحيانًا تحقق من الطلبات. للمزيد من المصطلحات، راجع الفرق بين التحقق من الصحة والتحقق.

هناك مصطلحان آخران قريبان:

  • Fake: تطبيق مبسط يعمل فعلًا، مثل قاعدة بيانات في الذاكرة.
  • Spy: يلف كائنًا حقيقيًا ويسجل كيف تم استدعاؤه دون تغيير سلوكه.

في سياق HTTP، Mock API هي غالبًا stub عبر URL حقيقي مع تحقق اختياري.

Mock API مقابل خادم حقيقي

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

Mock API خادم حقيقي
خلف نقطة النهاية استجابات محددة مسبقًا منطق حي وقاعدة بيانات
مصدر الاستجابة قواعد كتبتها أنت تُحسب لكل طلب
البيانات ثابتة أو مُولَّدة حقيقية ومستمرة
الآثار الجانبية لا شيء كتابة بيانات، مدفوعات، رسائل بريد إلكتروني
السرعة سريعة وثابتة تتغير حسب الحمل
الدقة تطابق ما عرّفته تطابق السلوك الفعلي

الخادم الحقيقي يثبت أن النظام يعمل فعليًا، لكنه قد يكون بطيئًا، يحتفظ بالحالة، وينتج آثارًا جانبية. اختبار خاطئ قد يرسل بريدًا إلكترونيًا أو ينشئ طلبًا حقيقيًا.

الخادم الوهمي سريع وآمن وقابل للتنبؤ، لذلك يناسب:

  • التطوير المحلي.
  • اختبارات الواجهة الأمامية.
  • اختبارات حالات الخطأ.
  • العروض التوضيحية.

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

الواجهات الوهمية الثابتة والديناميكية

هناك نوعان شائعان من Mock API: ثابتة وديناميكية.

1. واجهة وهمية ثابتة

تُرجع نفس الاستجابة لكل طلب مطابق.

مثال:

{
  "id": "user_1001",
  "name": "Sara Ahmed",
  "email": "sara@example.com"
}
Enter fullscreen mode Exit fullscreen mode

مناسبة عندما تريد اختبارًا قابلًا للتكرار:

test("يعرض اسم المستخدم", async () => {
  const user = await getUser("user_1001");
  expect(user.name).toBe("Sara Ahmed");
});
Enter fullscreen mode Exit fullscreen mode

استخدمها في:

  • اختبارات الوحدات.
  • اختبارات snapshot.
  • الحالات التي تحتاج فيها قيمة معروفة بدقة.

عيبها أنها لا تكشف بسهولة مشاكل مثل:

  • نصوص طويلة جدًا.
  • مصفوفات فارغة.
  • قيم null.
  • حقول ناقصة.

2. واجهة وهمية ديناميكية

تُنشئ الاستجابة لكل طلب.

بدلًا من:

{
  "id": "user_1001"
}
Enter fullscreen mode Exit fullscreen mode

يمكن أن تُرجع في كل مرة:

{
  "id": "7e3c9b8e-5f4a-4c21-91a2-91e4c2e5a111",
  "name": "Omar Khaled",
  "email": "omar.khaled@example.com",
  "created_at": "2026-05-22T10:30:00Z"
}
Enter fullscreen mode Exit fullscreen mode

عادة تُستخدم مولدات بيانات مثل Faker.js، بحيث ينتج الحقل email بريدًا إلكترونيًا، وينتج created_at تاريخًا.

استخدمها في:

  • التطوير اليومي.
  • العروض التوضيحية.
  • اختبار تنوع البيانات.
  • كشف الحالات الهامشية.

لكن احذر: البيانات المتغيرة تجعل التأكيدات الصارمة أصعب. بدلًا من اختبار قيمة محددة، اختبر الشكل:

expect(user.email).toMatch(/@/);
expect(user.id).toBeDefined();
expect(new Date(user.created_at).toString()).not.toBe("Invalid Date");
Enter fullscreen mode Exit fullscreen mode

واجهات وهمية مشروطة

الواجهة الوهمية تصبح أكثر فائدة عندما تتفرع حسب الطلب.

مثال قواعد:

GET /orders/123      -> 200 OK
GET /orders/404      -> 404 Not Found
GET /orders/500      -> 500 Internal Server Error
Authorization مفقود -> 401 Unauthorized
Enter fullscreen mode Exit fullscreen mode

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

مثال في كود الواجهة الأمامية:

async function loadOrder(id) {
  try {
    const res = await fetch(`/orders/${id}`);

    if (res.status === 404) {
      return { error: "الطلب غير موجود" };
    }

    if (!res.ok) {
      return { error: "حدث خطأ في الخادم" };
    }

    return await res.json();
  } catch {
    return { error: "تعذر الاتصال بالخادم" };
  }
}
Enter fullscreen mode Exit fullscreen mode

باستخدام Mock API، تستطيع اختبار كل فرع:

/orders/123  -> يعرض الطلب
/orders/404  -> يعرض رسالة غير موجود
/orders/500  -> يعرض رسالة خطأ
Enter fullscreen mode Exit fullscreen mode

أين تستخدم Mock API في دورة التطوير؟

استخدم Mock API في ثلاث مراحل رئيسية.

1. قبل جاهزية الخلفية

يتفق فريقا الواجهة الأمامية والخلفية على العقد:

GET /products/{id}
Enter fullscreen mode Exit fullscreen mode

استجابة متوقعة:

{
  "id": "p_1001",
  "name": "Keyboard",
  "price": 120
}
Enter fullscreen mode Exit fullscreen mode

بعدها يستطيع فريق الواجهة الأمامية تنفيذ الشاشة دون انتظار API الحقيقي.

2. أثناء الاختبار

بدل الاعتماد على الشبكة والخادم الحقيقي، استخدم Mock API لتثبيت النتائج:

test("يعرض رسالة عند فشل تسجيل الدخول", async () => {
  mock.post("/login").reply(401, {
    message: "بيانات الدخول غير صحيحة"
  });

  const result = await login("wrong@example.com", "bad-password");

  expect(result.message).toBe("بيانات الدخول غير صحيحة");
});
Enter fullscreen mode Exit fullscreen mode

3. أثناء العروض والنماذج الأولية

لا تجعل العرض التجريبي يعتمد على خدمة قد تفشل أو بيانات قد تتغير. Mock API تعطيك بيانات يمكن التنبؤ بها.

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

كيف تمنع انجراف Mock API؟

الخطر الأكبر هو الانجراف: الواجهة الحقيقية تتغير، لكن الواجهة الوهمية تبقى قديمة.

مثال:

الإصدار القديم:

{
  "id": "1001",
  "name": "Sara Ahmed"
}
Enter fullscreen mode Exit fullscreen mode

الإصدار الجديد:

{
  "id": "1001",
  "full_name": "Sara Ahmed"
}
Enter fullscreen mode Exit fullscreen mode

إذا بقيت Mock API تُرجع name، ستنجح اختباراتك بينما يفشل التطبيق أمام الخادم الحقيقي.

الحل: لا تكتب الواجهة الوهمية يدويًا كلما أمكن. اجعلها مشتقة من نفس المخطط أو المواصفة التي تستخدمها الواجهة الحقيقية.

تدفق عملي:

  1. عرّف العقد باستخدام OpenAPI أو أداة تصميم API.
  2. ولّد الوثائق من نفس العقد.
  3. ولّد Mock API من نفس العقد.
  4. شغّل اختبارات عقد دورية ضد الخادم الحقيقي.

بهذا يصبح تغيير العقد مرئيًا في كل مكان.

يعمل Apidog بهذا الأسلوب: تصمم واجهة برمجة التطبيقات مرة واحدة، ثم تُنشأ نقطة النهاية الوهمية من التصميم نفسه مع بيانات واقعية مستنتجة من أسماء الحقول. الواجهة الوهمية، الوثائق، واختبار عقد واجهة برمجة التطبيقات تقرأ من مصدر واحد، لذلك تبقى متوافقة. لرؤية تدفق التصميم إلى الواجهة الوهمية عمليًا، قم بتنزيل Apidog.

قائمة تحقق سريعة لاستخدام Mock API

قبل اعتماد Mock API في مشروعك، تحقق من الآتي:

  • هل تستخدم نفس المسارات والطرق التي ستستخدمها API الحقيقية؟
  • هل رموز الحالة واقعية؟ مثل 200, 201, 400, 401, 404, 500.
  • هل تغطي المسار السعيد وحالات الفشل؟
  • هل توجد بيانات null ومصفوفات فارغة وقيم طويلة؟
  • هل يمكن تبديل baseURL بسهولة بين mock وproduction؟
  • هل الواجهة الوهمية مولدة من نفس العقد أو المخطط؟
  • هل لديك اختبارات عقد ضد الخادم الحقيقي لمنع الانجراف؟

الأسئلة الشائعة

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

هي واجهة API مزيفة تحاكي واجهة حقيقية. تكشف نفس المسارات وتُرجع استجابات بنفس الشكل، لكن لا يوجد منطق حقيقي أو قاعدة بيانات خلفها. الاستجابات محددة مسبقًا أو مولدة.

ما الفرق بين Mock وStub؟

stub يُرجع استجابة جاهزة فقط. أما mock فيمكنه أيضًا التحقق من طريقة الاستدعاء، مثل عدد مرات الاستدعاء والوسائط المستخدمة. باختصار: stub يجيب، وmock يجيب ويراقب.

كيف تختلف Mock API عن الخادم الحقيقي؟

Mock API تُرجع استجابات محددة مسبقًا بدون منطق حقيقي أو آثار جانبية. الخادم الحقيقي يشغل منطق التطبيق ويتعامل مع قاعدة بيانات وحالة فعلية. استخدم Mock API للتطوير والاختبارات المعزولة، واستخدم الخادم الحقيقي لاختبارات العقد والاختبارات الشاملة.

هل أستخدم واجهة وهمية ثابتة أم ديناميكية؟

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

كيف أمنع Mock API من أن تصبح غير دقيقة؟

ولّدها من نفس المخطط أو مواصفة API التي تستخدمها الخدمة الحقيقية. عند تغيير العقد، أعد توليد الواجهة الوهمية. أضف اختبارات عقد دورية ضد الخادم الحقيقي لاكتشاف أي انجراف مبكرًا.

Top comments (0)