واجهة برمجة التطبيقات (API): المفهوم والعمل

Recommended resources

The freely available resources this lesson will direct you to.

أهلاً بك في الدرس الثاني من رحلتنا نحو أتمتة متجرك. في الدرس السابق، استكشفنا "ماذا" نريد أن نفعل (الأتمتة) و"لماذا" هي ضرورية. الآن، سنبدأ في استكشاف "كيف" يمكننا تحقيق ذلك.

تذكر أن الأتمتة تعتمد على تواصل الأنظمة المختلفة مع بعضها—على سبيل المثال، يجب أن يكون متجر YouCan قادرًا على "التحدث" إلى Google Sheets أو نظام رسائل WhatsApp. الجسر الذي يسمح بحدوث هذا التواصل هو واجهة برمجة التطبيقات (API).

بحلول نهاية هذا الدرس، ستتمكن من تعريف واجهة برمجة التطبيقات (API) وكيفية عملها لتبادل البيانات. فهم هذا المفهوم هو الخطوة التقنية الأولى والأساسية لبناء أي نظام أتمتة.

1. ما هي واجهة برمجة التطبيقات (API)؟

ببساطة، الـ API هي اختصار لـ Application Programming Interface (واجهة برمجة التطبيقات). فكر فيها كوسيط أو "مترجم" يسمح لبرنامجين مختلفين بالتواصل مع بعضهما البعض، حتى لو كانا مكتوبين بلغات برمجة مختلفة أو يعملان على أنظمة مختلفة تمامًا.

API Interaction Flow Diagram — هذا المخطط يوضح دور الـ API كوسيط. العميل (Client) يرسل طلبًا (Request) إلى الـ API، التي بدورها تتواصل مع الخادم (Server) لجلب البيانات أو تنفيذ إجراء، ثم تعيد الاستجابة (Response) إلى العميل. الـ API تخفي كل التعقيدات الداخلية للخادم عن العميل.

للحصول على شرح مرئي ومبسط لهذا المفهوم، شاهد المقطع التالي.

يعني إيه API؟ وإزاي بتشتغل؟ الفرق بينها وبين Web API ببساطة

يقدم هذا الفيديو من قناة Ali Shahin تعريفًا ممتازًا لمفهوم الـ API باستخدام تشبيه "البوابة"، ويوضح الفرق المهم بين الـ API بشكل عام و الـ Web API التي سنستخدمها.

شاهد المقاطع التالية: من الدقيقة 2:14 إلى 3:12 للتعرف على التعريف الأساسي للـ API. من الدقيقة 6:29 إلى 7:57 لفهم الفرق بين API و Web API. ركز على أن الـ Web API تعمل عبر الإنترنت باستخدام روابط (URLs) وبروتوكول HTTP، وهذا هو النوع الذي سنتعامل معه في رحلتنا.

كما أوضح الفيديو، ما يهمنا في سياق أتمتة المتاجر الإلكترونية هو Web API. هذا يعني أننا سنتواصل مع خدمات مثل YouCan وشركات الشحن عبر الإنترنت، باستخدام روابط محددة تمامًا كما تتصفح أي موقع ويب.

2. كيف تعمل الـ API؟ دورة الطلب والاستجابة (Request-Response Cycle)

التواصل عبر الـ API يحدث دائمًا من خلال دورة من خطوتين: الطلب (Request) والاستجابة (Response).

أ. نموذج العميل والخادم (Client-Server Model)

في أي تفاعل عبر الـ API، هناك طرفان:

العميل (Client): هو التطبيق الذي يبدأ الطلب للحصول على بيانات أو لتنفيذ إجراء. في حالتنا، سيكون منصة الأتمتة مثل Make.com هي العميل.
الخادم (Server): هو التطبيق الذي يمتلك البيانات ويستجيب للطلب. في حالتنا، سيكون الخادم هو نظام YouCan الذي يحتوي على بيانات منتجاتك وطلباتك.

ما المقصود بواجهة برمجة التطبيقات (API)؟

يقدم هذا المقال من Amazon Web Services (AWS) تعريفًا رسميًا للـ API ويشرح بوضوح نموذج العميل والخادم.

اقرأ قسمي "ما المقصود بواجهة برمجة التطبيقات؟" و "كيف تعمل واجهات برمجة التطبيقات؟". ركز على فهم دور كل من العميل (Client) والخادم (Server) في عملية التواصل.

ب. تشريح طلب الـ API (Anatomy of an API Request)

عندما يرسل العميل طلبًا إلى الخادم، لا يرسل سؤالًا عشوائيًا. بل يرسل طلبًا منظمًا بدقة يحتوي على عدة مكونات أساسية.

للحصول على شرح تفصيلي لهذه المكونات، شاهد المقطع التالي.

دورة كاملة في تعلم مفاهيم الـ API مع أمثلة عملية وشرح بالتفصيل

يقدم هذا الفيديو من قناة BraaSite شرحًا تقنيًا لمكونات طلب الـ API وأنواع الطلبات المختلفة.

شاهد المقاطع التالية: من الدقيقة 4:42 إلى 5:18 للتعرف على أنواع الطلبات الرئيسية (GET, POST, PUT, DELETE). من الدقيقة 5:18 إلى 6:07 لفهم المكونات الثلاثة للطلب: الرابط (Endpoint)، رأس الطلب (Header)، وجسم الطلب (Body). ركز على فهم الغرض من كل نوع طلب ومتى نستخدمه.

لتلخيص ما ورد في الفيديو، يتكون الطلب من:

الرابط (Endpoint): هو عنوان URL المحدد الذي يستهدفه الطلب. كل وظيفة في الـ API لها رابط خاص بها.
- مثال: https://api.youcan.shop/v1/products لجلب قائمة المنتجات.

الطريقة (Method): هي الفعل الذي نريد تنفيذه. أشهر الطرق هي:

الطريقة	الوصف	مثال للاستخدام في متجرك
`GET`	جلب البيانات	الحصول على قائمة بجميع الطلبات الجديدة.
`POST`	إنشاء بيانات جديدة	إضافة منتج جديد إلى متجرك.
`PUT` / `PATCH`	تحديث بيانات موجودة	تغيير حالة طلب من "جديد" إلى "تم التأكيد".
`DELETE`	حذف بيانات	إزالة منتج من متجرك.

الترويسات (Headers): معلومات إضافية عن الطلب، مثل نوع المحتوى الذي نرسله، والأهم من ذلك، معلومات المصادقة (Authentication) مثل مفتاح الـ API (API Key) الذي يثبت أن لديك الصلاحية للوصول لهذه البيانات. (سنتعمق في المصادقة في درس لاحق).
الجسم (Body): البيانات الفعلية التي نرسلها إلى الخادم. يستخدم هذا الجزء مع طلبات POST و PUT.
- مثال: عند إنشاء منتج جديد (POST)، سيحتوي الجسم على اسم المنتج، سعره، وصفه، وصوره.

ج. تشريح استجابة الـ API (Anatomy of an API Response)

بعد أن يستلم الخادم الطلب ويعالجه، يرسل استجابة تحتوي على:

رمز الحالة (Status Code): رقم مكون من 3 أرقام يخبرنا بنتيجة الطلب. هذه الأرقام موحدة عالميًا. أشهرها:
- 200 OK: نجح الطلب (عادةً مع GET).
- 201 Created: تم إنشاء شيء جديد بنجاح (مع POST).
- 400 Bad Request: هناك خطأ في الطلب الذي أرسلته (مثل بيانات ناقصة).
- 401 Unauthorized: ليس لديك صلاحية للوصول (خطأ في مفتاح الـ API).
- 404 Not Found: الرابط (Endpoint) الذي طلبته غير موجود.
- 500 Internal Server Error: حدث خطأ في الخادم نفسه.
الترويسات (Headers): معلومات إضافية عن الاستجابة، مثل نوع المحتوى.
الجسم (Body): البيانات التي طلبها العميل. في معظم واجهات برمجة التطبيقات الحديثة، تكون هذه البيانات بتنسيق يسمى JSON، وهو ما سنتناوله بالتفصيل في درس قادم.

اختبر فهمك!

تخيل أنك تريد بناء أتمتة لتحديث حالة طلب في متجرك على YouCan من "جديد" إلى "تم الشحن" بعد أن تحصل على رقم التتبع من شركة الشحن. بناءً على ما تعلمته، أجب عن الأسئلة التالية:

أي طريقة (Method) ستستخدمها على الأرجح لإجراء هذا التحديث؟
ما هي المعلومة الأساسية التي تتوقع أن ترسلها في جسم (Body) الطلب؟

أظهر الإجابة

على الأرجح ستستخدم طريقة PUT أو PATCH، لأن الهدف هو تحديث بيانات موجودة (الطلب) وليس إنشاء طلب جديد.
يجب أن يحتوي الجسم على الأقل على المعلومتين التاليتين:
- الحالة الجديدة للطلب: "تم الشحن".
- رقم التتبع الذي حصلت عليه من شركة الشحن.
  بهذه الطريقة، يعرف خادم YouCan ما الذي يجب تغييره بالضبط في بيانات الطلب.

3. الـ API في صميم الأتمتة الحديثة

الآن بعد أن فهمت الآلية التقنية، من المهم أن ترى كيف يُستخدم هذا المفهوم لبناء الأنظمة القوية التي تهدف إلى إنشائها. كل الأدوات المتقدمة التي سنستخدمها، من بوابات الدفع إلى نماذج الذكاء الاصطناعي، تعتمد بشكل كامل على الـ API.

يعني إيه API؟ وإزاي بتشتغل؟ الفرق بينها وبين Web API ببساطة

يوضح هذا المقطع من قناة Ali Shahin أمثلة عملية وقوية جدًا لاستخدامات الـ Web API، مثل بوابات الدفع والذكاء الاصطناعي، وهي تطبيقات ستتعامل معها مباشرة في هذا المسار.

شاهد من الدقيقة 7:57 إلى 10:44. ركز على كيفية تمكين الـ API للتكامل (Integration) بين أنظمة مختلفة تمامًا (مثل متجرك وبنك العميل) دون الحاجة إلى معرفة التفاصيل الداخلية المعقدة. هذا هو جوهر القوة التي تمنحها لنا الـ API.

خلاصة الدرس

في هذا الدرس، انتقلنا من "لماذا" إلى "كيف" من خلال فهم حجر الزاوية التقني للأتمتة:

API هي واجهة تسمح للتطبيقات بالتحدث مع بعضها البعض. النوع الذي يهمنا هو Web API الذي يعمل عبر الإنترنت.
التواصل يتم عبر دورة طلب-استجابة بين عميل (يطلب البيانات) وخادم (يقدم البيانات).
الطلب يحتوي على رابط (Endpoint)، وطريقة (Method مثل GET, POST)، وترويسات (Headers)، وأحيانًا جسم (Body) يحتوي على البيانات.
الاستجابة تحتوي على رمز حالة (Status Code) يخبرنا بنتيجة الطلب، وجسم يحتوي على البيانات المطلوبة.

الدرس القادم

حتى الآن، تعلمنا كيف يمكن لنظامنا (العميل) أن يسأل نظامًا آخر (الخادم) عن معلومات جديدة بشكل استباقي (مثلاً: "يا YouCan، هل هناك أي طلبات جديدة؟"). ولكن، أليس من الأفضل أن يقوم YouCan بإخبارنا فورًا عند وصول طلب جديد، بدلاً من أن نسأل باستمرار؟

هذه الطريقة "التفاعلية" للتواصل ممكنة باستخدام تقنية تسمى Webhooks. في الدرس القادم، سنتعرف على ماهية الـ Webhooks وكيف تكمل عمل الـ API لتصميم أنظمة أتمتة أكثر كفاءة وفورية.