“Herkese açık API'lar sonsuza dek: Doğru olanı elde etmek için yalnızca bir şans”?


20

Bir işletim sistemi kitabında şunu okudum: "Herkese açık API'lar sonsuza dek: Doğru olanı elde etmek için yalnızca bir şans". Bu doğru mu? Yalnızca İşletim Sistemleri API'larında veya diğer API'larda da uygulanabilir mi? Örneğin, bu, Tasker, Locale ve Pushover gibi Android Uygulamalarının API'ları için geçerli olacak mı?


2
İlkeyi tüm kodlara genişletirim. Aynı şeyi birden çok kez yazmak için yeterli zaman yok. Mükemmel kod yazmak öğrenilebilecek bir beceridir.
tp1

22
@ tp1: mükemmel kod yazmak gerçek dünyada bulunmayan bir beceridir.
Michael Borgwardt

4
@michael borgwardt: Sadece hangi mükemmel sürümü kullanacağınızı seçmeniz gerekiyor.
tp1

1
Bunu gerçek dünyada gördüm ve ne tür bir API'ya bağlı. Alınan ders: herhangi bir "herkese açık" web API'sindeki ilk gereksinim, API kullanıcısının hangi API sürümünü kullanacaklarını seçebilmesidir.
Josh Petitt

Yanıtlar:


32

Genel olarak herhangi bir herkese açık API için doğrudur, evet. Bir API'yi herkese açık hale getirdikten ve insanlar bu API'ye bağlı uygulamalar oluşturmaya başladığında, API'yi değiştirmek son derece zorlaşır, çünkü bunu yapmak tüm uygulamaları bozacaktır. Bu hem zor bir teknik sorun hem de zor bir politik sorun olma eğilimindedir.

Tabii ki, genel bir API'yi değiştirmek mümkündür. Örneğin, projelerin bir sürümde bir API'yı dağıtacağı, yeni bir API tanıtacağı ve daha sonraki bazı sürümlerde eski API'yi kaldıracağı anlaşılıyor. Ancak bu, eski API'yi kullanan her (önemli) uygulamanın, eski API kaldırılmadan önce yeni API'yi kullanacak şekilde yeniden yazılacağını varsayar. Bu genellikle birkaç yıl alır. Bu, genel API sahibinin, API'yi tüketen diğer tüm projelere maliyet yüklediği anlamına gelir. Genellikle bir API'nın çok daha fazla tüketicisi olduğundan, bu tüketiciler nispeten güçlü bir siyasi lobi olma eğilimindedir.


2
"zor bir teknik sorun hem de zor bir teknik sorun" İki kez "teknik" tekrarladı.
luiscubal

12
@luiscubal: çünkü bu gerçekten çok zor bir teknik problem.
Michael Borgwardt

3
@luiscubal Bir kere demek istiyorsun. Bir kez tekrarlandı, iki kez söyledi.
Joe Z.Şubat

4
"Genel Yanıtlar değil ..."
Chris

3
@Chris Pek değil. Justin'in yanıtı artık luiscubal'ın yorumuyla uyumlu değil. :-)
svick

12

Alıntı yazarı Joshua Bloch, ifade onun Tampon-Etiket API Tasarım makalesinden:

Elmaslar gibi herkese açık API'lar sonsuza kadar. Doğru bir şansınız var, bu yüzden elinizden gelenin en iyisini yapın.

Bu konuda daha ayrıntılı bilgi için, yazar, onun konferans oturumu sunum okuyucuları eder "İyi API Tasarım Nasıl ve Neden Önemlidir" . Slayt API Tasarımının Sizin İçin Neden Önemli Olduğu, bunun herhangi bir programlama etkinliği (işletim sistemleri olsun ya da olmasın, yazar için önemli değil) ile ilgili olduğunu açıkça belirtir:

  • Programlıyorsanız, bir API tasarımcısısınız

    • İyi kod modülerdir - her modülün bir API'si vardır
  • Faydalı modüller yeniden kullanım eğilimindedir

    • Modülün kullanıcıları olduğunda, API'yi istediği gibi değiştiremezsiniz
    • İyi yeniden kullanılabilir modüller kurumsal varlıklardır
  • API'ler açısından düşünmek kod kalitesini artırır

Slayt Sonuç ayrıca bunu genel bir yaklaşım olarak vurgulamaktadır:

  • API tasarımı asil ve ödüllendirici bir zanaat

    • Programcıların, son kullanıcıların, şirketlerin çoğunu geliştirir ...

2
Teknik olarak elmas metastabildir. Termodinamik olarak, grafit daha kararlı bir karbon şeklidir.
13'te

3

API'lar her zaman değişir, aksi takdirde sistem yükseltmesinin anlamı ne olur? Yalnızca dahili öğeler mi değiştiriliyor?

Sistemin her sürümü yeni API'ler getirir, eski API'ler eski haline gelir ve eski API'ler kaybolur.

API değişikliği sadece teknik olarak ve iletişim açısından çok dikkatli olmalıdır.


Tüm tüketicilerinizle iyi iletişim kurabildiğiniz ve kullanıcılarıyla konuşabildikleri sürece - Windows'a bakın: Windows, son kullanıcıların modern sistemlerde bile son derece eski uygulamaları çalıştırmaktan hoşlandığı gibi tonlarca eski, kullanımdan kaldırılmış, kötü API'ye sahip
johannes

2

Benim düşüncem, yayınlandıktan sonra, API'nın bu 'sürümü' sonsuza kadar sürecek, ancak '2.0' API'sını yayınlayarak onu kullanımdan kaldırabilirsiniz (bunun gerçekleştiği birkaç örnek var - şu anda, piyasaya sürülen Strava'yı düşünebilirim hizmetlerini tüketmeye yönelik geliştirme için bir API'nin 2.0 sürümü).

Sorun orijinal API reklam sonsuz destekliyor ... Sanırım bu eski API kullanımı ve bu API tüketicilerin size ne değer bağlıdır.

Windows 3.x ve 9x vb.'nin 'eski günlerine' geri dönersek, yayınlandıktan sonra, bu OS API'leri yapıldı ve ayarlandı. Şimdi, OS güncellemeleri her zaman itiliyor, bu yüzden yeni API'ler piyasaya sürülebilir, ancak belirli bir OS lezzetini (ana sürüm) çalıştırdığınız sürece, bu API'ler yalnızca eklenir, asla kaldırılmaz ... Yine de 'bir sonraki' büyük sürüm için böyle olun.

Hmm, belki de asıl sorudan uzaklaştım.


1

Ne tür bir API olduğuna bağlıdır (ve değişiklikleri bozduğumu varsayıyorum, aksi takdirde ifade açıkça doğru değildir).

Arayan hangi sürümü kullandığını seçebiliyorsa (örneğin çağıran uygulama ile birlikte gelen kütüphaneler / çerçevelerle), API'yi değiştirmek büyük bir sorun değildir - ancak yazılımın itibarı için hala kötüdür. İnsanlar sorunsuz bir şekilde yeni sürüme geçmeyi sever.

Öte yandan, kullanıcılar API'nın eski sürümünü (çevrimiçi bir hizmet veya eski sürümleri çalıştırmanın çok istenmeyen olduğu bir tarayıcı veya işletim sistemi gibi) kullanmaya devam edemediğinde, API'ları uyumsuz bir şekilde değiştirmek çok kötüdür. Gerçekten de, onu kullanan ve güncellenmeyen tüm yazılımları kıracağından. Bu, geliştiricilere bir bakım maliyeti getirir ve bunun için sizden nefret ederler. Ve bakımı yapılmayan ve kesilen yazılımlar da size kötü yansıyacaktır.

Sürükleyici yandan, API'da sürekli olarak değişiklikler yapan ve yine de gülünç derecede başarılı olan en az bir API sağlayıcısı var : Facebook. Ancak değişiklikleri çok dikkatli bir şekilde yönetiyorlar: yayınlanmış bir politika var , değişiklikleri en az 90 gün önce ilan edip açıklıyor ve geliştiriciler bu zaman diliminde erken etkinleştirmeyi seçebilirler.


1

API'nın kendisine bir sürüm numarası eklemeyi öngörürseniz. Bağlantı / başlatma çağrısında veya her çağrıda parametre listesinin başlangıcına yakın bir yerde, API'niz mevcut istemcileri bozmadan zaman içinde gelişebilir ve değişebilir.


0

Yaptığımız tek şey onları bir seferde en iyi yapmak olsa da, zaman değişikliği ve iyileştirme geldiğinden, bazen dev sağlayıcıların çoğunun yaptığı gibi bilgileri güncellememiz gerekir (yüz kitabı birkaç güncelleme, twitter bir büyük oAuth ve birkaç majör için dönüyor, ancak mümkün olduğunca tüm iyileştirme ile geliyor, bu yüzden sık değişiklik yok.Ve evet lütfen eski olanı desteklemeyi bırakmayın, acıyor !!


-1

Açıkça bir API içerecek her türlü iletişim protokolünü serbest bıraktığınızda, protokolün / arayüzün geriye dönük uyumlu ve genişletilebilir olması anlamında doğru bir şansınız vardır.

Bu, eski sürümleri kullanan kişileri bozma konusunda endişelenmenize gerek kalmadan yeni işlevler eklemenize ve yeni sürümler yayınlamanıza olanak tanır. Yazılım dünyasında hiçbir zaman belirli bir zamanda zor bir kesime sahip olabileceğiniz bir durum olmayacak ve herkes eski sürümü bırakıp yeni sürümü kullanmaya başlayacak.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.