कारण सेवा स्वतंत्रपणे तैनात केल्या जातात, तुम्ही कधीही असे गृहीत धरू शकत नाही की कॉलर्स लॉकस्टेपमध्ये अपग्रेड करतात. API versioning अधिक backward compatibility हे निर्माताांना विद्यमान ग्राहकांना खंडित न करता विकसित होऊ देते.
कारण सेवा स्वतंत्रपणे तैनात केल्या जातात, तुम्ही कधीही असे गृहीत धरू शकत नाही की कॉलर्स लॉकस्टेपमध्ये अपग्रेड करतात. API versioning अधिक backward compatibility हे निर्माताांना विद्यमान ग्राहकांना खंडित न करता विकसित होऊ देते.
| धोरण | उदाहरण |
|---|
| URI path | GET /v2/orders/42 |
| Header | Accept: application/vnd.api.v2+json |
| Schema evolution | फील्ड जोडा, कधीही काढू किंवा पुनः नाम देऊ नका |
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
कधीही आवृत्तीला काढू नका जेव्हा वास्तविक ट्रॅफिक त्याचा वापर करते. निवृत्त होण्यापूर्वी वापर ट्रॅक करा.
स्वतंत्र परिनियोजन केवळ तेव्हाच कार्य करते जेव्हा निर्माता प्रत्येक ग्राहकाच्या सोडणीचे समन्वय न करता बदल पाठवू शकतो.
अव्य बदलांसाठी डिজाइन करणे आणि स्थलांतरणाच्या दरम्यान जुन्या आवृत्त्यांचे समर्थन करणे हे आहे जे त्या स्वतंत्रतेला जतन करते, तर नाजूक मोठ्या-बँग अपग्रेडला भाग पाडत नाही.