الخدمات المصغرة ، واجهات برمجة التطبيقات والابتكارات: قوة واجهات برمجة التطبيقات

مرحبا بالجميع!



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

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

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

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

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

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

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

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

التفكير التصميمي و API

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

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

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

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

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

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

واجهة برمجة التطبيقات الأساسية غير موجودة

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

عملية التنفيذ: قطع كل ما هو غير ضروري

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

ركز على التفاعل وليس التكامل

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

ثلاثة أشياء يمكنك القيام بها اليوم

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

خذ ممارسة API الخاصة بك

أحد المكونات الرئيسية للنجاح طويل المدى لبرنامج API الخاص بك هو تطوير ممارسات تصميم API الخاصة بالتكنولوجيا. تأكد من أن هذا البرنامج لن يعتمد بالكامل على أحدث صيحات البرمجة ، باستخدام المكتبات أو المنصات. لهذا ، من الأنسب الاعتماد على نموذج "الخطوة الأولى - API".

"الشيء الأول هو واجهة برمجة التطبيقات" يعني أننا نصمم واجهة برمجة التطبيقات أولاً ، وعندها فقط نفكر في تفاصيل تنفيذها. من حيث المبدأ ، فإن مكون الأعمال هو نفسه بغض النظر عن التكنولوجيا التي تستخدمها لتنفيذ واجهة برمجة التطبيقات: سواء كانت SOAP أو CRUD أو REST أو gRPC أو GraphQL أو أي شيء شائع آخر. في الواقع ، من المرجح أن يسمح لك البرنامج المصمم جيدًا بصياغة التوصيات ذات الصلة بمجموعات التكنولوجيا المختلفة ، على التوالي ، ومساعدة فريقك وتقييم الوفورات المحتملة ، والحفاظ على اتساق القرارات في الإصدارات اللاحقة من الأنظمة الأساسية.

نحن نضمن مخاطر منخفضة عند إنشاء API

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

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

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

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

ثلاث API لإدارة الحيتان

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

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

يعني تنظيم التنسيقات أنك بحاجة إلى الموافقة على التنسيقات التي سيتم إرسال البيانات بين الخدمات. تتوقع جميع المتصفحات تقريبًا استجابة بتنسيق HTML - على هذا النحو تمامًا ، على مستوى واجهة برمجة التطبيقات لديك ، تحتاج إلى تحديد التنسيق الذي ستتفاعل فيه مع النظام البيئي بأكمله. تفضل معظم الشركات تنسيقات بسيطة ، مثل JSON أو XML أو CSV ، لكن نماذج رسائلها تفتقر إلى البيانات الوصفية الرئيسية ، ولا سيما أسماء الكائنات والروابط ونماذج الإدخال - وهي ضرورية للتفاعلات طويلة المدى. من ناحية أخرى ، أعرف أيضًا الشركات التي تستخدم تنسيقات أكثر تقدمًا ، على سبيل المثال ، HAL و Siren و Collection + JSON لواجهات برمجة التطبيقات المستندة إلى HTTP. بالنسبة للتفاعلات الثنائية بين الخدمات ، تأخذ العديد من المنظمات البروتوبوف وأشكال مماثلة كأساس. بغض النظر عن التنسيق الذي تختاره ، من المهم التحقق منه في خط التجميع الخاص بك ، مع التأكد من أن واجهات برمجة التطبيقات التي تتوافق تمامًا مع اللوائح فقط هي التي تدخل حيز الإنتاج.

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

بعد أن تعلمت هذه المبادئ: "أولاً - API" و "sketch-prototype-assembly" و "three API control kit" ، سيكون فريقك قادرًا على استخدام واجهات برمجة التطبيقات الخاصة بهم بكامل طاقتها ، دون المخاطرة باستقرارهم أثناء التنفيذ.