الهدف
بنهاية هذا الدرس، سيكون الطالب قادرًا على مقارنة بروتوكولات الاتصال في الويب (HTTP, WebSocket, REST, GraphQL) وتحديد الأنسب لكل سيناريو.
شرح الدرس
HTTP/HTTPS: بروتوكول طلب-استجابة. العميل يبادر بالطلب والخادم يرد. أحادي الاتجاه من ناحية المبادرة.
أساليب HTTP الرئيسية:
- GET: قراءة بيانات
- POST: إرسال بيانات جديدة
- PUT/PATCH: تعديل بيانات موجودة
- DELETE: حذف
REST API: نمط تصميم يعتمد HTTP. ثوابته: عديم الحالة، موارد محددة بـ URLs، يستخدم أساليب HTTP القياسية.
GraphQL: بديل لـ REST يتيح للعميل تحديد ما يريده بالضبط — لا زيادة ولا نقصان في البيانات.
WebSocket: اتصال دائم ثنائي الاتجاه — الخادم يُرسل للعميل دون انتظار طلب. مثالي للمحادثات الفورية والألعاب.
كود HTTP الشائعة: 200 (نجاح)، 404 (غير موجود)، 401 (غير مصرح)، 500 (خطأ في الخادم).
أسئلة تدريبية
1. تطبيق رسائل فورية (مثل WhatsApp Web) مقابل موقع أخبار يعرض مقالات. أيهما يستخدم WebSocket وأيهما HTTP العادي؟ وضّح السبب.
عرض الإجابة
المحادثة الفورية: WebSocket — الرسائل تأتي في أي لحظة دون العميل يسأل، فالاتصال الدائم الثنائي ضروري. موقع الأخبار: HTTP — المستخدم يطلب مقالًا (GET)، الخادم يرد، ينتهي الاتصال. لا حاجة لبقاء الاتصال مفتوحًا. فتح آلاف اتصالات WebSocket لقراء المقالات هدر في الموارد.
2. REST API تُرجع قائمة مستخدمين بكل بياناتهم (الاسم، البريد، العنوان، الصورة…) لكن التطبيق يحتاج فقط الاسم والبريد. ما المشكلة؟ وكيف يحلها GraphQL؟
عرض الإجابة
المشكلة: Over-fetching — تُحمَّل بيانات أكثر مما يحتاجه العميل، هدر في عرض النطاق وزمن الاستجابة. GraphQL يحل: العميل يُحدد في الطلب بالضبط: ‘أريد اسم وبريد فقط’ — الخادم يُرجع فقط ما طُلب، لا أقل ولا أكثر.
3. مطوّر يرى كود HTTP 401 عند استدعاء API. ما معناه؟ وكيف يتصرف في التطبيق بناءً على هذا الكود؟
عرض الإجابة
401 يعني: غير مصرح (Unauthorized) — الطلب لم يتضمن بيانات مصادقة صالحة. التصرف في التطبيق: توجيه المستخدم لصفحة تسجيل الدخول تلقائيًا، أو تحديث رمز الجلسة (Token Refresh) إذا انتهت صلاحيته، ثم إعادة الطلب.
4. ما الفرق بين PUT وPATCH في HTTP؟ اضرب مثالًا من تعديل بيانات مستخدم.
عرض الإجابة
PUT: يستبدل المورد بالكامل — ترسل كل بيانات المستخدم، حتى غير المتغيرة. PATCH: يُعدّل جزءًا فقط — ترسل الحقل المتغير وحده. مثال: تغيير البريد الإلكتروني فقط. PATCH ترسل: {“email”: “new@mail.com”}. PUT ترسل: {“name”: “Ahmed”, “email”: “new@mail.com”, “phone”: “01001234567”…}. PATCH أكفأ.
5. ما مبدأ ‘عديم الحالة’ في REST؟ وكيف يؤثر في تصميم الـ API؟
عرض الإجابة
كل طلب يجب أن يحمل كل المعلومات اللازمة لمعالجته — الخادم لا يتذكر الطلبات السابقة. التأثير في التصميم: كل طلب يتضمن رمز المصادقة (Token) في الـ Header. لا يمكن الاعتماد على ‘الجلسة المفتوحة’. الميزة: سهولة التوسع — أي خادم يستطيع معالجة أي طلب دون معرفة ما سبقه.
6. موقع يستخدم AJAX لتحديث جزء من الصفحة دون إعادة تحميل كاملة. اشرح كيف يعمل AJAX من منظور HTTP.
عرض الإجابة
AJAX (Asynchronous JavaScript and XML): JavaScript في المتصفح يُرسل طلب HTTP للخادم في الخلفية (دون تغيير URL أو إعادة تحميل الصفحة)، يستقبل الرد (عادةً JSON حديثًا)، ثم يُحدّث الـ DOM (جزء الصفحة) بالبيانات الجديدة. المستخدم يرى التحديث فوريًا. مثال: تحديث عدد الإعجابات دون إعادة تحميل الصفحة.
7. ما الـ CORS (Cross-Origin Resource Sharing)؟ ولماذا ينتج عنه خطأ أحيانًا عند استدعاء API من نطاق مختلف؟
عرض الإجابة
CORS: سياسة أمنية في المتصفح تمنع JavaScript في صفحة من نطاق (example.com) من طلب بيانات من نطاق آخر (api.othersite.com) دون إذن صريح. الخطأ: يحدث حين الخادم لا يُدرج Header يسمح للنطاق الطالب (Access-Control-Allow-Origin). الحل: الخادم يُضيف هذا الـ Header للسماح للنطاقات المحددة أو للجميع.
8. ما الـ Webhook؟ وكيف يختلف عن استدعاء API عادي؟
عرض الإجابة
API عادي: أنت تسأل (Pull) — ترسل طلبًا وتنتظر ردًا. Webhook: الخادم يُخبرك (Push) — عند حدوث حدث معين يُرسل إشعارًا تلقائيًا لعنوان URL تحدده. مثال: Stripe يُرسل Webhook لموقعك حين يُكمل العميل الدفع — لا تحتاج أن تسأل ‘هل اكتمل الدفع؟’ كل ثانية.
9. ما الفرق بين زمن الاستجابة (Latency) وعرض النطاق (Bandwidth)؟ وأيهما يؤثر أكثر على تجربة المحادثة الفورية؟
عرض الإجابة
Latency: وقت وصول أول بايت (ميلي ثانية). Bandwidth: كمية البيانات في الثانية (Mbps). المحادثة الفورية: Latency يؤثر أكثر — رسالة نصية صغيرة جدًا لكن يجب أن تصل فورًا. تأخر 500ms ملحوظ جدًا في المحادثة. بينما تحميل ملف كبير: Bandwidth يهم أكثر من Latency.
10. يقول مطوّر: ‘REST API أفضل دائمًا من GraphQL.’ هل هذا صحيح؟ متى يكون كل منهما الأنسب؟
عرض الإجابة
ليس صحيحًا مطلقًا. REST أنسب: للـ APIs البسيطة بموارد محددة، حيث Over-fetching مشكلة صغيرة، وللفرق التي تعرفه جيدًا. GraphQL أنسب: تطبيقات معقدة تجلب بيانات من مصادر متعددة (مثل Facebook)، تطبيقات الموبايل حيث عرض النطاق ثمين، وحين كل عميل يحتاج بيانات مختلفة من نفس الـ API.
11. ما الـ Rate Limiting في APIs؟ ولماذا تُطبّقه شركات مثل Google وTwitter على مطوّري الـ API؟
عرض الإجابة
Rate Limiting: تحديد عدد الطلبات المسموحة لكل مستخدم أو مفتاح API في فترة زمنية معينة (مثل 1000 طلب/ساعة). السبب: (1) حماية الخادم من الإغراق (هجوم DDoS مقصود أو عرضي). (2) ضمان توزيع عادل للموارد بين المطوّرين. (3) تشجيع الاستخدام الفعّال — المطوّر يُفكر قبل إرسال كل طلب.
12. أنت تبني API لتطبيق توصيل. ما الـ Endpoints (نقاط النهاية) الأساسية التي تحتاجها؟ وما أسلوب HTTP الأنسب لكل منها؟
عرض الإجابة
POST /orders — إنشاء طلب جديد. GET /orders/{id} — عرض تفاصيل طلب. PUT /orders/{id}/status — تحديث حالة الطلب. GET /restaurants — قائمة المطاعم. GET /restaurants/{id}/menu — قائمة طعام مطعم. DELETE /orders/{id} — إلغاء طلب. نمط REST: موارد كاسماء في URL، والفعل يُحدده أسلوب HTTP.