دليل المبتدئين إلى API

ربما صادفت اختصار API عشرات المرات من قبل. إذا سبق لك الدفع عبر الإنترنت أو استخدام مجمّع بيانات، فقد استخدمت ذلك الـ API الغامض. لكن ما هو؟ في هذه المقالة، نستعرض ماهية API، وبروتوكولات API المتاحة، وأنواع API الموجودة.

ما هو API، وكيف يعمل؟

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

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

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

إضافة إلى ذلك، تتيح API للأنظمة المختلفة التواصل بغض النظر عن تقنياتها وبنيتها الأساسية. وبالنسبة إلى المستخدمين، تعني API قائمة واسعة من الوظائف.

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

مكونات API

لنلق نظرة أقرب خلف الكواليس. مم يتكون هذا الجزء من الشفرة المسمى API؟

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

عميل API

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

طلب API

يجب أن تتبع طلبات API المعيار نفسه. وهي تتضمن عادة خمسة عناصر رئيسية:

نقاط النهاية

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

الطريقة

في طلبك، يجب أن تخبر الخادم بما تريده أن يفعله. لذلك، الطريقة هي أمر للخادم يخبره بما ينبغي فعله. تختلف الطرق بحسب بروتوكول API الذي تستخدمه. على سبيل المثال، يستفيد بروتوكول REST من طرق HTTP مثل GET وPOST وPUT وPATCH وDELETE. وللبروتوكولات الأخرى طرقها الخاصة. إذا كنت ستستخدم API، فاقرأ وثائقه، إذ يوضح المزود البروتوكول والطرق التي يستخدمها API المعين.

المعلمات

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

الرؤوس

تؤدي الرؤوس في طلب API دورا تقليديا، إذ توفر بيانات إضافية عن الطلب وتنسيقات الاستجابة المطلوبة، وتفاصيل التفويض لإثبات أنك مخول لتنفيذ الإجراءات المطلوبة، وتفاصيل عن كيفية تخزين الطلبات والاستجابات مؤقتا.

جسم الطلب

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

خادم API

خادم API هو منصة أو برنامج أو قاعدة بيانات أو أي شيء نرسل إليه طلباتنا. وهو يوفر API ويخزن جميع بيانات API وينفذ الإجراءات التي نحددها في طلباتنا.

استجابة API

حيثما يوجد طلب، توجد استجابة أيضا. الاستجابة هي ما يرسله الخادم عند تلقي طلبك. وتتكون الاستجابات كذلك من عدة لبنات أساسية.

رمز الحالة

يشير رمز الحالة إلى ما إذا كان طلبنا ناجحا وما إذا كان الخادم استطاع معالجته. تعني الرموز في نطاق 200 أن الطلب نجح، وتعني 300 إعادة التوجيه، وتشير 400 إلى وجود مشكلات في الطلب، وتعني 500 وجود مشكلة من جهة الخادم.

رؤوس الاستجابة

تشبه رؤوس الاستجابة رؤوس الطلب. فهي ترسل ملفات تعريف الارتباط إلى العميل وتوفر تفاصيل عن جسم الاستجابة.

جسم الاستجابة

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

بروتوكولات API

البروتوكول مجموعة قواعد تحدد كيفية عمل API. وتستخدم عدة بروتوكولات مع API.

REST

REST، أو RESTful، هو أكثر بروتوكولات API استخداما. لكنه أقرب إلى أسلوب معماري منه إلى بروتوكول. يعتمد على بروتوكول HTTP لنقل البيانات بتنسيقي JSON أو XML. الطلبات مستقلة عن بعضها، ويمكن تخزين الاستجابات مؤقتا. البساطة وقابلية التوسع هما أبرز مزايا REST، ولهذا يعد الخيار الأول لخدمات الويب وتطبيقات الأجهزة المحمولة.

ومن ناحية أخرى، قد يحدث جلب مفرط أو جلب ناقص، فيحصل العميل على بيانات أكثر مما طلب أو، على العكس، لا يحصل على جميع البيانات اللازمة. كذلك، وبما أن REST يستخدم بروتوكول HTTP، فقد لا يكون مناسبا لجميع أنواع البيانات والتطبيقات والبيئات. ويرتبط REST أيضا بمخاوف أمنية، إذ قد يحتوي على ثغرات إذا لم تتم صيانته بصورة صحيحة.

SOAP

بروتوكول الوصول البسيط إلى الكائنات، أو SOAP، أكثر صرامة وتعقيدا بكثير من REST. يستخدم معيار بيانات XML ويمكنه دعم عدة بروتوكولات لنقل البيانات، بما فيها HTTP وSMTP. كما يدعم ميزات أمنية متقدمة مثل WS-Security. ويستخدم أساسا في الحالات التي تتطلب الأمان والطابع الرسمي أكثر من سهولة الاستخدام لجمهور كبير، مثل الخدمات المالية أو تطبيقات المؤسسات مثل Salesforce.

RPC

يعالج بروتوكول استدعاء الإجراء عن بعد البيانات بتنسيقي JSON وXML. لكنه يختلف جذريا عن REST وSOAP لأنه يستدعي طريقة بدلا من مصدر بيانات. وتشير استجابة RPC إلى أن إجراء ما تم تشغيله أو أخفق. وبما أن استدعاء خادم RPC يغير حالة الخادم، فمن الضروري وجود مستوى عال من الأمان بين المزودين والمستخدمين. لذلك، تكون API الخاصة بـ RPC خاصة غالبا. ومع ذلك، يعتمد RPC على بروتوكول HTTP/2 لنقل البيانات، وهو غير مدعوم أصلا في غالبية المتصفحات، لذلك قد تحتاج إلى معدات إضافية لضمان عمله بشكل صحيح.

GraphQL

على الرغم من أن GraphQL يسمى بروتوكولا، فهو لغة استعلام. بخلاف REST الذي يملك نقاط نهاية عديدة، لا يملك GraphQL عادة سوى نقطة واحدة. ويتيح GraphQL تنفيذ طلبات متعددة في استعلام واحد. ويمكن للمستخدمين تحديد البيانات التي يحتاجون إليها، ما يمنع الجلب المفرط أو الناقص. ومن ناحية أخرى، يواجه GraphQL بعض التحديات في التخزين المؤقت للبيانات. كما يجب على المزودين تقديم وثائق شاملة لإبلاغ المستخدمين بالمعلمات المتاحة لهم لإجراء استعلام.

أنواع API

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

API العامة

تسمى أيضا API المفتوحة أو الخارجية، وتصمم لجمهور واسع. ليس لها قيود أو لها قيود قليلة، وحتى إذا تطلبت مصادقة أو تسجيلا، فالإجراء سهل ولا يحتاج المستخدمون إلى أي مؤهلات لاستخدام API تلك. ومع ذلك، قد تتطلب API المفتوحة دفعات أو تحد من ميزات الحسابات المجانية. على سبيل المثال، Google Maps API هي API عامة.

API الخاصة

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

API الشركاء

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

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

API أحادية البنية

تنشأ API من هذا النوع كقاعدة شفرة واحدة تتيح الوصول إلى مصدر معقد. وتشمل مزاياها الوظائف المتوقعة والاستقرار. لكن من الصعب توسيعها أو تحديثها، لأن كثيرا من البيانات مترابط وقد تؤدي التغييرات إلى عواقب غير متوقعة.

API الخدمات المصغرة

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

API المركبة

هنا يأتي دور API المركبة. يمكنها استهداف نقاط نهاية متعددة في استدعاء واحد، وتحديد أكثر مجموعة فعالة من الاستدعاءات، وتزويدك بالبيانات اللازمة، ومنع تكرار الشفرة.

API الموحدة

تشبه API الموحدة API المركبة، لكنها بدلا من طلب نقاط نهاية مختلفة على API واحد، تطلب API متنوعة. ويتوقف الاختيار على احتياجاتك.

اختبار API ومراقبتها

مثل أي برنامج آخر، تتطلب API الاختبار والمراقبة لضمان الاستقرار والأمان والأداء العالي. يمكنك اختبار API يدويا أو إجراء اختبار آلي. وتوجد عدة أنواع من اختبار API:

• الاختبار الوظيفي – لضمان استجابة الخادم للطلبات، وصحة الاستجابات وتنسيقات البيانات؛
• اختبار الحمل – يساعد على التحقق مما إذا كان API يعمل بشكل صحيح عند حدوث ارتفاعات مفاجئة في حركة المرور؛
• اختبار الأمان – ضروري لضمان عدم بقاء أي ثغرات للمحتالين؛
• اختبار الانحدار – عند إجراء تغييرات، يلزم اختبار الانحدار للتأكد من عدم حدوث أي عواقب غير متوقعة وغير مرغوب فيها؛
• اختبار تحمّل الأعطال – مفيد للتحقق من كيفية استجابة النظام للطلبات التي قد تكون ضارة، مثل الطلبات التي قد تؤدي إلى هجوم DDoS.

يجري المطورون اختبار API خلال مرحلتي التطوير والنشر.

الخلاصة

API أداة أخرى تساعدك على تحقيق أقصى استفادة من التقنيات. وعلى الرغم من أنك تستخدمها كثيرا حتى من دون أن تدرك ذلك، فإن العديد من الوظائف في موقع الويب أو التطبيق المفضل لديك ممكنة بفضل API. ومن جانبها، تشرح DataImpulse التقنيات دائما بلغة واضحة كي تشعر بالراحة. كما أن تشغيل أداة بأخرى قد يمنحك أفضل نتيجة. على سبيل المثال، يصبح اختبار API أكثر فائدة بكثير مع البروكسي. وقد طورنا API الخاصة بنا أيضا، لذا يمكنك استخدامها لإعادة بيع البروكسي لدينا وتحقيق الربح معنا. لمعرفة المزيد، راسلنا على [email protected] أو اضغط زر “جرّب الآن” في الزاوية العلوية اليمنى من الشاشة.