What Happens When You Open a Website? — إيه اللي بيحصل لما بتفتح موقع؟
رحلة الـ Request من البداية لحد النهاية
كل مرة بتضغط على لينك أو بتكتب URL في المتصفح، بيحصل تسلسل محدد من الخطوات. ده اللي بنسميه الـ Request-Response Cycle.
Client & Server — طرفا المحادثة
مين بيطلب ومين بيرد؟
- عادةً المتصفح (Browser) أو تطبيق الموبايل
- هو اللي بيبدأ المحادثة بإرسال الـ Request
- وظيفته يعرض HTML و CSS و JavaScript للمستخدم
- يجمع Input من الأزرار والـ Forms ويبعتها
- يستقبل الـ Response ويعرضها (Rendering)
- جهاز أو خدمة بتسمع وبترد على الـ Requests
- هو اللي بيستقبل ويعالج الـ Request
- بيشغل الـ Business Logic والـ Validation
- بيتواصل مع الـ Database لو محتاج
- بيرجع Response مناسبة (صفحة، JSON، Redirect)
Frontend vs Backend vs Database — الطبقات الثلاث
كل طبقة عندها مسؤولية مختلفة — تفهمهم كويس مهم جداً!
🖥️ Frontend (Client Side)
- اللي المستخدم بيشوفه ويتعامل معاه
- HTML, CSS, JavaScript
- بيشتغل في المتصفح (Browser)
- بيهتم بالشكل والتفاعل (UX)
- بيبعت Requests للـ Backend
⚙️ Backend (Server Side)
- بيعالج الـ Requests القادمة من المستخدم
- Python, JavaScript, Java, PHP…
- بيشتغل على الـ Server
- Business Logic, Validation, Permissions
- بيتواصل مع الـ Database ويجهز الرد
🗄️ Database (Data Layer)
- بيحفظ البيانات بشكل دائم (Persistent)
- SQLite, MySQL, PostgreSQL
- لا تتكلم مع المستخدم مباشرة!
- الـ Backend هو الوسيط الوحيد
- Tables: students, courses, grades…
| الوظيفة | الطبقة |
|---|---|
| عرض زرار "سجّل" على الشاشة | Frontend |
| التأكد إن كلمة المرور صح | Backend |
| حفظ بيانات الطالب في الجدول | Database |
| عرض رسالة "تم التسجيل بنجاح" | Frontend |
| التحقق من الـ Permissions | Backend |
| جلب بيانات الطالب للعرض | Backend → Database |
Static vs Dynamic Websites — ثابت أم ديناميكي؟
ليه Backend موجود أصلاً؟
📄 Static Website — موقع ثابت
- نفس المحتوى لكل الزوار بدون تغيير
- ملفات HTML جاهزة على السيرفر
- مناسب للمواقع التعريفية البسيطة
- عشان تعدل لازم تعدل الـ HTML يدوياً
- لا يحتاج Database
⚡ Dynamic Website — موقع ديناميكي
- المحتوى بيتغير بناءً على المستخدم أو الداتا
- الصفحة بتتولد لحظياً بكود الـ Backend
- ضروري للمتاجر، البوابات، الـ Dashboards
- البيانات بتيجي من الـ Database
- يدعم Login وبيانات مخصصة لكل شخص
URL Anatomy — تشريح الرابط
كل جزء في الـ URL بيقول حاجة مهمة
الـ URL (Uniform Resource Locator) هو عنوان أي مورد على الويب. بيقول للمتصفح فين يروح وإيه اللي يطلبه. ممكن يشير لصفحة، صورة، API endpoint، أو ملف.
| الجزء | المعنى | مثال |
|---|---|---|
| Protocol | نوع الاتصال — آمن أو عادي | http أو https |
| Domain | اسم الموقع على الإنترنت | portal.cu.edu.eg |
| Port | اختياري — بييجي بعد الـ Domain مفصول بـ : | :443 أو :8000 |
| Path | المسار للمورد المطلوب | /students/profile |
| Query String | بيانات إضافية للفلترة والبحث — بيبدأ بـ ? | ?level=2&sort=name |
- الـ Path بيحدد المورد الأساسي — إنت رايح فين؟
- الـ Query String بيضيف تفاصيل أو فلاتر إضافية — بتطلب إيه بالظبط؟
localhost معناها "الجهاز ده نفسه" — يعني السيرفر شغال على جهازك الشخصي. الـ 8000 هو الـ Port الافتراضي اللي Django بيشتغل عليه أثناء التطوير (Development).
HTTP — لغة التخاطب بين المتصفح والسيرفر
HyperText Transfer Protocol — البروتوكول الأساسي للويب
الـ HTTP (HyperText Transfer Protocol) هو البروتوكول اللي بيتحكم في شكل ومضمون الـ Requests والـ Responses بين المتصفح والسيرفر. هو مش بيحدد الـ Business Logic، هو بس بيحدد شكل التواصل (Communication Format).
الـ HTTPS هو نفس الـ HTTP لكن مشفّر (Encrypted) عن طريق SSL/TLS، وبيشتغل على الـ Port 443 بدل 80.
Request & Response — بنية الرسالتين
كل محادثة على الويب فيها Request من الـ Client وResponse من الـ Server
- يحتوي على Request Line (Method + Path + Version)
- يحتوي على Headers (بيانات وصفية)
- ممكن يحتوي على Body (بيانات مرسلة مثل الفورم)
- الـ Body مش إلزامي — GET مثلاً مبيكونش فيه Body
GET /students/list HTTP/1.1 Host: portal.cu.edu.eg Accept: text/html Authorization: Bearer token123 (Body فاضي في الـ GET)
- يحتوي على Status Line (Version + Status Code + Message)
- يحتوي على Headers (بيانات وصفية عن الرد)
- يحتوي على Body (HTML, JSON, صورة، أو رسالة خطأ)
- الـ Status Code مهم جداً — بيقول إيه اللي حصل
HTTP/1.1 200 OK Content-Type: application/json Content-Length: 256 {"status": "success", "data": [...]}
- أول سطر في الـ Request = Request Line (Method + URL + Version)
- أول سطر في الـ Response = Status Line (Version + Code + Message)
Headers — بيانات وصفية (Metadata):
Content-Type— نوع المحتوى (HTML, JSON, image)Authorization— بيانات الـ AuthenticationContent-Length— حجم المحتوىExpires— تاريخ انتهاء الـ Cache
Body — المحتوى الفعلي:
- في الـ Request: بيانات الفورم أو JSON
- في الـ Response: HTML أو JSON أو صورة
- مش كل Request بيحتاج Body
- معظم Responses بيكون فيها Body
"Expires: Tuesday, 17 Dec 2020 18:30 GMT" — ده Header بييجي في الـ Response (مش الـ Request) وبيعمل Time-Based Caching. الإجابة: response, time-based caching.HTTP Methods — أوامر الطلب
الـ Method بيقول للسيرفر نية الـ Request — إيه اللي عايزه يعمله؟
- بيُستخدم لجلب صفحة أو بيانات (Read-Only)
- البيانات بتظهر في الـ URL (Query String)
- لا يحتوي على Body
- مثال: فتح صفحة قائمة الطلاب
- Safe — مش المفروض يغير حاجة على السيرفر
- بيُستخدم لإرسال بيانات جديدة للسيرفر
- البيانات بتتبعت في الـ Body (مخفية)
- مثال: Login، Registration، إضافة ريكورد جديد
- أكثر أماناً من GET للبيانات الحساسة
- بيُنشئ Record جديد أو بيُنفذ Action
- PUT: تعديل كامل للـ Resource (Full Update)
- PATCH: تعديل جزئي للـ Resource (Partial Update)
- مثال: تحديث بيانات الطالب
- الفرق المهم: PUT = الكل، PATCH = جزء
- بيُستخدم لحذف Resource من السيرفر
- لازم يكون محمي بـ Authorization
- Idempotent — تكراره مش بيعمل مشاكل إضافية
- مثال: حذف كورس أو ريكورد
| المعيار | GET | POST |
|---|---|---|
| الغرض | قراءة البيانات | إرسال/حفظ بيانات جديدة |
| مكان البيانات | في الـ URL (مرئية!) | في الـ Body (مخفية) |
| الأمان | أقل أماناً للبيانات الحساسة | أكثر أماناً |
| Body | لا يحتوي على Body | يحتوي على Body |
| الاستخدام | فتح صفحات، بحث | Login، Registration، Forms |
HTTP Status Codes — أكواد حالة الـ Response
السيرفر بيستخدم الـ Status Code عشان يقول إيه اللي حصل
| الكود | المعنى |
|---|---|
200 OK | كل حاجة تمام — الأكثر شيوعاً |
201 Created | تم إنشاء Resource جديد بنجاح |
204 No Content | نجاح لكن مفيش Body في الرد |
| الكود | المعنى |
|---|---|
301 Moved Permanently | الصفحة اتنقلت لمكان تاني نهائياً |
302 Found | توجيه مؤقت — شائع بعد Login ناجح |
304 Not Modified | المحتوى لم يتغير — Cache صالح |
| الكود | المعنى |
|---|---|
400 Bad Request | الطلب مكسور أو ناقص |
401 Unauthorized | محتاج Login أولاً — "مين إنت؟" |
403 Forbidden | عارفك لكن مش مسموح — "مفيش صلاحية" |
404 Not Found | الصفحة أو الـ Resource مش موجود |
| الكود | المعنى |
|---|---|
500 Internal Server Error | كود الـ Backend وقع — مش غلط العميل |
502 Bad Gateway | السيرفر الوسيط فشل |
503 Service Unavailable | السيرفر مش شغال أو عليه ضغط |
- 401 Unauthorized: إنت مش عامل Login أصلاً — "مين إنت؟" — السيرفر شغال ومتاح
- 403 Forbidden: إنت عامل Login لكن معكش صلاحية — "أنا عارفك بس مش هسمحلك" — السيرفر شغال ومتاح
- 404 Not Found: المسار أو الـ Resource غلط أو مش موجود
- 304 Not Found: ❌ غلط! 304 = Not Modified (Cache لسه صالح) — Not Found دي 404
- 500 Internal Server Error: الكود ضرب جوه السيرفر — المسار صح لكن في Bug
| الموقف | الكود المتوقع | الشرح |
|---|---|---|
| فتح صفحة موجودة بشكل عادي | 200 OK | كل حاجة تمام |
| إضافة طالب جديد بنجاح | 201 Created | تم إنشاء الريكورد |
| بعد Login ناجح وتوجيه للـ Dashboard | 302 Found | Redirect مؤقت |
| فتح URL مش موجود | 404 Not Found | الـ Route مش موجود |
| طالب عادي يحاول يفتح صفحة الـ Admin | 403 Forbidden | بيعرفه لكن مش مسموح |
| Bug في كود Python على السيرفر | 500 Internal Server Error | الكود وقع |
Validation & Forms — التحقق والفورمات
ليه Backend Validation ضروري حتى لو الـ Frontend بيفحص؟
- بيتم في المتصفح قبل إرسال الطلب
- هدفه تحسين تجربة المستخدم (UX)
- سريع — مش بيحتاج رحلة للسيرفر
- يمكن تجاوزه! المستخدم يقدر يعدله
- JavaScript, HTML5 attributes
- بيتم على السيرفر بعد استقبال الطلب
- هدفه حماية البيانات والأمان
- لازم يفحص الـ required fields والـ formats
- لا يمكن تجاوزه — هو الحكم الأخير
- ضروري حتى لو الـ Frontend فاحص
JSON & APIs — نقل البيانات الحديث
ازاي الـ Backend بيبعت الداتا للـ Frontend والتطبيقات
الـ JSON (JavaScript Object Notation) هو format نصي لتمثيل البيانات المنظمة. شائع جداً في الـ APIs والتطبيقات الحديثة. بيستخدم Key-Value Pairs وشبه بالـ Dictionary في Python.
{
"name": "Ali",
"level": 2,
"department": "CS",
"courses": ["IS231", "CS101"]
}
HTML Response — رد عادي للمتصفح:
HTTP/1.1 200 OK Content-Type: text/html <html><body>Welcome!</body></html>
JSON Response — رد الـ APIs الحديثة:
HTTP/1.1 200 OK Content-Type: application/json {"status": "success"}
الـ API (Application Programming Interface) هو عقد للتواصل مع برنامج عن طريق Requests والـ Responses. الـ Web API بيرجع Responses فيها Data بدل صفحات HTML كاملة — ونفس مبادئ HTTP لازم تنطبق: URL, Method, Headers, Body, Response.
Cookies & Sessions — ازاي السيرفر بيتذكرك
بعد الـ Login، السيرفر عارفك إزاي في الطلبات الجاية؟
- بيانات صغيرة مخزنة في المتصفح
- السيرفر بيبعتها في الـ Response
- المتصفح بيبعتها مع كل Request تاني
- مثال: بيانات الـ Login Session
- الهيدر:
Expiresبيحدد مدة صلاحيتها
- بيانات مخزنة على السيرفر
- بتمثل حالة المستخدم (Logged In State)
- السيرفر بيتعرف على المستخدم عن طريق Session ID
- الـ Session ID بيتخزن في Cookie في المتصفح
- Django بيتعامل معاها تلقائياً
أسئلة امتحانات Web Basics & HTTP
كل أسئلة المحاضرة دي من امتحانات 2021 + 2024 + 2025 — مرتبة حسب ترتيب الشرح 🇪🇬
كل صورة JPEG بتحسب كـ Object منفصل (4 صور = 4 Objects)، وملف الـ HTML نفسه بيحسب Object واحد. إذن المجموع = 4 + 1 = 5 Objects. مفهوم الـ Object في الويب هو أي ملف يُطلب بشكل منفصل.
الـ HTTP بيشتغل فوق بروتوكول TCP على الـ Port 80 بشكل افتراضي. الـ TCP بيضمن وصول البيانات بالترتيب وبدون أخطاء (Reliable). أما HTTPS فبيشتغل على TCP كمان لكن على الـ Port 443.
رسالة الـ Request بتبدأ بـ Request Line (Method + Path + Version). مثال:
GET /students/list HTTP/1.1أما رسالة الـ Response بتبدأ بـ Status Line (Version + Code + Message). مثال:
HTTP/1.1 200 OK
أي HTTP Request لازم يحتوي دايماً على: Request Line + Headers. أما الـ Body فهو اختياري — بيكون موجود في POST/PUT لكن GET مثلاً مبيبعتش Body. وال Status Line دي بتاعة الـ Response مش الـ Request!
الـ POST أأمن من GET لأن البيانات في الـ POST بتتبعت في الـ Body (مخفية)، بينما في الـ GET بتظهر في الـ URL! لو بعتت Password بـ GET، هيظهر في الـ URL ويتسجل في الـ Browser History — ده خطر أمني كبير.
الـ 304 مش "Not Found"! 304 معناها Not Modified — يعني المحتوى لم يتغير والـ Cache في المتصفح لسه صالح. أما Not Found فدي الكود 404. الاختيارات التانية A و B و C كلها صح في التوصيل.
في الـ URL، الـ Port Number اختياري وبييجي بعد الـ Host مفصول بنقطتين (
:). مثال: https://portal.cu.edu.eg:443/students — الـ 443 ده الـ Port. لو مش موجود، المتصفح بيستخدم الـ Default (80 لـ HTTP أو 443 لـ HTTPS).
الهيدر
Expires بيتبعته السيرفر في الـ Response (مش الـ Request). وبما إنه بيحدد تاريخ ووقت معين لانتهاء الصلاحية، فده يُسمى Time-Based Caching. ده من أشهر الأسئلة المتكررة — ظهر في 2021 و2024!
الـ Content-Type (أو الـ MIME type) بيعرّف المتصفح نوع الداتا اللي جاية: هل هي
text/html ولا application/json ولا image/jpeg. ملوش دعوة بحجم المحتوى خالص — الحجم ده الـ Content-Length.
الكود 200 OK معناه الطلب نجح بالكامل — السيرفر استقبله وعالجه وبعت رد ناجح. في السياق ده: المستخدم مصرح له يشوف الداتا والدنيا تمام. (السؤال ده اتكرر بنفس الصياغة في فاينال 2021 كمان).
الكود 403 Forbidden معناها: السيرفر شغال وموصلنا له (Reachable)، وفاهم الطلب، لكن المستخدم معكوش صلاحية (Not Authorized) يوصل لده المورد. مثال: طالب عادي بيحاول يفتح صفحة Admin. مختلف عن 401 (مش عامل Login أصلاً).
PUT method in the HTTP request message for doing partial updates. (True or False?)الـ PUT بيعمل Full Update — بيعدل الـ Resource بالكامل. أما Partial Update (تعديل جزء منه بس) فده بيتعمل بـ PATCH. ده من الفخاخ المشهورة في الامتحانات!