ما هي واجهة برمجة التطبيقات (API)؟ شرح مبسّط للمبتدئين
✦ أهم النقاط
- واجهة برمجة التطبيقات (API) هي وسيط يسمح لبرنامجين بالتواصل وتبادل البيانات دون معرفة تفاصيل عمل بعضهما.
- التشبيه الأشهر هو النادل في المطعم: أنت الزبون، والمطبخ هو الخادم، والنادل هو الـ API الذي ينقل الطلب ويعيد النتيجة.
- معظم واجهات الويب الحديثة تتبع أسلوب REST وتستخدم أوامر HTTP الأربعة: GET وPOST وPUT وDELETE.
- أكواد الحالة مثل 200 و404 و500 تخبرك بسرعة إن نجح الطلب أم فشل ولماذا.
- مفاتيح API وحدود الاستخدام تحمي الخدمة وتضبط عدد الطلبات المسموح بها لكل مستخدم.
في كل مرة تفتح فيها تطبيق الطقس، أو تضغط على زر «تسجيل الدخول عبر جوجل»، أو ترى موقعك يظهر على الخريطة، تكون هناك واجهة برمجة تطبيقات تعمل بصمت في الخلفية. إنها البنية الخفية التي تجعل تطبيقات اليوم متصلة ببعضها. لكن ما هي هذه الواجهة فعليًا، وكيف تعمل بلغة يفهمها المبتدئ؟
ما هي واجهة برمجة التطبيقات؟
واجهة برمجة التطبيقات، أو اختصارًا API (من Application Programming Interface)، هي مجموعة من القواعد المتفق عليها التي تسمح لبرنامجين بالتحدث معًا. فكّر فيها كعقد: البرنامج «أ» يعرف أنه إذا أرسل طلبًا بصيغة معيّنة، فسيحصل على رد بصيغة متوقعة. لا يحتاج أي طرف أن يعرف كيف بُني الطرف الآخر من الداخل؛ يكفي أن يلتزم كلاهما بالقواعد المعلنة.
أداة الفواتير وعروض الأسعار
فواتير احترافية تُحسب وتُطبع/PDF في دقيقة.
هذه الفكرة قوية لأنها تفصل بين «ما تريده» و«كيف يُنجَز». عندما تطلب من خدمة خرائط تحديد مسار بين مدينتين، لا يهمّك أي خوارزمية تستخدمها أو أي خوادم تعمل عليها؛ يهمّك فقط أن ترسل نقطة البداية والنهاية وتستقبل المسار. الواجهة هي الباب المنظّم الذي تدخل منه.
تشبيه النادل في المطعم
أفضل طريقة لفهم الـ API هي تخيّل مطعم. أنت جالس على الطاولة (أنت التطبيق الذي يريد شيئًا)، والمطبخ هو الخادم الذي يملك البيانات ويطبخها. أنت لا تدخل المطبخ بنفسك ولا تعرف كيف تُطهى الأطباق، بل تنادي النادل. النادل هو واجهة برمجة التطبيقات: يأخذ طلبك المكتوب في القائمة، ينقله إلى المطبخ بلغة يفهمها الطهاة، ثم يعود إليك بالطبق جاهزًا.
القائمة نفسها مهمة في هذا التشبيه: فهي تحدّد ما يمكنك طلبه وما لا يمكنك. بالمثل، تنشر كل واجهة API «توثيقًا» يشبه القائمة، يبيّن الطلبات المتاحة والبيانات التي يجب إرسالها والنتائج المتوقعة. أنت مقيّد بما هو في القائمة، وهذا في الحقيقة أمان لا قيد؛ فهو يمنع الفوضى ويحافظ على المطبخ منظّمًا.
الطلب والاستجابة وأسلوب REST
كل تعامل مع واجهة الويب يتكوّن من جزأين: طلب (Request) ترسله، واستجابة (Response) تعود إليك. الطلب يحمل عنوانًا يشير إلى المورد المطلوب، ونوع العملية، وأحيانًا بيانات إضافية. الاستجابة تحمل النتيجة، عادةً بصيغة JSON، وهي صيغة نصية خفيفة يسهل على البشر والآلات قراءتها.
معظم واجهات الويب اليوم تتبع أسلوبًا يُسمى REST. الفكرة الأساسية فيه أن كل شيء يُعامَل كـ«مورد» له عنوان فريد، وأنك تتفاعل مع هذه الموارد باستخدام أوامر HTTP القياسية. هذا الأسلوب أصبح شائعًا لأنه بسيط ومنظّم ويعتمد على بروتوكول الويب نفسه الذي تعمل به المتصفحات.
أوامر HTTP الأربعة الشائعة
عندما تتعامل مع واجهة REST، تختار «فعلًا» يصف ما تريد فعله بالمورد. الجدول التالي يلخّص الأوامر الأربعة الأكثر استخدامًا:
| الأمر | الغرض | مثال |
|---|---|---|
| GET | جلب بيانات موجودة دون تغييرها | عرض قائمة المقالات |
| POST | إنشاء عنصر جديد | إضافة تعليق جديد |
| PUT | تحديث عنصر موجود بالكامل | تعديل بيانات ملفك الشخصي |
| DELETE | حذف عنصر | إزالة صورة من الألبوم |
أكواد الحالة: لغة النجاح والفشل
بعد كل طلب، تعيد الخدمة «كود حالة» من ثلاثة أرقام يخبرك بسرعة ماذا حدث. الأكواد التي تبدأ بالرقم 2 تعني النجاح، وتلك التي تبدأ بالرقم 4 تعني خطأً من جهتك أنت، وتلك التي تبدأ بالرقم 5 تعني خطأً في الخادم نفسه. إليك أشهرها:
| الكود | المعنى |
|---|---|
| 200 | نجح الطلب |
| 201 | تم إنشاء عنصر جديد بنجاح |
| 400 | الطلب غير صحيح أو ناقص |
| 401 | مطلوب تسجيل دخول أو مفتاح صالح |
| 404 | المورد غير موجود |
| 429 | تجاوزت حدّ عدد الطلبات المسموح |
| 500 | خطأ داخلي في الخادم |
مفاتيح API وحدود الاستخدام
كثير من الخدمات تطلب «مفتاح API»، وهو سلسلة سرية من الحروف والأرقام تُرفق مع كل طلب لتعريف من أنت. المفتاح يشبه بطاقة عضوية: يسمح للخدمة بالتأكد من هويتك، وحساب استخدامك، وإيقافك عند إساءة الاستخدام. لهذا يجب أن تبقي مفتاحك سريًا ولا تنشره علنًا في الكود.
ومن أجل حماية الخوادم من الضغط الزائد، تفرض معظم الواجهات «حدود استخدام» (Rate Limits)، أي عددًا أقصى من الطلبات في فترة زمنية، مثل ألف طلب في الساعة. إذا تجاوزت هذا الحد، تعيد لك الخدمة الكود 429 وتطلب منك الانتظار. هذه الحدود تضمن العدالة بين المستخدمين وتمنع أي طرف من احتكار الموارد.
مثال عملي خطوة بخطوة: تطبيق الطقس
لنتتبّع ما يحدث حين تفتح تطبيق الطقس على هاتفك. أولًا، يحدّد التطبيق موقعك ويجهّز طلبًا من نوع GET إلى واجهة خدمة الطقس، مرفقًا به إحداثيات مدينتك ومفتاح API الخاص به. ثانيًا، يصل الطلب إلى خادم الطقس الذي يتحقق من صحة المفتاح ومن أنك لم تتجاوز حدّ الطلبات.
ثالثًا، يبحث الخادم عن بيانات الطقس لموقعك ويحزمها في استجابة بصيغة JSON تحتوي على درجة الحرارة والرطوبة واحتمال المطر، ويرفق معها الكود 200 للدلالة على النجاح. رابعًا، يستقبل تطبيقك هذه البيانات ويحوّلها إلى الصورة الجميلة التي تراها: شمس مشرقة و«28 درجة». كل هذا يحدث في أقل من ثانية، وأنت لم تر أي طلب أو كود؛ رأيت النتيجة فقط. هذا هو جوهر واجهة برمجة التطبيقات: تعقيد كبير مخفيّ خلف تجربة بسيطة.
أمثلة يومية تحيط بك
زر «تسجيل الدخول عبر جوجل» هو واجهة API أخرى: بدل أن ينشئ الموقع نظام كلمات مرور خاصًا به، يطلب من جوجل التحقق من هويتك ويكتفي بالرد. وخرائط المدن المدمجة في تطبيقات التوصيل تأتي من واجهة خرائط. وحتى زر الدفع الإلكتروني يستدعي واجهة بنكية آمنة. بمجرد أن تدرك وجود هذه الواجهات، ستراها في كل تطبيق تفتحه، تعمل بصمت كنادل مجتهد لا يتوقف.