Mobil İstemcilerin Kullandığı Genel API'leri Sürümlemek

Mobil gecikme kalıcı bir kısıttır

Mağaza incelemesi, MDM dondurmaları ve güncellemeyi yok sayan kullanıcılar API'nizin birden fazla istemci neslini aynı anda sunmasını gerektirir.

En eski desteklenen uygulama sürümünü birinci sınıf tüketici sayın.

Hızlı alan yeniden adlandırma isteğinde ilk soru: hangi uygulama sürümleri eski şekli hâlâ parse ediyor ve ikisini ne kadar taşıyacaksınız?

Sürümü sözleşmede tutun

Açık API epoch'ları (header veya path) kullanın; istemci build kimliğini her istekte göndersin.

Alanları ölçülü deprecation olmadan kaldırmayın; sunset ipuçlarını yapılandırılmış hatalarda döndürün.

İnsan release notlarının yanında makine okunur uyumluluk notları yayınlayın; istemci ekipleri davranışı trafikten reverse-engineer etmesin.

• API epoch başına minimum uygulama sürümü içeren mobil uyumluluk matrisi yayınlayın
• Breaking change'leri yanıtta sunset tarihli sözleşme olayları olarak ele alın
• CI'da en eski desteklenen uygulama build'lerinden shadow trafik çalıştırın
• Sürüm skew'ini ölçün: hangi build'ler deprecated alanlara vuruyor

Release ve destekle koordine edin

API sunset'lerini uygulama içi güncelleme ve destek makrolarıyla eşleyin.

CI'da en eski desteklenen client bundle ile sözleşme testleri çalıştırın.

Destek ve success ekiplerinin tek bir minimum sürüm ve sunset matrisi olsun; her olay aynı skew tablosunu yeniden icat etmesin.

Kesmeden önce skew ölçün

Aktif uygulama sürümlerini API epoch kullanımına karşı panoda izleyin.

Disiplinli sürümleme, mobil'i rehin almadan backend geliştirmenizi sağlar.

Yalnızca deprecated yollarda trafik ihmal edilebilir seviyedeyken ve uygulama içi güncelleme kapsamı sert kesmeyi taşıyabiliyorken cut yapın.

• Stripe — API versioning
• Microsoft — REST API guidelines
• Apple — App Store review guidelines