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

ما يُساعد هذا الدليل على تحقيقه

• كتابة العقد
• توضيح الأخطاء
• اختبار التوافق
• التخطيط للإيقاف

فحص سريع

• ما هي الجهات التي تستخدم كل عملية؟
• هل للأخطاء أنواع ثابتة وحالات متسقة؟
• هل يمكن لعميل قديم تحمل التغيير؟
• هل يمكن أن تؤدي إعادة المحاولة إلى تكرار إجراء ما؟
• كيف سيتم الإعلان عن الإيقاف والتحقق منه؟

طريقة خطوة بخطوة

1. 1

   جرد المستهلكين

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

   المُخرَج: خريطة تبعيات العقد.

2. 2

   وصف الطلبات والاستجابات.

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

   المخرج: المُخرَج: عقد مُرَقَّم واختبارات المطابقة.

3. 3

   تثبيت الأخطاء.

   استخدام حالات HTTP وفقًا لدلالاتها، وعند الحاجة، استخدام نوع مشكلة موثق وفقًا لـ RFC 9457. عدم الكشف عن البيانات السرية بالتفصيل.

   المخرج: المُخرَج: فهرس أخطاء مُختَبَر.

4. 4

   تصنيف التغيير.

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

   المخرج: المُخرَج: مصفوفة التوافق وقرار الإصدار.

5. 5

   جعل الإشعارات قوية.

   بالنسبة لخطافات الويب، تخطيط المصادقة، والتسليم غير المُرتَّب، والتكرارات، وإعادة المحاولات. جعل المعالجة مُتكرِّرة حيثما أمكن التكرار. المخرجات

   المخرج: سيناريو إعادة التشغيل والتأكيد. المخرجات

6. 6

   إصدار مع مسار خروج. المخرجات

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

   المخرج: خطة الترحيل وإثبات الإيقاف النهائي. المخرجات : خطة الترحيل وإثبات الإيقاف النهائي.

مؤشرات الإدارة

الأخطاء الشائعة

• افتراض أن رقم الإصدار وحده يحافظ على التوافق
• توثيق 200 استجابة فقط
• إرجاع تتبع داخلي أو سر في حالة الخطأ
• افتراض وصول روابط الويب مرة واحدة وبالترتيب