نظراً لأن الخدمات تُنشر بشكل مستقل، لا يمكنك أبداً افتراض أن المستخدمين يقومون بالترقية بشكل متزامن. إصدار نسخ واجهات برمجية التطبيقات بالإضافة إلى التوافق العكسي يسمح للمُنتجين بالتطور دون كسر العملاء الموجودين.
نظراً لأن الخدمات تُنشر بشكل مستقل، لا يمكنك أبداً افتراض أن المستخدمين يقومون بالترقية بشكل متزامن. إصدار نسخ واجهات برمجية التطبيقات بالإضافة إلى التوافق العكسي يسمح للمُنتجين بالتطور دون كسر العملاء الموجودين.
| الاستراتيجية | مثال |
|---|
| مسار URI | GET /v2/orders/42 |
| رأس الطلب | Accept: application/vnd.api.v2+json |
| تطور المخطط | إضافة حقول، عدم الحذف/إعادة تسمية |
NON-BREAKING (safe):
✓ add a new optional field
✓ add a new endpoint
✓ add a new enum value (if clients tolerate unknowns)
BREAKING (needs a new version):
✗ remove or rename a field
✗ change a type or make a field required
✗ change semantics of an existing field
message Order {
string id = 1;
double total = 2;
string currency = 3; // NEW field 3 — old clients ignore it safely
}
أرقام الحقول، وليس الأسماء، تُحدد تنسيق السلك، لذا فإن إضافة حقول متوافقة مع الإصدارات السابقة.
Release v2 ─▶ run v1 + v2 together ─▶ migrate consumers ─▶ deprecate v1 ─▶ remove v1
لا تقم أبداً بحذف نسخة بينما لا تزال هناك حركة مرور حقيقية تستخدمها. تتبع الاستخدام قبل الإيقاف.
النشر المستقل يعمل فقط إذا كان بإمكان المُنتج شحن تغيير دون تنسيق إصدار كل عميل.
التصميم للتغيير الإضافي ودعم الإصدارات القديمة أثناء الترحيل هو ما يحافظ على هذا الاستقلال بدلاً من فرض ترقيات كبرى هشة.