واجهة برمجة التطبيقات الموحدة: سد الفجوة بين تطبيقات SaaS

واجهة برمجة التطبيقات الموحدة (API) هي واجهة برمجة تطبيقات تعمل كطبقة من التجريد يمكنها التواصل مع واجهات برمجة التطبيقات الأساسية المتعددة في وقت واحد.

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

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

ما المشكلة التي تحلها واجهات برمجة التطبيقات الموحدة؟

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

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

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

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

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

كيف تعمل واجهات برمجة التطبيقات الموحدة؟

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

تخيل أن عملائك يطلبون دمج منتجك مع نظام إدارة علاقات العملاء (CRM) الخاص بهم - عبر قاعدة المستخدمين الخاصة بك، يستخدم بعض العملاء Salesforce، والبعض الآخر يستخدم HubSpot، والبعض الآخر يستخدم Dynamics أو Pipedrive.

ستقوم واجهة برمجة تطبيقات CRM الموحدة بتجريد واجهات برمجة التطبيقات الخاصة بكل من إدارة علاقات العملاء هذه عن طريق الحفاظ على مراجع لكل واجهة برمجة تطبيقات خاصة بإدارة علاقات العملاء.

المصدر: باراجون

يوضح المثال هنا أن كل نظام أساسي لإدارة علاقات العملاء (CRM) يحتوي على كائن يمثل "جهة اتصال".

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

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

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

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

لا يمكن توحيد جميع واجهات برمجة التطبيقات في واجهة برمجة تطبيقات واحدة لأن تطبيقات SaaS المختلفة لها نماذج بيانات وهياكل وميزات فريدة.

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

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

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

ما هي فوائد واجهات برمجة التطبيقات الموحدة؟

توفر واجهات برمجة التطبيقات الموحدة فوائد متعددة للفرق الهندسية التي تحتاج إلى شحن وصيانة العشرات من عمليات التكامل.

تجريدات API

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

وهذا لا يجعل بناء عمليات التكامل هذه أسهل وأسرع فحسب، بل يساعد أيضًا في تقليل تعقيد عمليات التكامل.

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

المصادقة المدارة

يقدم موفرو واجهة برمجة التطبيقات الموحدة عمومًا خدمة مصادقة مُدارة تزيل تعقيدات المصادقة باستخدام واجهات برمجة التطبيقات الأساسية، سواء كان ذلك عبر مفاتيح واجهة برمجة التطبيقات أو OAuth.

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

نظرًا لوجود العديد من الفروق الدقيقة في كيفية تعامل كل تطبيق مع المصادقة، فقد تكون هذه مهمة مرهقة وعرضة للأخطاء، خاصة إذا كنت تعمل مع عدد كبير من واجهات برمجة التطبيقات.

تسجيل

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

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

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

واجهة مستخدم مبنية مسبقًا

يوفر معظم موفري واجهة برمجة التطبيقات الموحدة واجهة معدة مسبقًا لعملائك للمصادقة على التكامل، مما يوفر عليك بناء تجربة التكوين بنفسك.

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

ما هي التحديات التي تواجه استخدام واجهات برمجة التطبيقات الموحدة؟

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

استخدام قيود الحالة

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

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

المصدر: باراجون

دعونا نستعرض بعض الأمثلة على هذه القيود.

ميزات لا يمكن التوفيق بينها

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

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

حقول مفقودة

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

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

الكائنات والحقول المخصصة

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

يمكن أن يكون هذا عائقًا كبيرًا إذا كان عملاؤك يطلبون عمليات التكامل التي تقدمها لدعم استخدام الكائنات المخصصة داخل تطبيقات الطرف الثالث.

حدود المعدل

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

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

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

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

حماية

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

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

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

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

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

نموذج البيانات المبدئية

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

قيود خارطة الطريق

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

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

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

متى يجب عليك استخدام واجهة برمجة التطبيقات الموحدة

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

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

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

تحدي التكامل B2B SaaS

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

يمكن أن تكون واجهات برمجة التطبيقات الموحدة حلاً رائعًا لشحن العشرات من عمليات التكامل بأقل جهد، بشرط أن تكون حالات الاستخدام التي يطلبها عملاؤك موحدة عبر كل عملية تكامل ضمن فئة معينة.

إنها سوق نامية تضم العديد من اللاعبين الجدد وهي بالتأكيد طريقة مثيرة للاهتمام لحل تحدي التكامل بين B2B SaaS.

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