რადგან სერვისები დამოუკიდებლად იკეცებიან, თქვენ არასოდეს შეგიძლიათ ვივარაუდოთ, რომ მომხმარებლები სინქრონულად აქვთ განახლება. 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
}
ველის რიცხვები, არა სახელები, განსაზღვრავენ wire ფორმატს, ამიტომ ველების დამატება უკან თავსებადია.
Release v2 ─▶ run v1 + v2 together ─▶ migrate consumers ─▶ deprecate v1 ─▶ remove v1
თავი აარიდეთ ვერსიის წაშლას, სანამ რეალური ტრაფიკი ის კი იყენებს. თვალი ადევნეთ გამოყენებას წინ გამოქვეყნების.
დამოუკიდებელი განვითარებადობა მხოლოდ მაშინ მუშაობს, თუ წარმოებული შეიძლება აწარმოის ცვლილება კოორდინაციის გარეშე ყველა მომხმარებლის გამოშვების.
დიზაინი დამატებითი ცვლილებისთვის და ძველი ვერსიების მხარდაჭერა მიგრაციის დროს არის ის, რაც ინარჩუნებს იმ დამოუკიდებლობას სამსახურეზე დაღქეული დიდი ვერტიკალური განახლებების დაკავშირება.