الفصل 20: الشبكة - كيف يتحدث الكود عبر الإنترنت (HTTP, APIs, JSON)

الجهاز العصبي الرقمي الذي يربط العالم

هل تساءلت يومًا كيف يقوم هاتفك بتحديث حالة الطقس في لحظة؟ أو كيف يقوم إنستغرام بتحميل صور جديدة دون أن تضطر إلى إعادة تحميل الصفحة بأكملها؟

الجواب ليس سحراً. إنه ليس شيئًا غامضًا يحدث في الفضاء الرقمي. إنه نظام، بروتوكول، لغة متفق عليها. إنه الجهاز العصبي للإنترنت، وهو يتكون من ثلاثة أجزاء رئيسية تعمل في تناغم تام: HTTP، APIs، و JSON.

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

استعد، لأننا على وشك توصيل الكود الخاص بك بالإنترنت.

1. HTTP: ساعي بريد الويب

تخيل الإنترنت كنظام بريد عملاق. أنت، أو بالأحرى متصفحك، هو العميل (Client). الموقع الذي تريد زيارته هو الخادم (Server). لكي تحصل على شيء من الخادم، يجب أن ترسل طلبًا. البروتوكول الذي ينظم هذه الطلبات والردود عليها هو HTTP (HyperText Transfer Protocol).

إنه مجموعة القواعد التي تضمن أن يفهم العميل والخادم بعضهما البعض.

أشهر نوعين من الطلبات (Requests):

1. GET: هذا هو طلب “القراءة”. عندما تكتب عنوان موقع في متصفحك، فأنت ترسل طلب GET للحصول على صفحة الويب. أنت تقول: “أعطني هذه المعلومة”.
2. POST: هذا هو طلب “الكتابة” أو “الإرسال”. عندما تملأ نموذج تسجيل دخول أو تكتب تعليقًا، فأنت ترسل طلب POST يحتوي على البيانات التي أدخلتها. أنت تقول: “خذ هذه المعلومة وسجلها عندك”.

إشارات المرور الرقمية (Status Codes): عندما يرد الخادم، فإنه يرفق “رمز حالة” (Status Code) مع الرد ليخبرك بنتيجة طلبك. إنها مثل إشارات المرور:

• 200 OK: الضوء الأخضر. كل شيء سار على ما يرام، وها هي البيانات التي طلبتها.
• 404 Not Found: “لم أجد ما تبحث عنه”. الصفحة أو المورد غير موجود. هذا خطأ من جانب العميل (أنت طلبت شيئًا غير موجود).
• 500 Internal Server Error: “حدث خطأ ما عندي في الخادم”. المشكلة ليست منك، بل من الخادم نفسه.

HTTP هو الأساس، هو الطريق السريع للمعلومات. لكن ماذا عن الرسائل نفسها؟ هنا يأتي دور الـ API.

2. API: قائمة طعام البرمجيات

إذا كان HTTP هو الطريق، فإن API (Application Programming Interface) أو واجهة برمجة التطبيقات هي قائمة الطعام والعناوين المحددة على هذا الطريق.

استخدمنا تشبيه المطعم من قبل، وهو أفضل تشبيه على الإطلاق هنا:

• أنت (العميل): الزبون في المطعم.
• الخادم (Server): المطبخ الذي يجهز الطعام.
• الـ API: النادل (الويتر).

لا يمكنك الذهاب مباشرة إلى المطبخ والصراخ بطلبك. هذا سيسبب فوضى. بدلاً من ذلك، هناك واجهة محددة: النادل. أنت تنظر في قائمة الطعام (التي يوفرها النادل)، وتختار طبقًا محددًا (مثل GET /users/123)، والنادل يأخذ طلبك إلى المطبخ ويعود بالطعام (البيانات).

الـ API هي العقد. هي مجموعة القواعد والمسارات (Endpoints) التي يعرضها الخادم للعالم الخارجي، قائلاً: “هذه هي العمليات التي يمكنك القيام بها، وهذه هي الطريقة التي تطلبها بها”.

مثال عملي: تطبيق الطقس على هاتفك لا يحتوي على بيانات الطقس لكل مدن العالم. هذا سيكون جنونًا. بدلاً من ذلك، عندما تفتحه، فإنه:

1. يستخدم HTTP لإرسال طلب GET إلى API الخاص بخدمة الطقس.
2. الطلب يذهب إلى مسار محدد مثل api.weather.com/forecast?city=Riyadh.
3. الخادم يستقبل الطلب عبر الـ API، ويبحث في قاعدة بياناته عن طقس الرياض.
4. ثم يرسل البيانات مرة أخرى إلى هاتفك.

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

3. JSON: اللغة المشتركة للبيانات

حسنًا، العميل أرسل طلب HTTP إلى API. الخادم جهز الرد. لكن بأي لغة يجب أن يكون هذا الرد؟

تخيل أن العميل يتحدث الإنجليزية والخادم يتحدث اليابانية. سيحتاجان إلى لغة مشتركة ومترجم. في عالم الويب، هذه اللغة المشتركة هي JSON (JavaScript Object Notation).

JSON هو مجرد تنسيق نصي لتمثيل البيانات. لقد انتصر على تنسيقات أقدم وأكثر تعقيدًا (مثل XML) لسببين رئيسيين:

1. سهل القراءة للبشر: انظر إلى المثال في الرسم البياني. يمكنك فهم بنية بيانات JSON بمجرد النظر إليها. إنها تتكون من أزواج key: value، تمامًا مثل الكائنات في جافاسكريبت (ومن هنا جاءت التسمية).
2. سهل التحليل للآلات: كل لغات البرمجة تقريبًا لديها أدوات مدمجة لتحويل نص JSON إلى هياكل بيانات أصلية (مثل object في جافاسكريبت، dictionary في بايثون، أو map في جافا) والعكس.

عندما يرسل خادم الطقس البيانات إلى هاتفك، فإنه لا يرسلها كصورة أو ملف معقد. يرسلها كنص JSON بسيط يبدو هكذا:

{
  "city": "Riyadh",
  "temperature": 35,
  "unit": "celsius",
  "condition": "sunny"
}

تطبيقك يستلم هذا النص، يقرأ قيمة temperature و condition، ثم يعرض لك أيقونة شمس ودرجة الحرارة “35°”.

JSON هو النسيج الضام الذي يحمل البيانات الفعلية في رحلتها عبر شبكة الإنترنت. إنه خفيف، سريع، وعالمي.

الخلاصة: الرقصة المتكاملة

الآن، دعنا نجمع كل القطع معًا لنرى الصورة الكاملة. عندما تضغط على زر “تحميل المزيد من التعليقات” على موقع ما:

1. العميل (متصفحك): يقوم بإنشاء طلب HTTP من نوع GET.
2. الوجهة: الطلب لا يذهب إلى صفحة ويب، بل إلى نقطة نهاية API محددة، مثل example.com/api/comments?post_id=42&page=2.
3. الخادم: يستقبل الطلب، وتتحقق الـ API من صحته. ثم يطلب من الكود الموجود على الخادم أن يجلب التعليقات للصفحة الثانية للمنشور رقم 42 من قاعدة البيانات.
4. تنسيق البيانات: الخادم يقوم بتنسيق قائمة التعليقات في شكل نص JSON.
5. الاستجابة: الخادم يرسل استجابة HTTP برمز 200 OK وفي جسم الاستجابة (Body) يضع نص الـ JSON.
6. العودة إلى العميل: متصفحك يستقبل الرد، يقرأ بيانات الـ JSON، ويستخدم جافاسكريبت لعرض التعليقات الجديدة على الشاشة دون إعادة تحميل الصفحة.

هذه الرقصة بين HTTP و API و JSON هي ما يجعل الويب الحديث تفاعليًا وسريعًا. إنها أساس كل شيء تقريبًا، من تطبيقات الهاتف المحمول، إلى مواقع الويب أحادية الصفحة (Single-Page Applications)، إلى إنترنت الأشياء (IoT).

لقد فتحت الآن الباب ليس فقط لفهم كيفية عمل الويب، ولكن لبناء تطبيقات قوية تتجاوز حدود الجهاز الواحد.

في الفصل القادم: سنتعمق في الأدوات التي تجعل التعامل مع هذه الرقصة أسهل بكثير. سندخل “عالم النظام البيئي” ونتحدث عن الفرق الجوهري بين المكتبات وأطر العمل.