الاختلافات بين واجهات برمجة التطبيقات ورسائل اتصالات التطبيقات

فيل ويلكنز | مخطط تطوير السحابة، بـ Oracle | ديسمبر 2022

تحتاج البرامج إلى الاتصال بالبرامج الأخرى. في بعض الأحيان، يحتاج البرنامج الموجود في أحد أجزاء التطبيق إلى طلب الخدمات أو تبادل البيانات مع جزء آخر من التطبيق. أو، يجب على أحد التطبيقات طلب الخدمات أو تبادل البيانات مع تطبيق مختلف تمامًا.

توجد آليتان نموذجيتان مستخدمتان لهذه الأنواع من الاتصالات: واجهات برمجة التطبيقات (APIs) والرسائل.

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

تعريف تفصيلي لواجهات برمجة التطبيقات

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

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

تستخدم بعض الكتب والمقالات حول واجهات برمجة التطبيقات تشبيه واجهة برمجة التطبيقات باعتبارها بابًا، مع وصف خصائص واجهة برمجة التطبيقات. على سبيل المثال، قد يكون باب متجر بقالة يفتح تلقائيًا أو باب خزانة بنك فائق الأمان. يجب أن يساعد عقد التطبيق — خصائص الباب - في معالجة اعتبارات مثل:

ماذا تفعل واجهة برمجة التطبيقات على مستوى عالٍ؟ في تشبيه الباب لدينا، هل يفتح دون الحاجة إلى الضيف لوقف ولمس شيء ما (باب متجر البقالة) أو هل يتحكم في الوصول وحماية ما وراء الباب (خزانة البنك)؟
ما الحمولات (البيانات التي يتم إرسالها) التي ستحتاج إلى دعم للسماح للبرنامج بتنفيذها؟ على سبيل المثال، قد يتلقى البرنامج رقم حساب مصرفي وتخويل أمني ويرد بالرصيد في ذلك الحساب المصرفي.
ما البيانات التي يجب تبادلها للقيام بهذه الخدمة؟ على سبيل المثال، من المهم تحديد شكل رقم الحساب والتخويل الأمني الصالحين وتحديد محتويات الاستجابة. التفاصيل مهمة هنا؛ يمكن أن يؤدي الغموض إلى أخطاء.
ما هو عنوان الباب؟ يعني هذا عادةً طريقة تكوين معرف المورد العام (URI) للطلب. بمعنى آخر، كيف يتصل الطالب بالفعل بواجهة برمجة التطبيقات؟
ما البروتوكول (البروتوكولات) الذي سيتم استخدامه للاتصال؟ يمكن أن تتراوح هذه التقنيات من تقنيات معروفة، مثل HTTP وFTP، إلى بروتوكولات خاصة، مثل STOMP وQUIC.
ما الشروط والأحكام التي يجب على مستخدم واجهة برمجة التطبيقات الالتزام بها؟ يمكن أن تتضمن تفاصيل التشفير، أو حد لعدد المرات التي يمكن فيها استدعاء واجهات برمجة التطبيقات، أو آليات إعادة الرسوم للخدمات التجارية.
ما الوعود التي تقدمها واجهة برمجة التطبيقات؟ قد تتضمن ذلك ضمانات على مستوى الخدمة لواجهة برمجة التطبيقات، مثل أن يتم الإقرار بالطلب أو تنفيذه خلال فترة زمنية محددة.

تحديد الرسائل في تطوير التطبيق

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

فكر في الأمر بهذه الطريقة:

تشير الرسائل إلى عملية إرسال جزء من المعلومات—الرسالة—من طالب الخدمة إلى مزود الخدمة (تستخدم غالبًا طرفًا ثالثًا يعرف بالوسيط).

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

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

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

اطلع على المزيد من التفاصيل حول تكوين واجهات API، ومنصات API، وإدارة API.

تعمل واجهات برمجة التطبيقات والمراسلة معًا في أنظمة المؤسسة

يتم إنشاء أنظمة برامج المؤسسة من عمليات متعددة ومنفصلة قابلة للتنفيذ، ونتيجة لذلك تتطلب اتصالًا بين العمليات (IPC). يمكن أن تكون الاتصالات هنا معقدة، مما يتطلب العديد من الحركات ذهابًا وإيابًا مع العديد من استدعاءات واجهة برمجة التطبيقات مع الكثير من البيانات المنسقة بدقة لتنفيذ معاملة. يتعين تنظيم تلك المعاملات وإكمالها بعناية من أجل تلبية الاحتياجات التجارية.

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

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

السلوك المتزامن وغير المتزامن

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

تأتي أنظمة رسائل المؤسسة المعقدة في أنواع أو أنماط مختلفة:

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

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

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

يعد المصطلح المرادف لناقل الخدمة ناقل الرسائل. عندما كانت هذه التقنيات تتطور لأول مرة لتصبح حلول بنية موجهة بالخدمة (SOA)، كانت توجد بعض الاختلافات بين ناقلات الرسائل وناقلات الخدمة. اليوم، لا توجد اختلافات حقيقية. في الواقع، يزداد الاسم إلى مجرد ناقل.
خدمات الويب: بالمعنى الأوسع للمصطلح، تمثل خدمات الويب اتصالات متزامنة مباشرة بين عمليتين، عادةً باستخدام بروتوكولات TCP وHTTP (أو الاختلافات، مثل HTTPS وHTTP/2). يتم تحقيق المستهلك والعميل كاتصالات من نقطة إلى نقطة (على الرغم من أنه من الشائع أن يدعم الطرف مزود الخدمة اتصالات متعددة متزامنة مع العميل). قد يكون هناك وكلاء (من جدران حماية الشبكة إلى بوابات واجهة برمجة التطبيقات، وذاكرات التخزين المؤقتة للويب) ووسطاء (المحولات وأجهزة التوجيه) الشبكة بين العمليتين، لكن لن يكون المزود أو المستهلك على علم بها.
يتصل مزود خدمة الرسائل مباشرةً بالمستهلك. تتوقف عملية الإرسال على توفر كلا الطرفين.
وسطاء الرسائل:يمثل وسطاء الرسائل وسطاء بين مزود خدمة الرسائل ومستهلك الرسائل ولديهم سمات مشتركة مع كل من ناقلات الخدمة وخدمات الويب.

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

يأتي التشابه مع خدمات الويب من حقيقة أن الاتصال بين العميل والوسيط يمثل اتصالًا من نقطة إلى نقطة؛ يعد وسيط الرسائل غير مرئي وظيفيًا.

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

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

يوجه مزود خدمة الرسائل رسالته إلى الوسيط. ثم يحتفظ الوسيط بالرسالة حتى يقوم المستهلك (المستهلكين) بطلب رسالة أو يمكنهم استلام الرسالة. لا يعتمد مزود الخدمة على المستهلك.

دور بث رسائل المؤسسة

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

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

تمثل التقنيات الشائعة لبث خدمة الويب WebSockets وعمليات بث gRPC واشتراكات GraphQL. عندما يتعلق الأمر بعمليات بث الرسائل الوسيطة (باستخدام التقنيات، مثل Kafka)، يمكنك في بعض الأحيان الاستفادة من طريقة عمل الوسيط للنظر في "جزء" من الأحداث المرسلة. يساعدك ذلك على جمع رؤى قيمة، بما في ذلك معلومات حول البث نفسه—ومن ثم مصطلح بث التحليلات.

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

معايير صناعة API والرسائل

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

كان هذا مجالًا للتطوير، لا سيما بالنسبة لواجهات API، لأكثر من عشر سنوات. تبنت الصناعة مواصفات OpenAPI لواجهات API المستندة إلى REST، والتي تعد شكلًا من أشكال خدمات الويب—وربما الأنواع الأكثر شيوعًا لواجهات API المستخدمة في برامج المؤسسة الحديثة.

مع واجهات برمجة التطبيقات (والبث)، توجد عدد من المعايير الإضافية لتعريف ووصف جوانب الرسائل ونقلها. تشمل هذه مخازن البروتوكولات المؤقتة (وتسمى أيضًا Protobuf وتستخدم بجانب gRPC) ومؤخرًا GraphQL ومخطط JSON وYAML.

في مجال الرسائل غير المتزامنة، شهدت السنوات القليلة الماضية جهودًا ناجحة للتوسع حول تعريف يسمى AsyncAPI، والذي كيَّف الأفكار من OpenAPI وغيرها من المعايير المتطورة لتلبية متطلبات الرسائل العديدة.

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