Sunucu API ile sipariş ve sunucu yönetimi otomasyonu
Sunucu API entegrasyonunda sipariş durumu, yetkilendirme, tekrar denemesi ve kayıt tutma: server reseller operasyonları için uygulama planı.
Proje ilişkisi: VDSHost ve Takipci.gen.tr aynı işletmeciye aittir. Bu sayfa bağımsız bir ürün değerlendirmesi değildir.
Sunucu API entegrasyonunu yalnızca oluşturma isteği olarak düşünmeyin. Siparişin alınması, işlemin tamamlanması ve müşteriye doğru durumun gösterilmesi ayrı adımlardır.
Bu rehberde neler var?
- Siparişten çalışan sunucuya giden akışı çizin
- Aynı siparişin iki sunucu oluşturmamasını sağlayın
- Karar tablosu: durumunuzu değerlendirin
- Erişim anahtarları ve müşteri yetkilerini ayırın
- Test listenize hata durumlarını da ekleyin
- Zaman aşımı sonrası ikinci sunucuyu önlemek
- VDSHost ile entegrasyon kapsamını netleştirin
- Uygulama kontrolü ve dikkat edilecek nokta
- Sık sorulan sorular
Siparişten çalışan sunucuya giden akışı çizin
Bir müşteri sipariş verdiğinde ödeme kontrolü, kaynak uygunluğu, sunucu oluşturma ve teslim bildirimi birbirini izler. Bu adımları tek bir başarılı ekranla temsil etmek hataları gizleyebilir. Ödeme alınmış fakat sunucu henüz hazır değilse müşteri paneli bunu açıkça göstermelidir.
Sunucu API kullanımı, bu işlemleri kendi uygulamanızdan yönetmenizi sağlar. Ancak bir isteğin kabul edilmesi her zaman kurulumun tamamlandığı anlamına gelmez. Sağlayıcının yanıtlarını ve durum sorgulama yöntemini okuyup uygulamanızdaki durumlarla eşleştirin.
Aynı siparişin iki sunucu oluşturmamasını sağlayın
Bağlantı zaman aşımına uğradığında karşı sistem işlemi tamamlamış olabilir. Körlemesine tekrar oluşturma isteği göndermek ikinci bir kaynak açılmasına yol açabilir. Sipariş kimliğini saklayın ve yeniden denemeden önce mevcut işlem sonucunu kontrol edin.
Sağlayıcı tekrarlı isteği ayırt eden bir mekanizma sunuyorsa belgelenen kullanımına uyun. Sunmuyorsa kendi iş kuyruğunuzda aynı siparişin eşzamanlı işlenmesini engelleyin. Başarısı belirsiz işleri ayrı bir inceleme listesine almak, otomatik olarak başarılı saymaktan daha güvenilir bir teslim süreci kurar.
Karar tablosu: durumunuzu değerlendirin
Dar ekranda tüm sütunları görmek için tabloyu yatay kaydırabilirsiniz.
| Durum | Nasıl yorumlanır? | Sonraki adım |
|---|---|---|
| Sipariş alındı | Henüz kaynak oluşturma sonucu yok. | Müşteriye hazır sunucu bilgisi göstermeyin; işlem durumunu izleyin. |
| Kurulum belirsiz | Yanıt kaybolmuş veya gecikmiş olabilir. | Sağlayıcı kaydıyla mutabakat yapın; doğrudan tekrar oluşturma çağrısı yapmayın. |
| İptal bekliyor | Kurulum ve iptal süreçleri çakışıyor. | Kaynak yaşam döngüsünü ve ücret kararını birlikte inceleyen bir sonlandırma akışı kurun. |
Erişim anahtarları ve müşteri yetkilerini ayırın
Altyapı erişim anahtarını tarayıcıya veya mobil uygulamaya göndermeyin. İşlemleri sunucu tarafında yürütün ve her istekte ilgili kaynağın oturum açan müşteriye ait olduğunu doğrulayın. Yalnızca ekrandaki düğmeyi gizlemek başka müşterinin sunucusuna erişimi engellemez.
Üretim ve deneme hesaplarını ayırın. Anahtar yenileme sürecini, erişim yetkilerini ve günlüklerde hangi alanların gizleneceğini önceden belirleyin. Sunucuyu silme veya yeniden kurma gibi veri kaybettirebilen işlemlerde müşteriye hedef kaynağı ve işlemin sonucunu açıkça gösterin.
Test listenize hata durumlarını da ekleyin
- Yetersiz bakiye veya kapasite nedeniyle reddedilen sipariş.
- Zaman aşımından sonra sonucu belirsiz kalan kurulum.
- Aynı durum bildiriminin ikinci kez gelmesi.
- Başka müşteriye ait kaynak kimliğiyle yapılan istek.
- İptal edilen siparişin sonradan tamamlanan kurulumu.
Her senaryoda ücret, kaynak ve müşteri ekranının aynı gerçeği yansıttığını doğrulayın. Destek ekibinin takip edebilmesi için sipariş ile altyapı işlem kimliğini ilişkilendirin; günlüklerde parola ve erişim anahtarı bulundurmayın.
Zaman aşımı sonrası ikinci sunucuyu önlemek
AÇIKLAMALI ÖRNEK · TEMSİLÎ SENARYO
Bir müşteri tek sipariş veriyor; oluşturma çağrısı sırasında bağlantı kesiliyor. Uygulama sonucu bilinmeyen işlemi başarısız kabul edip tekrar gönderirse iki kaynak açılabilir. Siparişin yerel kimliği ile sağlayıcının işlem veya kaynak kimliği eşleştirilir. Sonuç belirsiz olduğunda yeni kaynak oluşturmadan önce mevcut durum araştırılır.
Otomasyon testinde aynı sipariş iki kez iş kuyruğuna verilerek tekrar davranışı incelenir. İptal talebi kurulumu sürerken gelirse hangi durumun geçerli olacağı da tanımlanır. Destek ekranı sipariş, ödeme ve kaynak durumunu ayrı göstermelidir. Bu akış belirli API uç noktalarını varsaymaz; VDSHost’un güncel belgelerindeki desteklenen yöntemler esas alınarak uygulanır.
VDSHost ile entegrasyon kapsamını netleştirin
VDSHost sitesinde API ile sunucu yönetimi ve bayi otomasyonu seçenekleri tanıtılıyor. Kendi sisteminize bağlamadan önce güncel API belgelerini, desteklenen işlemleri ve panel modüllerini inceleyin. Bir örnek isteğin çalışması bütün müşteri yaşam döngüsünün hazır olduğu anlamına gelmez.
Sunucu oluşturmanın yanında durdurma, yeniden kurulum, yedekleme ve hizmet sonlandırma ihtiyaçlarınızı ayrı ayrı listeleyin. API entegrasyonu kontrol listesini kullanarak kabul ölçütlerini belirleyebilir; sunucu bayiliği rehberiyle ticari sorumlulukları eşleştirebilirsiniz.
Uygulama kontrolü ve dikkat edilecek nokta
KENDİ ÇALIŞMANIZA UYGULAYIN
- Her kaynak isteğini tek müşteri ve sipariş kaydıyla ilişkilendirin; sahiplik kontrolünü sunucuda yapın.
- Silme ve yeniden kurulum gibi işlemlerde hedef kaynağın doğru olduğunu ayrıca doğrulayın.
- API hatalarını parolasız ve anahtarsız günlüklerle kaydedip belirsiz işlemleri görünür tutun.
Sık sorulan sorular
Sunucu API nedir?
Sunucu oluşturma, durum sorgulama ve yönetim gibi işlemleri bir yazılımdan yürütmeye yarayan arayüzdür. Desteklenen işlemler sağlayıcıya göre değişir.
Hazır panel modülü yeterli olur mu?
Standart işlemleri karşılayabilir. Kullandığınız sürüm, faturalama akışı ve hata durumları için ayrıca kabul testi yapın.
API anahtarı müşteriye verilmeli mi?
Ana altyapı hesabının anahtarı paylaşılmamalıdır. Müşteri işlemleri yetki kontrolü yapılan uygulama katmanından yürütülmelidir.
Otomasyonda insan müdahalesi tamamen kaldırılmalı mı?
Belirsiz ücret veya kaynak durumu gibi istisnalar için insan incelemesi gerekebilir. Amaç bu durumları gizlemek değil, sınırlı ve izlenebilir bir kuyruğa almak, tekrar oluşmalarının nedenini azaltmaktır.
Kaynaklar ve doğrulama
Bu kaynaklar ilgili platform veya teknik konu için referanstır. Örnek senaryolar editoryal açıklamalardır; bağımsız ürün testi veya gerçek müşteri sonucu değildir. Değişebilen koşulları işlem öncesinde resmi kaynaktan doğrulayın.
Bu rehber Takipci.gen.tr tarafından hazırlanmıştır. Temsilî senaryolar ve hesaplamalar yöntemi açıklamak içindir; ölçülmüş müşteri sonucu veya başarı garantisi değildir. Yayın ve kaynak yaklaşımımız.