Frontend وBackend: تتبّع طلباً واحداً داخل مشروعك

تضغط «تأكيد الحجز»، فتظهر لك رسالة نجاح. بين الضغط والرسالة يمر الطلب بالواجهة والخادم وقاعدة البيانات، ولكل منها عمل مختلف. سنتتبع حجز جهاز مختبر لنرى أين تُفحص المدخلات والصلاحيات والتعارضات، ومتى يصبح من الصحيح إخبار المستخدم أن الحجز حُفظ. يمكن تنفيذ هذا المسار داخل تطبيق واحد أو عبر واجهة تتصل بـAPI؛ توزيع المسؤوليات هو ما يهمنا هنا.

من النموذج إلى الطلب

يختار المستخدم الجهاز والفترة، ثم يضغط «تأكيد الحجز». تعرض الواجهة أخطاء إدخال مفهومة قبل الإرسال، مثل تاريخ غير مكتمل، لكن فحصها لا يغني عن الخادم؛ إذ يستطيع أي عميل إرسال طلب HTTP مباشرة. يمكن لخادم واحد أن يولد HTML ويستقبل النموذج، أو تستدعي الواجهة API عبر JavaScript. توزيع المسؤوليات أهم من شكل الملفات.

POST /api/bookings
Content-Type: application/json

{
  "deviceId": 12,
  "startsAt": "2026-11-01T09:00:00+03:00",
  "endsAt": "2026-11-01T10:00:00+03:00"
}

لا يرسل المثال رقم المستخدم لتحديد مالك الحجز؛ يستنتج الخادم هويته من جلسة مصادَق عليها. ولو تضمن عقد الواجهة حقلاً للمالك لغرض إداري، فعلى الخادم التحقق من صلاحية إسناد الحجز إلى غير المستخدم الحالي. البيانات القادمة من المتصفح طلب للتحقق، وليست إثباتاً لامتلاك الصلاحية.

ماذا يراجع الخادم؟

1. التحقق من هوية المستخدم وصلاحيته لإنشاء الحجز.
2. قراءة JSON ورفض الحقول أو القيم المخالفة للعقد.
3. تفسير التوقيت بوضوح، والتحقق أن النهاية بعد البداية.
4. التحقق من وجود الجهاز وإتاحته وعدم تعارض الفترة مع حجز أو صيانة.
5. حفظ العملية بطريقة تحافظ على الاتساق إذا وصل طلب آخر بالتزامن.
6. إرجاع استجابة محددة دون كشف تفاصيل داخلية غير لازمة.

فحص التعارض ثم الحفظ كعمليتين غير محميتين قد يسمح بمرور طلبين يريان الفترة فارغة في اللحظة نفسها. طريقة المعالجة تعتمد قاعدة البيانات وطبيعة نموذج الحجز: معاملات وعزل مناسب أو قيود تمثل قاعدة العمل. لذلك لا يكفي أن يعمل المثال عند الضغط ببطء من نافذة واحدة.

ما الذي تحفظه قاعدة البيانات؟

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

بعد نجاح الحفظ يمكن أن يعيد الخادم 201 Created مع تمثيل الحجز. الاستجابة التالية مثال عقد، ولا تتضمن نتيجة من نظام قائم:

{
  "id": 801,
  "deviceId": 12,
  "status": "confirmed",
  "startsAt": "2026-11-01T09:00:00+03:00",
  "endsAt": "2026-11-01T10:00:00+03:00"
}

كيف تتعامل الواجهة مع الاستجابة؟

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

async function readJsonResponse(response) {
  const contentType = response.headers.get("content-type") || "";
  const payload = contentType.includes("application/json")
    ? await response.json()
    : null;
  if (!response.ok) {
    const error = new Error(payload?.message || "تعذر إتمام الطلب");
    error.status = response.status;
    throw error;
  }
  return payload;
}

هذا المقطع يعالج استجابة وصلت بالفعل؛ يجب أن يعالج المستدعي أيضاً أخطاء الشبكة والإلغاء. وتوضح وثائق Fetch أن الحصول على استجابة 404 أو 500 لا يرفض الوعد تلقائياً، ولذلك يلزم فحص الحالة. لا تفترض أن جميع الاستجابات JSON، خصوصاً عند فشل وسيط الاستضافة.

جدول المسؤوليات يساعدك في الاختبار

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

عند فشل الطلب، تابع خطوات تشخيص API لتعرف أين توقف. ويربط مثال قاعدة البيانات الحجز بجداوله وقيوده. هذه التفاصيل مفيدة أيضاً عند طلب تطوير مشروع برمجي، لأنها توضح ما يجب أن تنفذه الواجهة وما يجب أن يتحقق منه الخادم.