Bir web API'sından vazgeçme: En İyi Uygulamalar?

Sonunda, herkese açık web API'nızın bölümlerini amortismana tabi tutmanız gerekir. Ancak bunu yapmanın en iyi yolunun ne olacağı konusunda kafam karıştı. Büyük bir 3. taraf uygulama tabanınız varsa, API'nın eski sürümlerini sormak neredeyse tüm uygulamalar bir gecede başarısız olacağından bunu yapmanın yanlış yolu gibi görünüyor. Ancak eski web api'leri sonsuza kadar kullanılabilir ya da onunla çalışmayı imkansız kılan önemli değişiklikler olduğu için sonsuza kadar mevcut tutamazsınız.

Eski web api'lerini kullanımdan kaldırmaya yönelik en iyi uygulamalar nelerdir?

Orijinal posterin zaten etkili olduğu anlaşılıyor, ancak gayri resmi olarak API'larını ('eski API' olarak adlandırılan herhangi bir şey) kullanımdan kaldırıldı. Ancak, ilan edilene ve kullanıcılar bir API'nın kullanımdan kaldırıldığı bildirilene kadar, resmi olarak kullanımdan kaldırılmaz.

Kullanımdan kaldırılmış API, kodun geçici, etkin olmayan bir aşamasıdır. Bu son ayinler. Bu, benimseyenlerin / tüketicilerin uygulamalarını daha yeni bir API için yeniden yapılandırmasına ve API ile barışı sağlayarak hoşçakal veda etmesine izin veren dönemdir. Bazı API'lar diğerlerinden daha uzun süre kalabilir, ancak bu noktada zamanlarının uzun olmadığını biliyoruz.

Silinmiş API bir kod cenazesidir. Yapabileceği daha fazla bir şey yok, ancak uygun şekilde atılmış ve uygun şekilde anılmış.

Birçok API ve hizmet geliştiricisi, son ayinleri gerçekleştirmek yerine kod cenazelerini tercih eder; ancak bunun biraz riskli olduğunu düşünüyorum. API / hizmet başlangıçta kabul edildiğinde veya yenilenirken herhangi bir hizmet veya destek sözü verildiyse, cenaze törenini gerçekleştirmeden önce bu taahhüdü makul bir süre yerine getirmek isteyebilirsiniz.

Hizmet dışı kütüphaneler için, zaman dilimine bakılmaksızın büyük bir sürümün muhtemelen kabul edilebilir ve adil bir geriye dönük uyumluluktan daha fazla olduğunu düşünüyorum. Bunun ötesinde, ömrünü o dönemin ötesine uzatmak, kullanıcıların etkisine ve lobisine bağlıdır. Ve zaman zaman değiştirilemez 3. taraf bağımlılıklarının limboda sıkışması ve belirli platformların belirli sürümlerine bağlı olması nedeniyle itirazlar varsa şaşırmayın.

Hizmetler için, sadece bir hizmetin kim tarafından ve nasıl tüketilebileceği ve projeyi tüketmekten projeyi tüketmeye karşılık gelen geliştirme döngüsü varyansı nedeniyle altı ay veya yıl dönemine bakmak isteyebileceğinizden şüpheleniyorum - hizmetinizi tüketebilecek birçok proje hala ön tasarımda büyük olabilir ve bir yıldan daha uzun bir yayın döngüsü planlayabilir. Dışarıdan gelen çoğu geliştirici görüşü, uzun programlara sahip olanların döngü sürelerinizi karşılamaktan sorumlu olduğunu ve uzun döngü tüketen projelerin daha hızlı bir serbest bırakma döngüsünü benimsemesi gerektiğini önerecektir ve bu doğru olabilir. Ancak nihayetinde silme tarihi, kullanıcılarla müzakere etmeniz gereken bir şeydir.

Kullanımdan kaldırma için iyi ancak kurşun geçirmez bir strateji, kullanımdan kaldırılmanın açıklanması, söz konusu API bölümlerinin bir anket biçiminde yorum veya itiraz talebinin yanı sıra silme niyetinin zaman aralığını vurgulamak olabilir. Hizmetiniz [yarı] anonim erişim ile çalıştığı için bir kullanıcı listeniz yoksa, sık ve etkin kullanıcılar için günlüklere bakabilir ve uygun gördükleri şekilde iletmek için bildirimi ana bilgisayara veya etki alanı yöneticisine gönderebilirsiniz.

Kullandığım Web API'lerinin çoğunun (Google, Yahoo! ve Microsoft gibi şirketlerden) "gün batımı" süresi vardır. Geliştiriciler, amortismana tabi olacak özelliklerden makul bir süre (3-6 ay) içinde önceden yükseltmeleri için bolca zaman tanıyacak şekilde bilgilendirilir.

Gün batımı dönemlerinin ayrıntılarını, hizmet şartlarına veya diğer belgelere ekleyerek insanların nasıl çalıştığını bilmesini sağlayabilirsiniz. Bu, birisi API'nizi kullanmaya karar verdiğinde hangi programlarla birlikte çalışması gerektiğini bileceği anlamına gelir. Örneğin, insanları yılda bir kez sistemlerini yükseltmeleri gerekeceği konusunda bilgilendirebilir ve bunu 4 ay önceden bildirebilirsiniz.

Sürüm numaralandırma kullanmak da iyi bir fikirdir, örneğin "sürüm 3 yakında amortismana tabi tutulacaktır, bu nedenle kodunuzun sürüm 4 ile çalıştığından emin olun" vb. 4 Gün batımına hazırlar.

Proses açısından ek bilgiler:

• Tüm paydaşlarla iletişim kurun : Diğer ekiplere ve API tüketicilerine, API'yi kullanım dışı bırakma nedeni, strateji, plan ve zamanlama ayrıntıları, sürüm oluşturma anlamı ve alternatifler hakkında HTTP'yi uygun şekilde ayarlayın.

• Planla ve Planla : Planda, kullanımdan kaldırma için önemli kilometre taşlarına ve hedef tarihe sahip olmalısınız. Tüketicilere aynı şeyi sormalı ve çağrıyı kullanımdan kaldıracakları tarihler vermelisiniz. Süreci izlemek ve tüketicileri desteklemek için düzenli bir toplantı düzenleyin.

• Sürüm Oluşturma ve Alternatifler Sağlama : Sürüm oluşturma , büyük sürümlerde ara değişikliklerini göstermeye ve API kullanımdan kaldırma stratejisini oluşturmaya yardımcı olabilir.

• Gün Batımı HTTP Yanıt Başlığını Ayarlama : HTTP başlıkları uyarının teknik kısmını oynatır, API tüketicileri bir API'nın ne zaman kullanımdan kaldırıldığını anlamak için bu tür kodu izlemelidir.

• Önce ve Sonra İzle : Tüketicilerinizi izleyin ve belirli bir süre sonra hala API'yı kullanan tüketicileri hiçbir terk etme yazılımını kaçırmamanız için yararlı bilgiler olarak uyarın.

Mevcut yanıtlara ek olarak, bir şeyi kaldırırken bir bırakma değiştirme veya taşıma planı sunmalısınız, böylece kullanıcılarınız kodlarını güncelleyebilir.

Alternatif sunmadan işlevselliği kaldırmaktan kaçının - bu, bazı kullanıcılarınızı mutsuz eder.