Birleşik API: SaaS Uygulamaları Arasındaki Boşluğu Kapatmak

Yayınlanan: 2023-10-31

Birleşik uygulama programlama arayüzü (API), aynı anda birden fazla temel API ile iletişim kurabilen bir soyutlama katmanı görevi gören bir API'dir.

Sonuç olarak, birleştirilmiş API'deki her nesne ve uç nokta, temeldeki API'deki karşılık gelen bir nesne ve uç noktayla eşleşir. Bu, SaaS şirketlerinin birleşik API ile tek bir entegrasyon oluşturmasına ve temel API'lerin her biriyle anında entegrasyon göndermesine olanak tanır.

Bu makalede, birleşik API'leri, nasıl çalıştıklarını, zorluklarını ve özelliklerini ve SaaS şirketlerine nasıl fayda sağladıklarını derinlemesine inceleyeceğiz.

Birleştirilmiş API'ler hangi sorunu çözer?

SaaS alıcıları, satın aldıkları çözümlerden kusursuz yerel entegrasyonlar beklemeye başladı. Birlikte çalışabilirlik artık hoş bir şey değil, bir gereklilik. Ancak bu yerel entegrasyonları diğer araçlarla oluşturmak, sevkıyat ve bakım için önemli mühendislik kaynakları gerektirdiğinden, günümüzde her SaaS şirketinin karşılaştığı bir zorluktur.

Her entegrasyon için mühendislerin güvenli kimlik doğrulaması oluşturması, üçüncü taraf uygulamasının API belgelerini taraması, kullanım senaryosunu sunmak için gereken iş mantığını uygulaması ve son kullanıcı için sezgisel bir yapılandırma deneyimi oluşturması gerekir.

Ve bu, yeni özellik istekleri eklendikçe, üçüncü taraf API son değişiklikleri yayınladığında entegrasyonun sürdürülmesi ve güncellenmesiyle ilgili tüm çalışmaları ve geliştiricilerin müşterilerin entegrasyon sorunlarının hatalarını ayıklamasına yardımcı olmak için harcadığı zamanı hesaba katmıyor.

SaaS entegrasyonları bağlamında, son yıllarda her bir üçüncü taraf uygulamasının API belgelerini anlama zorluğunun üstesinden gelmenin bir yolu olarak birleştirilmiş API'ler ortaya çıktı.

Temelde bu, mühendislik ekiplerini her entegrasyon için bir kez olmak üzere her bir API için nüansları, şekilleri ve terminolojiyi sürekli olarak öğrenmekten veya yeniden gözden geçirmekten kurtarmalıdır.

Birleştirilmiş API'ler nasıl çalışır?

Somut bir örnekle birleşik bir API'nin nasıl çalıştığını inceleyelim.

Müşterilerinizin ürününüzün kendi CRM'leriyle entegre olmasını istediklerini düşünün; kullanıcı tabanınız genelinde bazı müşteriler Salesforce'u, diğerleri HubSpot'u, bazıları ise Dynamics veya Pipedrive'ı kullanıyor.

Birleşik bir CRM API'si, temeldeki CRM'lerin API'lerinin her birine yapılan referansları koruyarak bu CRM'lerin her birinin API'lerini soyutlayacaktır.

birleşik API'ler çalışma örneği

Kaynak: Paragon

Buradaki örnek, temeldeki her CRM'nin bir "kişiyi" temsil eden bir nesneye sahip olduğunu göstermektedir.

HubSpot buna İrtibat Kişisi diyor, Salesforce hem Müşteri Adayı hem de İrtibat nesnesi sağlıyor ve Pipedrive ilgili kişileri Potansiyel Müşteriler olarak adlandırıyor. Birleşik API içindeki "İletişim" nesnesine bir çağrı yapıldığında, birleşik API daha sonra belirtilen hizmetteki karşılık gelen nesneye referans verecektir.

Artık nesne düzeyindeki referanslar ilk katmandır, ancak bu nesnelerin içinde soyutlanmış özellikler veya alanlar da vardır. Yukarıdaki örnekte bu, ad, kimlik, şirket vb. için farklı terminolojiyi içerebilir.

Dolayısıyla, ekibiniz birden fazla CRM entegrasyonu oluşturuyorsa teorik olarak, temeldeki tüm CRM entegrasyonlarını aynı anda göndermenize olanak tanıyan birleşik bir CRM API'si ile tek bir entegrasyon oluşturabilirsiniz.

Kategoriye özgü birleştirilmiş API'ler

Farklı SaaS uygulamalarının benzersiz veri modelleri, yapıları ve özellikleri olduğundan tüm API'ler tek bir API'de birleştirilemez.

Bu nedenle satıcılar genellikle CRM, muhasebe veya reklamcılık gibi belirli bir SaaS sektörüne özel birden fazla birleşik API sunar; çünkü bu SaaS uygulamaları nispeten benzer veri yapılarına sahip olacak ve birçok ortak nesneyi veya özelliği paylaşacaktır.

Birleştirilmiş bir API tasarlarken, temeldeki API'ler ne kadar çok örtüşürse, birleştirilmiş API'nin sağlayabileceği kapsam da o kadar geniş olacağından, API sağlayıcısı birleştirilmiş API'ye hangi temel API'lerin dahil edileceğini dikkatli bir şekilde seçmelidir.

Bununla birlikte, birleştirilmiş API birbirine o kadar benzer olmayan uygulamaları içerecekse, temeldeki API'lerin paylaştığı tüm nesneleri ve özellikleri ortaya çıkaramayacağı için daha az kullanışlı olacaktır. Örneğin, bir CRM ve bir muhasebe uygulamasını içeren birleştirilmiş bir API çok kullanışlı olmayabilir çünkü bir "müşteri" nesnesinin dışında, uygulamaların geri kalan veri modelleri arasında çok fazla örtüşme olmayabilir.

Birleştirilmiş API'lerin avantajları nelerdir?

Birleşik API'ler, düzinelerce entegrasyonu göndermesi ve sürdürmesi gereken mühendislik ekiplerine birçok avantaj sağlar.

API soyutlamaları

Her hizmetin ayrı ayrı API'lerini öğrenmek ve bunlarla etkileşim kurmak yerine, mühendislik ekibinizin yalnızca bir kez (kategori başına) birleştirilmiş API ile nasıl arayüz kuracağını öğrenmesi gerekir.

Bu, yalnızca bu entegrasyonların daha kolay ve hızlı bir şekilde oluşturulmasını sağlamakla kalmaz, aynı zamanda entegrasyonların karmaşıklığının azaltılmasına da yardımcı olur.

Ek olarak, bakım söz konusu olduğunda, temel API'lerle iletişimin yönetilmesinden birleştirilmiş API satıcısı sorumludur; bu, ekibinizin temel API'lerden birinde yapılan değişikliklerin bozulması konusunda endişelenmesine gerek olmadığı anlamına gelir. Sonuçta, birleştirilmiş API satıcısı, entegrasyonun çalışmaya devam etmesini sağlamak için soyutlamalarını güncellemekten sorumlu olacaktır.

Yönetilen kimlik doğrulama

Birleşik API sağlayıcıları genellikle, ister API anahtarları ister OAuth aracılığıyla olsun, temel API'lerle kimlik doğrulamanın karmaşıklığını ortadan kaldıran, yönetilen bir kimlik doğrulama hizmeti sunar.

Birden fazla API ile doğrudan entegre olduğunuzda, kullanıcı kimlik bilgilerinin yönetimi ve güvenli belirteç yenileme politikalarının sağlanması da dahil olmak üzere her biri için kimlik doğrulama sürecini yönetmeniz gerekir.

Her uygulamanın kimlik doğrulamayı nasıl işlediğine ilişkin pek çok nüans olduğu göz önüne alındığında, özellikle çok sayıda API ile çalışıyorsanız bu, hantal ve hataya açık bir görev olabilir.

Kerestecilik

Doğası gereği, birleştirilmiş API, temel API'lerine proxy isteklerinde bulunur. Bu şekilde üçüncü taraf uygulamalara yapılan taleplere ilişkin verileri toplayacak ve analiz edeceklerdir. Sonuç olarak, bir istek başarısız olduğunda, birleştirilmiş API sağlayıcısı bu olayı günlüğe kaydedebilir ve temel API tarafından döndürülen hata mesajıyla ilgili ayrıntıları sağlayabilir.

Bu günlük kaydı işlevi, entegrasyonlarında meydana gelebilecek sorunları hızlı bir şekilde tanımlamalarına olanak tanıdığından ekibiniz için yararlı olabilir. Birden fazla üçüncü taraf API'den gelen günlükleri incelemek yerine, günlük kaydını ve hata raporlamayı merkezileştirmek için birleştirilmiş API sağlayıcısına güvenebilirler.

Hata ayıklama hatalarıyla, birleştirilmiş API sağlayıcıları genellikle temel API'lerin kendisinden daha ayrıntılı hata mesajları sağlayabilir. Bunun nedeni, hata yanıtını analiz edebilmeleri ve sorunun temel nedeni hakkında daha fazla bağlam sunabilmeleridir; bu da hataları teşhis etmek için harcanan süreyi büyük ölçüde azaltabilir ve olay yanıt sürelerini hızlandırabilir.

Önceden oluşturulmuş kullanıcı arayüzü

Çoğu birleştirilmiş API sağlayıcısı, müşterilerinizin bir entegrasyonda kimlik doğrulaması yapması için önceden oluşturulmuş bir arayüz sağlayarak sizi yapılandırma deneyimini kendiniz oluşturmaktan kurtarır.

Bu, ekibinizin her bir entegrasyon için kullanıcı deneyimini tasarlama yükünü hafifletir ve bu da, birleştirilmiş API üzerinde oluşturabileceğiniz düzinelerce potansiyel entegrasyon dikkate alındığında zaman tasarrufu açısından birleşebilir.

Birleşik API'leri kullanmanın zorlukları nelerdir?

Birleştirilmiş API'ler yukarıda paylaşılan faydaları sağlarken, şirketlerin daha fazla farkına varmaya başladığı bazı yapısal sınırlamalar nedeniyle bunlar sekteye uğruyor.

Kullanım durumu sınırlamaları

Birleştirilmiş API'lerin yalnızca temel API'ler arasındaki "paylaşılan" nesneleri ve uç noktaları soyutlayabildiği göz önüne alındığında, yalnızca tüm entegrasyonlarda nispeten basit ve genelleştirilebilir özellikler oluşturabilirsiniz. Bu, herhangi bir birleşik API çözümünün açık ara en büyük sınırlamasıdır.

Ek olarak, birleştirilmiş bir API içerisinde ne kadar çok uygulama desteklenirse, o kadar sınırlı hale gelir.

birleştirilmiş API kapsamının özeti

Kaynak: Paragon

Bu sınırlamalara ilişkin bazı örnekleri inceleyelim.

Uzlaştırılamaz özellikler

Entegrasyonlardan birine özgü işlevsellik veya özellikleri içeren bir entegrasyon özelliği oluşturmanız gerekiyorsa, bu birleştirilmiş bir API ile mümkün olmayacaktır.

Örneğin, "birleşik geri bildirim API'si" aracılığıyla birden fazla müşteri geri bildirim aracıyla entegrasyon yapmak istediğinizi varsayalım. Bir araç, geri bildirim puanları 1-10 arasında olan niceliksel bir modelden yararlanırken diğeri yalnızca "negatif, tarafsız, olumlu" ve "notlar"ı topluyorsa, uzlaşamayacağınız için birleşik bir API'nin bu kullanım örneklerini desteklemesinin hiçbir yolu yoktur. bunları tek bir referansta toplayın.

Eksik alanlar

Entegrasyon yoluyla güncellemeniz gereken özellik, desteklenen entegrasyonların yalnızca belirli bir alt kümesi için mevcutsa bu özellik, birleştirilmiş API içinde kullanıma sunulmayacaktır.

Örneğin, temeldeki üçüncü taraf uygulamalardan birkaçı alan olarak ZIP koduna sahip olsa bile, alan olarak biri olmadığı sürece, ZIP koduna birleştirilmiş API aracılığıyla bir özellik olarak erişilemez.

Özel nesneler ve alanlar

Doğası gereği, birleştirilmiş API'ler, temeldeki her API için önceden tanımlanmış bir dizi referans sağlar. Ancak karışıma özel nesneler veya alanlar eklerseniz, birleştirilmiş API sağlayıcısı bu nesnelerin veya alanların ne olduğunu tahmin edemez. Bu nedenle özel nesneler veya alanlar içeren entegrasyonları destekleyemezler.

Müşterileriniz, üçüncü taraf uygulamalardaki özel nesnelerin kullanımını desteklemek için sağladığınız entegrasyonlara ihtiyaç duyuyorsa, bu büyük bir engelleyici olabilir.

Oran sınırları

Birleştirilmiş bir API aracılığıyla birden fazla API ile aynı anda entegrasyon yaparken, her bir API'nin hız sınırlarının farkında olmanız ve entegrasyon mantığınızın herhangi bir API'nin sınırlarını aşmadığından emin olmanız gerekir.

Bu, oluşturduğunuz mantığın, hız sınırları için en düşük eşiğe sahip API'nin hız sınırlarına uyması gerektiği anlamına gelir. Basitçe söylemek gerekirse, en düşük hız sınırına sahip API, entegrasyonunuz için sınırlayıcı faktör olacaktır. Söz konusu API'nin uç noktalarına çok fazla istekte bulunmaya çalışırsanız, birleştirilmiş API'deki diğer API'ler teknik olarak aynı birimi desteklese bile istekleriniz başarısız olmaya başlayacaktır.

Bu entegrasyonlar için belirli uç noktalara toplu istekte bulunurken hız sınırı hatalarına çarpmamak için, her bir API'ye gönderdiğiniz isteklerin hızını kontrol etmek amacıyla toplu işlem veya kısıtlamayı kullanmanız gerekir.

Dolayısıyla, daha düşük hız sınırları üzerinde çalışmak hâlâ mümkün olsa da, temeldeki entegrasyonlardan herhangi birinin sınırlamalarına uyum sağlamak için kod tabanınızda ek karmaşıklık oluşturduğunuzu göreceksiniz.

Güvenlik

Birleşik API'ler, her entegrasyon için ayrı kapsamlar seçmenize izin vermek yerine genellikle API'lerini kullanabilmeniz için bir üçüncü taraf hizmetinin tüm kapsamlarına erişim yetkisi vermenizi gerektirir.

Bu, bir kullanıcının entegrasyonunuzu kullanması için kimlik doğrulaması yaptığınızda, kullanıcının yalnızca entegrasyon için gereken verilere değil, söz konusu üçüncü taraf hizmetiyle ilişkili tüm verilere erişim izni vermek zorunda kalacağı anlamına gelir.

Örnek olarak, birleşik bir API aracılığıyla bir CRM entegrasyonu oluşturuyorsunuz ve CRM'nin satış, pazarlama ve müşteri destek verilerine erişimi var. Bir kullanıcı entegrasyonunuzu kullanmak için hesabının kimliğini doğruladığında, uygulamanızın tüm ihtiyaçları satış verileri olsa bile size üç veri kümesinin tümüne erişim izni verilir.

Bu, müşterilerinizin güvenlik endişelerini artırabilir. Bu endişeleri azaltmak için, hangi verilere erişim talep ettiğiniz konusunda kullanıcılarınıza karşı şeffaf olmanız ve bu verilere neden ihtiyaç duyduğunuzu net bir şekilde açıklamanız önemlidir.

Ayrıca satıcının genellikle birleştirilmiş API'ler barındırdığı göz önüne alındığında, kullanıcılarınızın verilerini yetkisiz erişime veya ihlallere karşı korumak için güçlü güvenlik önlemlerine sahip olduğundan emin olmak konusunda satıcıya güveniyorsunuz.

Görüşlü veri modeli

Satıcının farklı temel API'leri ve referans uç noktalarını nasıl uzlaştıracağı kendi görüşüne bağlıdır. Çoğu kullanım durumu için bu bir sorun olmasa da, katılmadığınız veya beklenen davranışa uymayan bir soyutlama sunabilecekleri zamanlar olacaktır.

Yol haritası kısıtlamaları

Birçok kategoride her üçüncü taraf API'nin bire bir soyutlamalarını sağlayan yerleşik entegrasyon platformlarıyla karşılaştırıldığında, birleştirilmiş API satıcıları, birleştirilmiş API'ler oluşturdukları kategorilerle sınırlıdır.

Zaman içinde yeni birleştirilmiş API'ler oluşturabilecekler ve oluşturacak olsalar da, şu anda desteklenmeyen bir kategoriyle entegrasyon talep ederseniz, bu entegrasyonun kullanıma sunulması için muhtemelen yıllarca beklemeniz gerekecek.

Bunun tek istisnası, satıcının talep edilen entegrasyonun uyduğu kategori için birleşik bir API oluşturması olabilir. Yine de SaaS ekosisteminin genişliği ve destekleyebilecekleri potansiyel kategoriler göz önüne alındığında, durum nadiren böyle olacaktır.

Geçici Çözümler: Birleştirilmiş API'lerle birlikte gelen, birleştirilmiş API'lerin gerçek değeri hakkında iki kez düşünmenize neden olabilecek pek çok sınırlama vardır; Bugün var olan satıcılar geçici çözümler sağlamak için benzersiz çözümler bulmaya çalışıyorlar.

Örneğin, belirli sağlayıcılar temeldeki API'ye "geçiş" istekleri yapma olanağı yarattı. Ancak günümüzün uygulaması hâlâ oldukça sınırlayıcıdır ve ortalamanın altında bir geliştirici deneyimi yaratmaktadır.

Birleşik API'yi ne zaman kullanmalısınız?

Birleştirilmiş API'nin ekibiniz için doğru çözüm olup olmadığına karar vermek söz konusu olduğunda basit karar verme kriterlerini takip edebilirsiniz.

Kriterler

Aşağıdakilerin tümü doğruysa, kesinlikle değerlendirmeye değer.

  • Entegrasyon yol haritanız, birleştirilmiş API sağlayıcısı tarafından desteklenen kategorilerle sınırlıdır .
  • Oluşturmanız gereken her entegrasyon kullanım durumu, kategorideki her uygulamaya genelleştirilebilir .
  • Ölçeklendikçe müşterilerinizi desteklemek için gereken talep hacmini karşılayabilecek bir altyapı oluşturmak için özel kaynaklara yatırım yapabilirsiniz .
  • Entegrasyonun nasıl davrandığını ve nerede hata yaptığını görmek için destek ekibinize ihtiyacınız yoktur ve mühendislik ekibinin hata ayıklaması için devreye girmesini sağlayabilirsiniz.

Yukarıdaki dört noktaya güvenle evet diyemiyorsanız, birleşik bir API kullanmaya mahkum olmak istemeyebilirsiniz.

Bunun yerine, bir Gömülü entegrasyon platformu, entegrasyon geliştirme sürecini kolaylaştırmaya yardımcı olacak daha kapsamlı araçlar sağlarken çok daha derin entegrasyonlar oluşturmanıza olanak tanıdığından daha iyi bir çözüm olabilir.

B2B SaaS entegrasyon zorluğu

SaaS ürününüzün yerel entegrasyon yol haritasını ölçeklendirmenize yardımcı olacak bir çözüme karar vermek kolay değildir. Yalnızca bugünkü kullanım senaryolarınıza değil, aynı zamanda müşterilerinizin gelecekte talep edebileceği tüm olası kullanım senaryolarına da hitap edebildiğinden emin olmanız gerekir.

Müşterilerinizin ihtiyaç duyduğu kullanım senaryolarının belirli bir kategorideki her entegrasyonda aynı olması koşuluyla, birleştirilmiş API'ler düzinelerce entegrasyonu minimum çabayla göndermek için mükemmel bir çözüm olabilir.

Pek çok yeni oyuncunun yer aldığı gelişmekte olan bir pazardır ve B2B SaaS entegrasyon sorununu çözmek için kesinlikle ilginç bir yaklaşımdır.

Kapsamlı kılavuzdan API'ler, bunların yararları, zorlukları ve kullanım örnekleri hakkında her şeyi öğrenin.