Veri akışını gözeterek API sürümünü değiştirmek
API geçişinde çağıran sistemler, verinin anlamı ve yanıtlar birbiriyle uyumlu olmalıdır. Somut bir test, geçişi denetlenebilir kılar.
Bir uygulama programlama arayüzünün (API) sürümünü değiştirirken ilgili veri akışlarını temel alın. Yeni uç nokta, geçişin yalnızca bir parçasıdır: Alanlar, izinler ve yanıtların yorumlanması da çağıran sisteme uygun olmalıdır.
Etkilenen çağıran sistemleri belirleyin
Varsayımsal şirkette müşteri portalı ve gece içe aktarma işlemi aynı API'ye sipariş gönderir. Yalnızca portalı geçirmek, ikinci çağıran sistemi eski sürümde bırakır. Her çağıran için hangi işlevleri kullandığını ve geçişini kimin yapabileceğini kaydedin. Gerçek sağlayıcının değişiklik ve kapatma bilgilerini esas alın; sürüm numarası, herkes için geçerli bir geçiş süresi vermez.
Google AIP-180, kaynak kodu, veri iletimi ve anlam uyumluluğunu birbirinden ayırır. Bu kılavuz, değişiklikleri incelemeye yardımcı olur; başka herhangi bir API'nin davranışını garanti etmez.
Değişikliği somut bir örnekle açıklayın
Örneğimizde eski istek, delivery_note alanında metin taşır. Yeni sürüm, metni delivery_note.text altında bekler. İkisinin de taşıması gereken teslimat talimatı aynıdır: “Tor B”. Bu nedenle yalnızca URL'yi değiştirmek veya bağlantının kurulması geçiş için yeterli değildir.
Kontrol sorusu | Örnekteki karar |
|---|---|
Ne korunmalı? | Doğru siparişte Tor B teslimat talimatı |
Teknik olarak ne değişiyor? | Metin alanı iç içe bir yapıya taşınıyor |
Başarı ne demek? | Hedef siparişte talimat değişmeden bulunuyor |
Metin yoksa ne yapılmalı? | Önceki gibi teslimat talimatı olmadan sipariş oluşturulur |
Hataların ve hâlâ devam eden işlemenin nasıl bildirildiğini de kontrol edin. İstek kabul edilmeye devam etse bile farklı bir yanıt yapısı çağıran sistemi etkileyebilir.
Eskiyi ve yeniyi aynı koşullarda karşılaştırın
Uygun bir test ortamında normal bir sipariş ve teslimat talimatı eksik bir örnek hazırlayın. Kaydedilmiş hedef verileri ve görünen yanıtı karşılaştırın. Kullandığınız erişim izinlerinin iki sürümü de kapsayıp kapsamadığını netleştirin. Bu karşılaştırma için gerçek siparişler, iki üretim yoluna birden gönderilmemelidir.
Geçişi açık işlemlerle koordine edin
Yeni isteklerin hangi noktadan itibaren yeni yolu kullanacağını belirleyin. Gönderilmiş ancak henüz onaylanmamış istekler, tekrarlarının yeni sipariş sayılmaması için eşlenmelidir. Yeni gelen istekler için eski yola dönüşü kararlaştırın; daha önce yazılmış verilere ne olacağını ayrıca inceleyin. URL'yi geri almak bu değişiklikleri geri almaz.
Kayda alınan bütün çağıran sistemlerin geçişi tamamlandığında ve açık işlemler eşlendiğinde eski sürüm bu veri akışından çıkarılabilir. Gerçekten kontrol edilen durumu yeni sürüm bilgisiyle birlikte belgeleyin.
Kaynaklar
Devamını okuyun
Tüm yazılar
ASES ile API ve entegrasyon
ERP, CRM ve mağaza sorunsuz bağlantılı