عقلية النظام الأساسي في إدارة منتج API

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

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

فعل المزيد بأقل

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

توصيل النقاط

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

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

اقتراح المنصة

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

تفتح واجهات برمجة التطبيقات قنوات عمل جديدة من خلال الاستفادة من خبرة الأطراف الثالثة التي تستفيد منها. يمكن للمطورين المستهلكين تصميم تطبيق عقاري يستخدم واجهات برمجة تطبيقات أماكن خرائط Google لمساعدة المستخدمين في البحث عن المنازل ، أو يمكنهم الاستفادة من واجهات برمجة تطبيقات Skyscanner's Flight وواجهات برمجة تطبيقات فندق Expedia لإنشاء موقع للسياحة البيئية يتخصص في السفر إلى موقع معين. يستفيد هؤلاء المطورون والشركاء الخارجيون من خلال الوصول إلى البيانات والخدمات الحالية التي يمكنهم تكييفها مع أعمالهم ، ويقوم مالكو واجهات برمجة التطبيقات مثل Expedia بتوسيع مدى وصولهم وتحقيق الدخل من الفرص التي لم تكن موجودة لو استمروا ، على سبيل المثال ، في إدراج الفنادق فقط في منتجاتهم.

جعلها وحدات

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

إسعاد المطورين

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

أفضل الممارسات

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

اصطلاحات التسمية ونقاط النهاية المتسقة

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

الهياكل التفصيلية للنجاح والاستجابة للفشل

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

 { "status": 400, "message": "incorrect request" }

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

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

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

حدود معدل شكلي

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

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

وثائق شاملة

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

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

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

هناك عدد من الأدوات في السوق يمكنها المساعدة في إنشاء وثائق شاملة لواجهة برمجة التطبيقات. مراجعة أمثلة الوثائق عالية الجودة ، مثل Stripe ، مفيدة أيضًا.

جمع كل ذلك معا

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