هل لدى برونو خادم وهمي؟ (وما البديل المناسب؟)

برونو عميل API خفيف الوزن، مفتوح المصدر، ويعتمد على Git، لذلك يناسب الفرق التي تريد مجموعات طلبات بسيطة وقابلة للمراجعة داخل المستودع. لكن عند الحاجة إلى محاكاة نقطة نهاية غير جاهزة، تظهر الفجوة مباشرة: برونو لا يوفر خادماً وهمياً مدمجاً. في هذا الدليل العملي ستعرف متى تحتاج إلى المحاكاة، ما حدود برونو، وكيف تنشئ خادماً وهمياً من مواصفات OpenAPI بدلاً من كتابة الاستجابات يدوياً.

جرّب Apidog اليوم

الإجابة المختصرة: برونو يستطيع إرسال الطلبات وتشغيل الاختبارات، لكنه لا يستطيع تحويل طلب محفوظ إلى endpoint وهمي يُرجع استجابة عينة. إذا أردت mock server، ستحتاج إلى أداة خارجية أو خادم بسيط تكتبه بنفسك.

لماذا تحتاج إلى خادم وهمي

الخادم الوهمي يرجع استجابات واقعية لنقاط نهاية لم تُبنَ بعد، أو غير مستقرة، أو يصعب تشغيلها في كل مرة. استخدمه عندما تريد:

• تطوير الواجهة الأمامية والجوال بالتوازي: الفريق يستهلك عقد API قبل اكتمال الخلفية.
• اختبار مسارات الأخطاء: مثل 429 أو 503 أو payload ناقص.
• تشغيل عروض ونماذج أولية: بدون قاعدة بيانات أو credentials أو staging server.
• تثبيت اختبارات CI: الاختبارات لا تتوقف بسبب rate limit أو تعطل بيئة staging.

أمثلة حالات يجب أن تختبرها عمداً:

السيناريو	ما يرجعه الخادم الوهمي	لماذا يصعب ذلك بدون محاكاة
تجاوز حد المعدل	429 + رأس Retry-After	لا يمكنك إجبار الخلفية غالباً على التقييد عند الطلب
تعطل الخادم	500 أو 503	لا تريد تعطيل staging فقط للاختبار
استجابة بطيئة	body مؤجل	الكمون الحقيقي يصعب تكراره
نتائج فارغة	200 مع []	يعتمد على حالة بيانات محددة
حمولة مشوهة	body بدون حقل مطلوب	تحقق الخلفية يمنع ذلك غالباً

هل يمتلك برونو خادماً وهمياً؟

لا. برونو يركز على:

• إرسال طلبات API.
• تنظيم المجموعات كملفات عادية داخل Git.
• تشغيل assertions واختبارات.
• إبقاء سير العمل بسيطاً وخفيفاً.

لكنه لا يحتوي على mock server أصلي، ولا يوجد إعداد يحوّل request محفوظاً إلى endpoint مباشر. هذا قرار نطاق، وليس خطأ في الأداة.

في العمل اليومي، أمامك خياران:

1. استخدام أداة محاكاة خارجية
   
   مثل Mockoon أو WireMock أو Prism أو json-server. تعرّف الاستجابات هناك، ثم تضبط برونو لإرسال الطلبات إلى عنوان mock server.

2. كتابة خادم وهمي يدوي
   
   باستخدام Express أو Flask أو FastAPI، ثم ترجع JSON ثابتاً أو مشروطاً.

مثال سريع باستخدام Express:

import express from "express";

const app = express();

app.get("/users/:id", (req, res) => {
  res.json({
    id: req.params.id,
    name: "Ahmed Ali",
    email: "[e-mail]"
  });
});

app.get("/rate-limit", (req, res) => {
  res.set("Retry-After", "60");
  res.status(429).json({
    error: "Too Many Requests"
  });
});

app.listen(3000, () => {
  console.log("Mock server running on http://localhost:3000");
});

هذا مناسب لنقطة أو نقطتين. لكنه يصبح عبئاً عندما تكبر واجهة API.

تكلفة المحاكاة الإضافية

ربط برونو بطبقة محاكاة منفصلة يعمل، لكنه يضيف تكلفة تشغيلية:

• انحراف التعريفات: مواصفات OpenAPI، طلبات برونو، وتعريفات mock قد تعيش في أماكن مختلفة.
• إعداد إضافي للفريق: كل مطور جديد يحتاج لتثبيت وتشغيل أداة محاكاة.
• كتابة payloads يدوياً: كل status code وكل response تحتاج مثالاً.
• بيانات ثابتة أكثر من اللازم: responses مثل "name": "string" لا تكشف أخطاء البيانات الحقيقية.
• صيانة مزدوجة: عند تغيير endpoint يجب تحديث المواصفة، الطلبات، والمحاكاة.

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

أنشئ خادماً وهمياً من مواصفات OpenAPI بدلاً من ذلك

الطريقة الأنظف هي توليد المحاكاة من العقد الذي تملكه بالفعل: مواصفات OpenAPI.

بدلاً من كتابة mock responses في مكان منفصل، يمكنك استيراد أو كتابة المواصفات في Apidog، ثم إنشاء خادم وهمي من نفس التعريفات المستخدمة في التصميم والاختبار والتوثيق.

الفكرة العملية:

1. تكتب endpoint في OpenAPI.
2. تضيف schema للطلب والاستجابة.
3. تستخدم Apidog لتوليد mock URL.
4. توجه الواجهة الأمامية أو الاختبارات إلى mock URL.
5. عند تحديث schema، تتحدث المحاكاة من نفس المصدر.

مثال مبسط لمواصفات OpenAPI:

openapi: 3.0.3
info:
  title: Users API
  version: 1.0.0

paths:
  /users/{id}:
    get:
      summary: Get user by ID
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: User found
          content:
            application/json:
              schema:
                type: object
                required:
                  - id
                  - name
                  - email
                properties:
                  id:
                    type: string
                  name:
                    type: string
                  email:
                    type: string
                    format: email
                  created_at:
                    type: string
                    format: date-time
        "404":
          description: User not found

عند توليد mock من هذا العقد، تحصل على استجابة JSON مطابقة للمخطط بدلاً من بناء server منفصل لكل endpoint.

ما يميز هذا الأسلوب:

• محاكاة من المواصفات: الحقول والأنواع تأتي من OpenAPI.
• بيانات أكثر واقعية: حقل email يمكن أن يظهر كبريد إلكتروني، وcreated_at كتاريخ.
• استجابات ديناميكية: لا تعتمد فقط على مثال ثابت واحد.
• بدون خادم يدوي: لا تحتاج إلى Express أو Flask فقط للمحاكاة.
• مصدر حقيقة واحد: التصميم، المحاكاة، الاختبار، والتوثيق من نفس المشروع.

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

كيفية سريعة: من OpenAPI إلى Mock URL

اتبع هذا المسار العملي:

1. استورد المواصفات
   
   استخدم ملف OpenAPI أو Swagger، أو أدخل رابط المواصفات.

2. راجع endpoints
   
   تأكد أن كل endpoint يحتوي على responses وschemas واضحة.

3. افتح endpoint المطلوب
   
   بما أن schema موجودة، يمكن توليد response وهمي منها.

4. احصل على mock URL
   
   استخدم عنوان المحاكاة الذي يوفره Apidog، سواء للاستخدام المحلي أو السحابي.

5. وجّه العميل إليه
   
   في الواجهة الأمامية، غيّر baseURL إلى عنوان المحاكاة.

مثال:

const api = axios.create({
  baseURL: "https://your-mock-url.example.com"
});

const user = await api.get("/users/123");
console.log(user.data);

1. أضف حالات خاصة عند الحاجة مثلاً response لـ 429 أو 404 أو payload ناقص لاختبار معالجة الأخطاء.

مثال اختبار بسيط:

test("handles rate limit response", async () => {
  const res = await fetch("https://your-mock-url.example.com/rate-limit");

  expect(res.status).toBe(429);
  expect(res.headers.get("Retry-After")).toBeTruthy();
});

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

متى تكون الحلول البديلة كافية؟

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

• لديك endpoint أو اثنان فقط للاختبار المحلي.
• الفريق يريد البقاء بالكامل داخل ملفات برونو.
• response ثابت يكفي ولا تحتاج بيانات متنوعة.
• لديك بالفعل Mockoon أو WireMock أو Prism في سير العمل.
• مصدر الحقيقة الإضافي لا يسبب بطئاً أو أخطاء صيانة.

المقايضة واضحة:

• برونو + أداة محاكاة منفصلة: بسيط كبداية، لكنه يضيف صيانة.
• محاكاة من OpenAPI: تقلل الانحراف، لكنها تعتمد على منصة أوسع.

اختر بناءً على حجم API وعدد الفرق التي تعتمد عليها.

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

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

لا. برونو عميل API لإرسال الطلبات وتشغيل الاختبارات. لا يحتوي على mock server أصلي. لمحاكاة endpoints، استخدم أداة خارجية أو اكتب خادماً وهمياً ووجّه برونو إليه.

ما أسهل طريقة لإضافة المحاكاة إلى سير عمل يشبه برونو؟

استخدم مواصفات OpenAPI كمصدر الحقيقة، ثم ولّد mock server منها. أدوات مثل Apidog تقرأ المواصفات وتوفر mock URL جاهزاً، بدلاً من تعريف الاستجابات في مكان منفصل.

هل يمكنني الاستمرار في استخدام برونو وإضافة خادم محاكاة بجانبه؟

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

متى أكتب mock server يدوياً؟

اكتبه عندما تحتاج تجربة سريعة أو endpoint مؤقتاً. لكن إذا أصبحت تضيف عشرات endpoints أو status codes مختلفة، فالأفضل توليد المحاكاة من OpenAPI لتقليل الصيانة.

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