البرمجة والذكاء الاصطناعي · الصف الثاني الثانوي · الترم الأول
طرق اتصال تطبيقات الويب
نموذج العميل والخادم ودورة الطلب والاستجابة، بروتوكولا HTTP وHTTPS، طرق طلب HTTP (GET وPOST)، رموز حالة HTTP (200، 404، 500)، ودور واجهات برمجة التطبيقات (API) وصيغة JSON في تبادل البيانات.
آخر تحديث: · كيف نراجع المحتوى
مقدمة
- المادة: البرمجة والذكاء الاصطناعي
- المسار: مسار الهندسة وعلوم الحاسب
عندما تفتح تطبيق الطقس، يظهر لك خلال لحظة أن درجة الحرارة في القاهرة 31. التطبيق لا يعرف ذلك بنفسه؛ بل «سأل» خادمًا بعيدًا فأجابه. هذا الحوار بين العميل والخادم يجري ملايين المرات كل ثانية على الإنترنت، وله قواعد دقيقة: كيف يُصاغ السؤال؟ وكيف يُفهم أن الجواب نجح أو فشل؟ وبأي صيغة تُرسل البيانات؟ في هذا الدرس نتعرف على نموذج العميل والخادم، وبروتوكولي HTTP وHTTPS، وطرق الطلب ورموز الحالة، وواجهات برمجة التطبيقات وصيغة JSON.
أهداف التعلم
- أن تشرح نموذج العميل والخادم ودورة الطلب والاستجابة.
- أن تميّز بين HTTP وHTTPS، وتستخدم GET وPOST في سياقات مناسبة.
- أن تفسّر رموز حالة HTTP الشائعة، وتشرح دور API وJSON في تبادل البيانات.
- أن تصمم طريقة اتصال مناسبة لمهمة في تطبيق ويب، وتبرر اختياره.
شرح الدرس
السؤال الرئيسي: كيف يتواصل العميل والخادم لتشغيل تطبيق الويب، وما القواعد والرسائل التي يستخدمانها؟ الفكرة الأساسية أن تطبيقات الويب تعمل من خلال إرسال العميل للطلبات وإرجاع الخادم للاستجابات، باستخدام بروتوكولات (HTTP/HTTPS) وغالبًا واجهات برمجة تطبيقات تتبادل البيانات بصيغ مثل JSON.
العميل والخادم
- العميل (Client): برنامج أو جهاز يرسل طلبًا إلى خدمة أخرى؛ ومن أمثلته متصفح الويب وتطبيق الهاتف.
- الخادم (Server): الجانب الذي يستقبل الطلبات من العملاء، ويعالجها، ويعيد الاستجابات.
تعتمد كثير من تطبيقات الويب على إرسال العميل طلبًا وإعادة الخادم استجابة (نموذج الطلب والاستجابة)، مع وجود وسائل اتصال أخرى عند الحاجة.
HTTP وHTTPS
- HTTP (بروتوكول نقل النص التشعبي): بروتوكول يُستخدم لتبادل الرسائل بين عميل وخادم على الويب.
- HTTPS: استخدام HTTP عبر اتصال TLS آمن. يساعد TLS على حماية سرية الاتصال وسلامته، وعلى مصادقة الخادم، بحيث لا يستطيع المتجسس قراءة المحتوى أو تعديله بسهولة أثناء النقل. المواقع التي تبدأ عناوينها بـ”https://” تستخدم اتصال HTTPS.
طرق طلب HTTP
تتضمن الطلبات المرسلة من العميل إلى الخادم معلومات تسمى طريقة طلب HTTP توضح “نوع العملية المطلوبة”:
| الأسلوب | الدور | أمثلة |
|---|---|---|
| GET | يُستخدم عادةً لطلب مورد أو بيانات من الخادم | عرض صفحة ويب، استرجاع نتائج البحث |
| POST | يُستخدم عادةً لإرسال بيانات ليعالجها الخادم | إرسال معلومات تسجيل الدخول، إرسال محتويات نموذج |
رموز حالة HTTP
تتضمن الاستجابات المرسلة من الخادم إلى العميل رقمًا يشير إلى نتيجة المعالجة، يُسمى رمز حالة HTTP:
| رمز حالة HTTP | المعنى |
|---|---|
| 200 | نجاح (تمت معالجة الطلب بنجاح) |
| 404 | المورد المطلوب غير موجود بهذا العنوان |
| 500 | خطأ داخلي في الخادم منعه من إكمال الطلب؛ ولا يحدد الرمز وحده السبب التفصيلي |
واجهة برمجة التطبيقات (API) وJSON
- واجهة برمجة التطبيقات (API – Application Programming Interface): مجموعة قواعد واضحة تسمح لبرنامج بطلب بيانات أو وظائف من برنامج آخر. قد ترسل الواجهة الأمامية طلبات إلى خدمة خلفية عبر API وتستقبل منها البيانات.
- JSON (JavaScript Object Notation): صيغة نصية شائعة لتمثيل وتبادل البيانات المهيكلة باستخدام كائنات ومصفوفات وقيم بسيطة، تدعمها لغات وأدوات برمجية كثيرة. مثال على بيانات JSON:
{
"city": "Cairo",
"temperature": 31
}في هذا المثال، "city" مفتاح (key) وقيمته "Cairo"، و"temperature" مفتاح آخر وقيمته 31.
يتواصل تطبيق الويب كتبادل منظم: يطلب العميل ويستجيب الخادم، باستخدام بروتوكول (HTTP/HTTPS)، وطريقة طلب HTTP (GET/POST)، ورمز حالة، وغالبًا واجهة برمجة تطبيقات تعيد البيانات بصيغة JSON.
أمثلة وتطبيقات
مثال 1 (اختيار طريقة الطلب):
| العملية | الطريقة |
|---|---|
| عرض صفحة منتج | GET |
| البحث عن كلمة واسترجاع النتائج | GET |
| إرسال اسم المستخدم وكلمة المرور لتسجيل الدخول | POST |
| إرسال نموذج «اتصل بنا» | POST |
مثال 2 (تفسير رمز الحالة):
- كتب مستخدم رابطًا به خطأ إملائي فظهرت رسالة «الصفحة غير موجودة» ← 404.
- فتح الموقع بنجاح وظهرت الصفحة ← 200.
- تعطل برنامج على الخادم أثناء معالجة الطلب ← 500 (والرمز وحده لا يحدد السبب التفصيلي).
مثال 3 (قراءة JSON): في البيانات {"city": "Cairo", "temperature": 31} يوجد مفتاحان: city قيمته النصية "Cairo"، وtemperature قيمته العددية 31. لاحظ أن المفاتيح والقيم النصية بين علامتي تنصيص مزدوجتين، أما الأعداد فلا.
مثال 4 (تصميم اتصال): تطبيق يعرض توقعات الطقس يستخدم GET لاسترجاع البيانات، ويجب أن يستخدم HTTPS لحماية سلامة البيانات والتحقق من هوية الخادم، ويستقبل البيانات بصيغة JSON لأنها سهلة القراءة آليًّا وتدعمها معظم لغات البرمجة.
ملاحظات مهمة
- العميل لا يعني المستخدم نفسه؛ العميل هو البرنامج أو الجهاز الذي يرسل الطلب (مثل المتصفح أو تطبيق الهاتف).
- لا تُرسل كلمات المرور أو البيانات الحساسة عبر HTTP غير المشفر.
- الرموز التي تبدأ بـ 4 تشير غالبًا إلى مشكلة في الطلب نفسه، والتي تبدأ بـ 5 إلى مشكلة في الخادم.
- JSON صيغة لتمثيل البيانات، وليست لغة برمجة ولا بروتوكول نقل.
المفاهيم الأساسية
- العميل يرسل الطلب (متصفح أو تطبيق هاتف)، والخادم يستقبله ويعالجه ويعيد الاستجابة.
- HTTPS = HTTP عبر TLS، لحماية سرية الاتصال ومصادقة الخادم.
- GET لطلب/استرجاع بيانات، POST لإرسال بيانات ليعالجها الخادم.
- رموز الحالة: 200 نجاح، 404 مورد غير موجود، 500 خطأ داخلي في الخادم.
- API قواعد لتبادل البيانات بين البرمجيات، وJSON صيغة نصية شائعة لتمثيل تلك البيانات.
ملخص الدرس
تعمل تطبيقات الويب بنموذج الطلب والاستجابة: يرسل العميل (كالمتصفح أو تطبيق الهاتف) طلبًا، فيستقبله الخادم ويعالجه ويعيد استجابة. ويُستخدم بروتوكول HTTP لتبادل الرسائل، وHTTPS هو HTTP عبر اتصال TLS يحمي السرية والسلامة ويصادق الخادم. ويحدد الطلب نوع العملية (GET للاسترجاع وPOST لإرسال بيانات للمعالجة)، ويعيد الخادم رمز حالة مثل 200 للنجاح و404 للمورد غير الموجود و500 لخطأ الخادم. وكثيرًا ما يتم التبادل عبر واجهة برمجة تطبيقات (API) بصيغة JSON النصية المهيكلة.
أسئلة للتدريب
1. لماذا يجب أن تستخدم صفحة تسجيل الدخول HTTPS بدلًا من HTTP العادي؟
الإجابة: لأن صفحة تسجيل الدخول تنقل بيانات حساسة (اسم المستخدم وكلمة المرور) عبر الشبكة؛ فإذا استُخدم HTTP العادي غير المشفر، يستطيع أي طرف يتنصت على الشبكة (كمن يستخدم شبكة Wi-Fi عامة نفسها) قراءة هذه البيانات بسهولة أثناء انتقالها. أما HTTPS فيشفّر محتوى الاتصال عبر TLS، ما يمنع قراءة أو تعديل هذه البيانات أثناء النقل، ويساعد أيضًا على التأكد من أن الخادم الذي يُرسَل إليه فعلًا هو الخادم الصحيح لا موقعًا مزيفًا.
2. إذا استقبل المتصفح رمز حالة HTTP 404، ماذا يعني ذلك؟ وفي أي جانب (العميل أم الخادم) عادة ما يكون سبب المشكلة؟
الإجابة: يعني رمز 404 أن المورد المطلوب غير موجود بهذا العنوان على الخادم (كأن يكون الرابط خاطئًا أو الصفحة قد حُذفت). عادة ما يكون السبب متعلقًا بجهة الطلب/العنوان نفسه — أي عنوانًا غير صحيح كتبه العميل أو رابطًا معطوبًا — بخلاف رمز 500 الذي يشير تحديدًا إلى خطأ داخلي وقع في معالجة الخادم نفسه.
3. تقدم خدمة الطقس واجهة برمجة تطبيقات تعيد توقعات اليوم عندما يرسل العميل طلبًا. ما طريقة طلب HTTP التي سيستخدمها العميل لاسترجاع التوقعات؟ ولماذا يجب أن تستخدم الخدمة HTTPS؟ وما ميزة واحدة لاستقبال البيانات بصيغة JSON؟
الإجابة: سيستخدم العميل GET، لأنه يطلب استرجاع بيانات موجودة (توقعات الطقس) دون إرسال بيانات ليعالجها الخادم. يجب استخدام HTTPS لحماية سلامة البيانات المتبادلة ومصادقة هوية خادم الخدمة، حتى لا يتمكن طرف ثالث من التلاعب بالتوقعات المرسلة أو انتحال شخصية الخدمة. ميزة استقبال البيانات بصيغة JSON: أنها صيغة نصية مهيكلة يسهل على البرامج قراءتها وتحليلها آليًا (ومفهومة للبشر أيضًا عند القراءة المباشرة)، وتدعمها معظم لغات البرمجة، ما يسهّل دمج بيانات الطقس في أي تطبيق يستهلك هذه الواجهة.