Sertifika otomasyonunuz bir API'ye bağlıysa, sağlayıcı uç noktaları veya yanıt alanlarını değiştirdiğinde betikleriniz bir gecede bozulabilir. Sürümleme, bu değişikliklerin kontrollü yaşanmasını sağlayan sözleşmedir.
Yaygın Sürümleme Yöntemleri
| Yöntem | Örnek | Not |
|---|---|---|
| URL yolu | /v1/orders | En görünür ve test etmesi en kolay yöntem |
| İstek başlığı | Accept: application/vnd.api+json; version=2 | URL'ler sabit kalır |
| Sorgu parametresi | ?api-version=2024-01-01 | Tarih tabanlı sürümlerde sık görülür |
İstemci Tarafında Yapılacaklar
- Sürümü koda gömmek yerine tek bir yapılandırma değişkeninde tutun.
- Her zaman açık sürüm belirtin; "varsayılan sürüme" güvenmeyin, çünkü varsayılan değişebilir.
- Yanıtları ayrıştırırken bilinmeyen alanları yok sayın; yeni alan eklenmesi sizi kırmamalı.
- Yeni sürümü önce test ortamında çalıştırıp çıktıları eski sürümle karşılaştırın.
API_BASE="https://api.example.com/v2"
curl -s "$API_BASE/orders/12345" -H "Authorization: Bearer $TOKEN"
Kullanımdan Kaldırma Uyarıları
İyi tasarlanmış API'ler eski sürümü kapatmadan önce duyuru yapar; bazıları yanıtlara Deprecation veya Sunset başlıkları ekler. Bu başlıkları izleyen basit bir kontrol, sürpriz kesintileri önler:
curl -sI https://api.example.com/v1/orders | grep -i -E "deprecation|sunset"
Geriye Dönük Uyumluluk
Alan ekleme genellikle uyumlu kabul edilir; alan silme, tip değiştirme veya anlam değiştirme ise yeni ana sürüm gerektirir. Kendi bayi/entegrasyon API'nizi sunuyorsanız aynı kuralı uygulayın ve değişiklik günlüğü tutun.
Sürüm geçişlerinde sertifika siparişlerinizin aksamaması için bilgi bankamızdaki entegrasyon yazılarına, sipariş ihtiyaçları için SSL sertifikaları sayfasına bakabilirsiniz.