API Ürün Yönetiminde Platform Zihniyeti

Salgının, kuruluşların önce dijital bir strateji benimseme ihtiyacını önemli ölçüde artırdığı bir sır değil. Diğer kurumsal hedefler lehine önceliği düşürülen dijital dönüşümler, eşi benzeri görülmemiş bir aciliyetle bir gecede öne ve merkeze kaydı. 2020 McKinsey Küresel Yönetici Anketi'ne göre, şirketler, COVID-19'un yol açtığı önemli zorluklara rağmen, dahili operasyonlarını dijitalleştirme ve dijital ürün portföylerini birkaç yıl boyunca genişletme oranlarını hızlandırdı.

Bu dijital dönüşümlerin merkezinde, uygulama programlama arabirimleri (API'ler) tarafından kolaylaştırılan entegrasyon yer alır. Bir zamanlar yazılım sistemleri arasında veri ileten “haberciler” veya “aracılar” olarak düşünülen API'ler, artık dijital ekosistemlerin “bağ dokusu” olarak kabul edilmekte ve onları oluşturan ve kullanan kuruluşlara sınırsız entegrasyon ve iş fırsatları sunmaktadır. API'lerin temsil ettiği benzersiz potansiyel nedeniyle, geliştirmelerini denetleyen ürün yöneticileri, kusursuz entegrasyon deneyimleri sağlamak için esneklik ve genişletilebilirliği vurgulayan, gizli değerleri açığa çıkaran bir yaklaşım benimsemelidir.

Daha Azıyla Daha Fazlasını Yapmak

Geçtiğimiz benzeri görülmemiş yıldan önce bile, API'lerin kuruluşlar için değeri iyi belgelenmişti ve API ekonomisi bir süredir gelişiyordu. Günümüzün entegrasyon ortamını anlamak için Best of Breed (BoB) felsefesinin kökenlerini araştırmak faydalı olacaktır. 1990'lardan önce, yazılım satıcıları, çok çeşitli kurumsal zorlukları çözmeye çalışan kurumsal kaynak planlama (ERP) paketi çözümleri pazarladı. Giderek, bu süitler, kuruluşa özgü kullanım durumlarını ele almadıkları için hantal ve pratik olarak görülmeye başlandı. Sonuç olarak, satıcılar, herkes için her şeyi yapmaya çalışan daha büyük süitler yerine, tek bir işlevsel alan için zorlukları çözen daha odaklı araçlar oluşturmaya başladı. İşletmeler, çeşitli daha küçük, daha özel araçlar arasından seçim yapma fikrini memnuniyetle karşıladı ve kendi özel ihtiyaçlarına en uygun bireysel çözüm koleksiyonlarını birleştirmeye başladı.

Noktaları birleştirmek

BoB yaklaşımı ivme kazandıkça, entegrasyonlar ürün stratejilerinin çok önemli bir parçası haline geldi. Bir işletmenin bir alanı için sorunları çözmede harika olan bir araç, onunla birlikte kullanılması muhtemel olan diğer BoB ürünleriyle iyi bir şekilde bütünleşebilmelidir. Satış hatlarını ve müşteri ilişkilerini izlemek ve optimize etmek için kuruluşlar tarafından uygulanan satış ve CRM yazılımı olan HubSpot'u düşünün. HubSpot, müşterinin mühendislik ekiplerinden ek geliştirme gerektirmeden DocuSign (dijital imzalar), Twilio (e-posta/SMS bildirimleri) ve Zendesk (müşteri desteği) gibi diğer BoB yazılımlarıyla kolayca entegre olur.

Birbirine sorunsuz bir şekilde bağlanmak için tamamlayıcı araçlara duyulan ihtiyaç, sistemler arasındaki etkileşimleri sınırlamak yerine endüstri çapında açıklığı benimsemeye doğru bir geçişle birlikte geldi. Bir yerde, bir ürünün desteklediği entegrasyonların sayısı pazarlamaya değer bir ölçü haline geldi.

Platform Önerisi

Ancak entegrasyonların gerçek değeri, farklı araç ve sistemleri koordine etme yeteneklerinin ötesine geçer. API'ler, ürünleri platformlara dönüştürmek için toplu mekanizmadır. Ürünler, tanım gereği, belirli bir uygulamaya sahip araçlardır; dolayısıyla "uygulamalar". Çoklu değer önermeleri ve buna bağlı olarak çoklu gelir akışları yaratma yetenekleri sınırlıdır. Platformlar ise farklı bir şekilde değer katar: çok sayıda ürünün üzerine inşa edilebileceği altyapı katmanını sağlayarak.

API'ler, onlardan yararlanan üçüncü tarafların uzmanlığından yararlanarak yeni iş kanalları açar. Tüketici geliştiriciler, kullanıcıların ev aramasına yardımcı olmak için Google Haritalar'ın Yerler API'lerini kullanan bir emlak uygulaması tasarlayabilir veya belirli bir konuma seyahat konusunda uzmanlaşmış bir ekoturizm sitesi oluşturmak için Skyscanner'ın Uçuş API'lerinden ve Expedia'nın Otel API'lerinden yararlanabilir. Bu geliştiriciler ve harici ortaklar, işletmeleri için uyarlayabilecekleri mevcut verilere ve hizmetlere erişim kazanarak fayda sağlar ve Expedia gibi API sahipleri, örneğin yalnızca ürünlerinde otelleri listelemeye devam etselerdi ulaşamayacakları fırsatlardan para kazanır ve erişimlerini genişletir.

Modüler Hale Getirmek

Ürün liderleri için başarılı bir API stratejisi geliştirmek, ürün düşüncesinden platform düşüncesine bir zihniyet değişimi gerektirir. Bu, ürünleri, işlevselliklerinin yeniden birleştirilmesine olanak tanıyan ve tüketici geliştiriciler için esnekliğe öncelik veren modüler, açık uçlu bir tarzda oluşturmak anlamına gelir. Müşterilerin çeşitli ihtiyaçları karşılamak için farklı şekillerde satın alabilecekleri, monte edebilecekleri ve özelleştirebilecekleri IKEA raf sistemlerini düşünün. İyi API ürün yöneticileri, API'leri oldukları gibi görür: işi ölçeklendirmek ve değerli ortaklıklar geliştirmek için araçlar. Bu potansiyeli tanımak, benimsemeyi sağlamak için en iyi uygulamaları uygulamak anlamına gelir.

Geliştiricileri Memnun Etmek

Sağlam bir API stratejisinin bir temel direği varsa, o da geliştirici deneyimidir (DX). API entegrasyonları için, "müşteriler" ürün yöneticilerinin, geliştiricileri tüketmekten memnun olması gerekir. Bunlar, nihai olarak bir API'yi arayan/entegre eden kullanıcılar, üründen platforma bir vizyonun gerçekleştirilmesine yardımcı olabilecek potansiyel ortaklardır. Deneyimlerini "UX" yerine "DX" olarak etiketlemek, tipik son kullanıcılar olmadıklarını, teknik açıdan önemli ölçüde daha usta olduklarını kabul eder. Onlarla empati kurabilmek için onların özel ihtiyaçlarını ve beklentilerini anlamak esastır.

En İyi Uygulamalar

Aşağıdakiler, hiçbir şekilde kapsamlı bir listeyi temsil etmese de, tüketen geliştiriciler için sorunsuz ve tutarlı, öngörülebilir entegrasyon deneyimleri sağlayan birinci sınıf API'ler oluşturmak için gerekli uygulamalardır. Ürün yöneticileri, API'leri ölçeklenebilir bir şekilde tasarlamaya, en iyi uygulamalar çerçevesini tanımlamaya ve bunu ekiplerin yeni API'ler oluştururken başvurabilecekleri bir belge olarak yayınlamaya yaklaşmalıdır.

Tutarlı adlandırma kuralları ve uç noktalar

API'nin yapısını ve amacını açıkça tanımlayan API uç noktaları için tutarlı adlandırma kuralları oluşturmak, belirsizliği ortadan kaldırır ve olumlu ve öngörülebilir bir DX'e katkıda bulunur. Tüm API'ler için ortak bir temel URL ve sondaki URL için jargon ve kısaltmalardan kaçınan bir çerçeve seçmek en iyisidir. Nordic API'leri, uç noktaları adlandırmak için yararlı bir ipuçları listesi sunar.

Ayrıntılı başarı ve başarısızlık yanıt yapıları

Geliştiriciler, başarı ve başarısızlık yanıtları için tanıdık veri nesneleri ve durum kodları ister ve bekler. Bu, başarı senaryoları için 2xx durum kodu, istemci tarafı arızalar için 4xx kodu ve sunucu tarafı hataları için 5xx kodu anlamına gelir. Ancak, özgüllük anahtardır. Ek bilgi olmadan basitçe 4xx yanıtı döndüren bir "e-posta gönder" API'sine yapılan çağrı, geliştirici deneyiminin kötü olmasına neden olur, çünkü tam olarak neyin yanlış gittiğine dair ek bilgi vermeden yalnızca hatanın istemci isteğinde olduğunu onaylar.

 { "status": 400, "message": "incorrect request" }

Buna karşılık, insan tarafından okunabilir biçimde ve benzersiz bir hata kodu biçiminde belirli ayrıntılar sunan bir yanıt, geliştiricilerin hata senaryosunu nasıl düzelteceklerine, sorunu çözmek için kod yazmaya ve API çağrısını yeniden denemeye hızla karar vermelerine yardımcı olabilir.

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

Optimum DX için, yanıt yapıları ve durumu bildiren anahtarlar, API'ler arasında tutarlı olmalıdır. Örneğin, yukarıdaki hata kodu alanı, bazı API'lerde "kod" ve diğerlerinde "errorCode" olarak değil, her API'de değişmez bir şekilde "kod" olarak anılmalıdır.

Yapılandırılabilir hız limitleri

Hız sınırları, bir kullanıcının tek bir zaman biriminde onu kaç kez arayabileceğini belirleyerek bir API'nin ne kadar erişilebilir olduğunu belirler. Çok yüksek oran sınırları, performansı düşüren yönetilemez sayıda istekle sistemlere taşabilirken, makul olmayan şekilde düşük hız sınırları, bekleyen işlemlerin kullanıcıların sistemlerinde sıraya girmesine neden olabilir. Her ikisi de zayıf DX'e katkıda bulunur. API'leri tasarlarken, belirli iş durumlarına ve koşullara göre ayarlanabilen oran sınırlarına izin vermek en iyisidir. Örneğin, yüksek hacimli müşteriler, API'leri daha sık aramak için gerçek bir ihtiyaç duyabilir.

Uygun hız sınırlarını en iyi şekilde belirlemek için, ilk olarak API'leri çağrıldıkları sıklık ve hacme göre anlamlı kategoriler halinde gruplandırmak yararlıdır. Örneğin, birincil müşteri verilerini (profil/hesap oluşturma) yapılandıran API'ler daha az sıklıkta çağrılır ve daha düşük oran sınırlarını işleyebilirken, işlem API'leri ("sipariş oluştur", "e-posta gönder") daha sık çağrılır ve daha yüksek oran sınırları gerektirir. Farklı kullanım durumları için kategoriler veya katmanlar oluşturmak, daha güvenilir ve ölçeklenebilir API'ler sağlar. Açıkça tanımlanmış hız limitlerinin bir örneği için Slack'in API belgelerine bakın.

Kapsamlı belgeler

Belgeler, bir API için kullanım kılavuzu görevi görür. Bir API'nin ne yaptığını, nasıl kullanılacağını ve ondan ne bekleneceğini geliştiricilere açıkça ifade eder. İyi belgeler açık, erişilebilir bir dilde yazılmıştır, ayrıntılı ve etkileşimlidir ve entegrasyonu kolaylaştırmak için çok sayıda demo ve kod parçacığı sunar. Bu şekilde, bir geliştiricinin ilk API'sini ne kadar hızlı bir şekilde başarılı bir şekilde çağırabileceğini gösteren önemli bir ölçüm olan İlk Merhaba Dünyaya Geçiş Süresi'ni (TTFHW) kolay bir şekilde eklemeyi ve hızlı bir şekilde kolaylaştırır.

Belgeler, API isteğindeki hangi alanların zorunlu ve hangilerinin isteğe bağlı olduğunu ve ayrıca bu alanlar için minimum ve maksimum uzunluk ve veri türünü açıkça tanımlamalıdır. Esasen, beklentileri belirlemek ve geliştiricileri tüketmenin önündeki engelleri kaldırmak için gerekli her şeyi içermelidir. Örneğin, sistemlerinde veritabanı şemaları oluşturan geliştiriciler, belgelerde parametreleri belirtmediği için daha sonra tablolardaki sütunların uzunluğunu ayarlamak zorunda kalmamalıdır.

API belgeleri, yalnızca geliştiricileri tüketen güvenilir bir referans olarak hizmet ederek değil, aynı zamanda API'nin kendisi için bir pazarlama aracı olarak hareket ederek benimsemeyi artırabilir. Genellikle, API belgeleriyle ilk karşılaşan kişi, ürün değerlendirmesinin ilk aşamalarında ona göz atan, işle ilgili bir paydaştır. Bu nedenle, yalnızca API'nin teknik unsurlarıyla ilgili ayrıntıları içermemeli, aynı zamanda API'nin mümkün kıldığı iş kullanım durumlarını da açıkça ifade etmelidir.

Piyasada kapsamlı API dokümantasyonu oluşturmaya yardımcı olabilecek bir dizi araç bulunmaktadır. Stripe's gibi yüksek kaliteli belge örneklerini incelemek de yararlıdır.

Hepsini Bir Araya Getirmek

Entegrasyonlar, birçok bileşeni olan geniş bir alanı temsil eder, ancak iyi bir API'nin temel ilkelerini anlamak, sağlam bir strateji geliştirmenin temelidir. API'ler, yalnızca sistem bağlayıcılarından çok daha fazlasıdır. Bunlar, geniş dijital ağların yapı taşları ve yeni gelir akışları açmanın ve kullanılmayan değeri serbest bırakmanın anahtarlarıdır. Bu nedenle, başarılı bir API stratejisi sadece ürün oluşturmakla ilgili değildir; bu potansiyel oluşturmakla ilgili. Bir API ürün yöneticisi, bir platform zihniyetini benimsemeli ve daha sonra API'lerini alabilecek, entegre edebilecek ve onunla çalışabilecek potansiyel ortaklar için benimsemeyi kolaylaştıracak faktörlere öncelik vermelidir.