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

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

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

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

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

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

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

من المفيد أن نكون دقيقين بشأن ما ليست واجهة برمجة التطبيقات الوهمية. إنها ليست ذاكرة تخزين مؤقتة (cache)، لأن ذاكرة التخزين المؤقتة تخزن استجابات حقيقية بينما الواجهة الوهمية تخترعها. وهي ليست بيئة اختبار (sandbox)، لأن بيئة اختبار المورد تشغل منطقًا حقيقيًا مبسطًا بينما لا تشغل الواجهة الوهمية أي منطق على الإطلاق. وهي ليست بيئة تجهيز (staging environment)، لأن بيئة التجهيز هي نشر كامل للنظام الحقيقي. الواجهة الوهمية أخف من الثلاثة: إنها مجرد الباب الأمامي لواجهة برمجة تطبيقات مع إجابات محددة مسبقًا خلفها، ولا شيء آخر.

واجهة وهمية (Mock) مقابل عنصر مؤقت (Stub)

يستخدم الناس مصطلحي "mock" و "stub" بالتبادل، لكنهما في الاختبار يعنيان أشياء مختلفة.

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

الواجهة الوهمية (mock)، بالمعنى الدقيق للاختبار، تتحقق أيضًا من التفاعل. يمكنها تأكيد أنه تم استدعاؤها، وكم مرة، وبأية وسائط. يمكن أن تُفشل الواجهة الوهمية اختبارك لأن الاستدعاء كان خاطئًا، وليس فقط توفير قيمة.

في عمل واجهة برمجة التطبيقات اليومي، يكون الخط الفاصل غير واضح، وعادة ما تغطي "واجهة برمجة التطبيقات الوهمية" كلاهما. الفائدة المستخلصة: العنصر المؤقت (stub) يجيب، والواجهة الوهمية (mock) تجيب وتراقب. عندما يهتم اختبارك فقط بالبيانات التي يتلقاها الكود الخاص بك، فإن الاستجابة بأسلوب العنصر المؤقت تكون كافية. عندما يهتم بما إذا كان الكود الخاص بك قد أجرى الاستدعاء الصحيح بالطريقة الصحيحة، فأنت تريد التحقق الذي تضيفه واجهة وهمية حقيقية. للمزيد من المصطلحات، راجع الفرق بين التحقق من الصحة والتحقق.

يوجد مصطلحان آخران قريبين. الزائف (fake) هو تطبيق عامل ولكنه مبسط، مثل قاعدة بيانات في الذاكرة تستخدم بدلاً من قاعدة بيانات حقيقية؛ لديها منطق، ولكن أقل. الجاسوس (spy) يلف كائنًا حقيقيًا ويسجل كيف تم استدعاؤه دون تغيير سلوكه. واجهة برمجة التطبيقات الوهمية (mock API)، كما يستخدم المصطلح في تطوير واجهات برمجة التطبيقات، هي الأقرب إلى العنصر المؤقت (stub) مع تحقق اختياري، يتم تقديمها عبر HTTP على عنوان URL حقيقي. لا تحتاج إلى مراقبة المصطلحات، ولكن معرفة النطاق يساعدك على قراءة وثائق الاختبار دون أن تضل.

واجهة برمجة تطبيقات وهمية (Mock API) مقابل خادم حقيقي

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

يخبرك الخادم الحقيقي بالحقيقة: فهو يشغل الكود الفعلي ويثبت أن النظام يعمل. كما أنه بطيء، ويحتفظ بالحالة (stateful)، وقادر على إحداث آثار جانبية حقيقية، لذا فإن اختبارًا ضده يمكن أن يؤدي إلى خصم من بطاقة أو إرسال بريد إلكتروني.

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

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

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

تُرجع الواجهة الوهمية الثابتة حمولة ثابتة. تكتب JSON الدقيق مرة واحدة، ويحصل كل طلب مطابق على نفس النص الأساسي. الواجهات الوهمية الثابتة قابلة للتنبؤ، مما يجعلها سهلة التأكيد عليها. نقطة ضعفها هي الواقعية: حمولة واحدة مشفرة بشكل ثابت لن تكشف عن خطأ في الكود الذي يتعطل عند السلاسل الطويلة، أو المصفوفات الفارغة، أو القيم الفارغة غير المتوقعة (nulls).

تُنشئ الواجهة الوهمية الديناميكية الاستجابة لكل طلب. فبدلاً من `\"id\": \"user_1001\"` الثابت، تنتج UUID جديدًا في كل استدعاء. وبدلاً من اسم واحد، تُرجع اسمًا واقعيًا مختلفًا في كل مرة. عادةً ما تعتمد الواجهات الوهمية الديناميكية على قواعد توليد البيانات مثل Faker.js، بحيث ينتج حقل باسم `email` بريدًا إلكترونيًا وينتج `created_at` تاريخًا. إنها أكثر واقعية وأفضل في الكشف عن الحالات الهامشية (edge cases)، على حساب كونها أصعب في التأكيد عليها بدقة.

تستخدم معظم الفرق كلاهما. واجهات وهمية ثابتة لاختبارات الوحدات الكثيفة التأكيد حيث تحتاج إلى قيمة معروفة واحدة. واجهات وهمية ديناميكية للتطوير، والعروض التوضيحية، والتغطية بأسلوب "fuzz" حيث تكون التنوع أهم من الإجابة الثابتة.

يمكن أن تكون الواجهة الوهمية الديناميكية مشروطة أيضًا، وهي خطوة تتجاوز التوليد البسيط. تتفرع الواجهة الوهمية المشروطة بناءً على الطلب: طلب لـ `/orders/404` يُرجع `404`، وطلب مع رمز مميز خاطئ يُرجع `401`، وكل شيء آخر يُرجع `200` عادي. بذلك تغطي نقطة نهاية وهمية واحدة المسار السعيد وعدة مسارات فشل في آن واحد. هذا ما يجعل الواجهة الوهمية مفيدة حقًا للاختبار، لأنها يمكن أن تعيد إنتاج استجابات الأخطاء التي لن ينتجها الخادم الحقيقي السليم عند الطلب.

مكانة واجهة برمجة التطبيقات الوهمية في التطوير

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

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

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

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

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

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

ما الفرق بين الواجهة الوهمية (mock) والعنصر المؤقت (stub)؟

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

كيف تختلف واجهة برمجة التطبيقات الوهمية عن الخادم الحقيقي؟

تُرجع الواجهة الوهمية استجابات محددة مسبقًا بدون أي عمليات حسابية حقيقية، لذا فهي سريعة، وقابلة للتنبؤ، وليس لها آثار جانبية. يدير الخادم الحقيقي منطقًا فعليًا مقابل قاعدة بيانات حقيقية، لذا فهو أبطأ ويحتفظ بالحالة (stateful) ولكنه يثبت أن النظام يعمل بالفعل. استخدم واجهة وهمية للتطوير، والخادم الحقيقي لاختبارات العقود والاختبارات الشاملة (end-to-end).

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

استخدم واجهة وهمية ثابتة عندما تحتاج إلى قيمة واحدة قابلة للتنبؤ للتأكيد عليها، وهذا يناسب اختبارات الوحدات. استخدم واجهة وهمية ديناميكية عندما تريد بيانات واقعية ومتنوعة تكتشف الحالات الهامشية (edge cases)، وهذا يناسب التطوير والعروض التوضيحية. تستخدم العديد من الفرق كلاهما.

كيف أمنع واجهة برمجة التطبيقات الوهمية من أن تصبح غير دقيقة؟

قم بتوليد الواجهة الوهمية من نفس المخطط (schema) الذي تنشره واجهة برمجة التطبيقات الحقيقية بدلاً من كتابتها يدويًا. عندما يتغير العقد، تتم إعادة توليد الواجهة الوهمية. دعمها باختبارات عقود مجدولة ضد واجهة برمجة التطبيقات الحقيقية يكتشف أي انجراف متبقٍ مبكرًا.