ما هي دورة حياة واجهة برمجة التطبيقات (API)؟

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

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

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

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

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

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

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

في مرحلة التخطيط هذه، تقوم المؤسسات بما يلي:

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

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

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

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

أين سيتم تخزين وتوفير الوثائق والمعلومات الأخرى الخاصة بواجهة برمجة التطبيقات (API) للمطورين والمستخدمين على حد سواء؟ أين سيتم تتبع وتخزين تغييرات الكود؟

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

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

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

على سبيل المثال، تشمل أطر عمل وبنى واجهات برمجة التطبيقات (API) الشائعة كلًا من REST و GraphQL و gRPC؛ ولكل منها نقاط قوتها وضعفها. 

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

عند تصميم واجهة برمجة التطبيقات (API)، سيقرر الفريق أيضًا نوع المصادقة المناسب (مثل OAuth 2.0) وما إذا كان يجب وضع واجهة برمجة التطبيقات خلف بوابة واجهة برمجة تطبيقات (API gateway).

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

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

بالنسبة لـ GraphQL، فإن المواصفات المعادلة هي مخطط GraphQL، وهو عقد قوي النوع مكتوب بلغة تعريف المخطط، أو SDL، وهي تنسيق قابل للقراءة من قبل البشر. توفر منظومة GraphQL أدوات متنوعة تستفيد من هذا المخطط بطرق تمنح وظائف مشابهة لـ OpenAPI؛ فعلى سبيل المثال، تُعد GraphiQL منظومة تطوير متكاملة (IDE) داخل المتصفح، تتيح للمطورين استخدامها كبيئة تجريبية. 

بالنسبة لـ gRPC، تُعد المخازن المؤقتة للبروتوكول أو ما يعرف بـ protobuf، تنسيقاً لتسلسل البيانات ولغة لتعريف الواجهات (IDL)، وهي تُستخدم كأكثر تنسيقات الملفات شيوعاً لوضع المواصفات التقنية. لا توفر Protobuf ميزة الاختبار التفاعلي، رغم وجود واجهات مستخدم ويب تتيح ذلك. 

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

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

GitHub هو خدمة استضافة Git الأكثر شيوعاً، حيث يقدم مستويات مجانية ومدفوعة، مما يتيح التخزين والاسترجاع والتعاون في مستودعات كود Git. هناك بدائل لاستضافة مستودعات Git، بما في ذلك GitLab و AWS CodeCommit و Microsoft Azure Repos.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بوابة واجهة برمجة التطبيقات (API gateway) هي طبقة برمجية توفر نقطة دخول واحدة للعملاء للوصول إلى مجموعة متنوعة من الخدمات الخلفية، أو نُسخ متعددة من خدمة خلفية واحدة. توفر بوابات واجهة برمجة التطبيقات العديد من المزايا:

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

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

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

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

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

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

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

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

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

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

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

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

• يوفر الإصدار الجديد أداءً فائقًا
• لم تعد احتياجات الامتثال أو الأمن تُلبى بشكل كافٍ 
• التغييرات التجارية أو المالية داخل المؤسسة
• عدم التوافق مع البرامج الأحدث

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

يتطلب إيقاف تشغيل واجهة برمجة التطبيقات (API) إجراء نقاش. هل من الضروري إيقاف تشغيل واجهة برمجة التطبيقات (API)، ولماذا؟ ما البديل، إن وجد؟ ومن الذي يجب إبلاغه بالتقاعد الوشيك؟

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

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

يُقصد "بيوم الإيقاف النهائي" (sunset day) الموعد الذي يتم فيه إغلاق الواجهة البرمجية العامة تماماً؛ حيث سيتوقف الرد على الطلبات، وستتلقى التطبيقات التي تحاول الاتصال بها رسالة خطأ. من الممارسات الجيدة تحديث الوثائق لتعكس هذا التغيير، وتحرير أي مساحة على الخادم أو البنية التحتية الأخرى التي كانت واجهة برمجة التطبيقات تستخدمها. 

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