Annemize ve Babamıza API ve API Yönetimini anlatmak
Bu yazıda, API Yönetiminin tüm bölümlerini bir restoran örneği üzerinden açıklayacağız. Bazen teknik konuları anlatırken, herkesin teknik bilgiye sahip olmadığını unutuyoruz. Bu yüzden bir adım geri gidip, bazı terimleri açıklamak için ortak bir dil bulmak önemlidir.
Peki, sen işin yapıyorsun?
Merhaba, benim adım Ertuğrul ve Apinizer adlı ürünün Kurucu Ortağı ve Geliştiricisiyim. En büyük zorluklarımdan biri, anneme/babama işimin ne olduğunu anlatmaktır. "Apinizer ürününü geliştiriyoruz, API'leri izliyor ve güvenli hale getiriyoruz!" gibi bir açıklama yapsam da, hmm güzelmiş diyor ama onu ikna etmiyor ya da yaptığım işi tam anlamasını sağlamıyor.
API ve API Yönetimi'nin ne olduğunu somut bir örnekle açıklamak gerekiyor. Restoran örneği, herkesin kolayca ilişki kurabileceği bir durumdur. Daha bir çok makalede belki görmüşsünüzdür.
Restoran Analojisi
- Müşteri (client): API Yönetiminde de aynı terimi kullanırız. Müşteri, talebi gönderen (Request) taraf olup, bu talepleri API aracılığıyla yapar.
- API Spesifikasyonu (menü): Restorandaki bir menü, API spesifikasyonu (WSDL ve Swagger/OpenAPI) gibidir. Menüde ne sipariş verebileceğinizi ve her öğenin açıklamasını bulabilirsiniz.
- Arka Plan Uygulaması (mutfak): Mutfak, siparişinizi hazırlayan yer gibidir. Mutfakta neler olup bittiğiyle ilgilenmenize gerek yoktur, önemli olan, siparişinizin istediğiniz gibi size ulaşmasıdır.
- Garson (API): Garson, müşteri ve mutfak arasındaki köprüdür. Siparişleri alır, mutfağa iletir ve sonuçları geri getirir (Response). API'ler de bu şekilde çalışır; talepleri alır, işleme koyar ve sonuçları geri iletir.
Uygulamanızın backend'i, restoranın mutfağının eşdeğeridir. Mutfak yemeğinizi hazırlayacak, tabağa koyacak ve güzelce sunacak ve biraz şansla, tam olarak sipariş ettiğiniz şeyi size verecektir. Bu, backend'in sorumluluğudur - size ihtiyacınız olan bilgiyi sağlamak, verilere gerekli işlemleri uygulamak ve belki de diğer kaynaklardan daha fazla bilgi istemek. Mutfak, yiyeceklerin işlenmesini ele alacaktır, örneğin dondurma, çözme, dilimleme, doğrama ve pişirme. Mutfak daha fazla malzeme talep etmek zorunda kalabilir. Tüm bu bilgi ve işlemler devam ederken, siz bir müşteri olarak bunları bilmenize gerek yoktur, hatta siparişinizi almak için bunları umursamanıza da gerek yoktur!
Müşteri yemek istiyor, Yemek Mutfakta Garsona ne gerek var?
Şimdi bir müşterimiz (Client), bir menümüz (API spesifikasyonu) ve bir mutfağımız (backend sistemi) var. Burada anahtar bir öğe eksik. Mutfak ne istediğinizi nasıl bilecek? Elbette, kendiniz mutfağa gidip doğrudan şefe sorabilirsiniz, ama o gergin ve akşam yemeği saatinde çok sayıda insanla konuşmak istemiyor. Ayrıca, insanların bir mutfağa girmesi pek hijyenik değil, 50 kadar müşterinin içeri girip siparişlerini bağırarak vermesi de pek pratik değil. Peki, yeni gelen 10 kişilik grubun siparişini alırken, odanın diğer ucundaki çocukları mümkün olduğunca ağlatmamaya çalışarak nasıl başa çıkacağız? Garson! İşte burada bizim Garsonumuz API Gateway oluyor
Garsonlar, API'lerin eşdeğeridir (Apinizer terminolojisinde API Proxy). Garson müşteriye gider, siparişini alır ve getirir. Ayrıca şunları da yaparlar:
- Aşırı tüketimi önlerler (bence iki yemek yeterli (Rate Limit))
- Menüde bir şey mevcut değilse uyarlamalar önerirler (füme somon bitti, ama füme alabalık mükemmel bir alternatif)
- Belirli durumlarda istek zamanlamasını ve varışını ayarlarlar (çocuklarınıza hemen biraz ekmek getireyim)
Yemekler hazır olduğunda, yemekler için uygun çatal bıçak takımını da sağlayacak ve genel olarak beklenen deneyimi sunacaklardır. Bir garson, istekleriniz (menüden sipariş) ile yanıtlar (masanıza getirilen yemekler) arasında API'lere çok benzer şekilde çalışır. API çağrıları yaptığınızda ve yanıtlar aldığınızda (Apinizer terminolojisinde politikalar olarak adlandırılır) bir dizi şey olur, örneğin:
- API çağrılarınızı güvence altına almaya yardımcı olur (üzgünüm, yeterince içtiniz)
- Veri dönüşümü uygular (Transformation) (çocuğunuz için yemeği keseyim)
- Backend'in işini yapabilmesi için daha fazla bilgi alır (Validation) (mutfağın bilmesi gereken herhangi bir alerjiniz var mı?)
- Bir yanıtı işler (çorba sipariş ettiniz, bir kaşık getireceğim)
API'ler bu durumları nasıl ele alacaklarını nasıl bilirler? Elbette, güvenlik, veri dönüşümü gibi ortak konular var, ancak belirli organizasyon politikasını nasıl ele alırız? Restoran örneğimize geri dönelim. Birçok ortak görev var (sipariş almak ve teslim etmek), ancak restoranın hem içeri girmek için bekleyen müşterilerin hem de siparişlerin kendilerinin kuyruklarını ele almak, belirli siparişlere öncelik vermek veya belki de genel olarak restoranda uygulanması gereken belirli temel kurallar gibi bazı özel politikaları olabilir.
API Yönetimi
API Yönetimi, restoran yöneticisinin yaptığı işlere benzer. Yöneticiler, garsonların (API'lerin) mutfak (arka plan uygulaması) ile müşteriler arasında nasıl çalışacağını belirler. Ayrıca, müşteri trafiğini analiz eder ve işlerin düzgün yürümesini sağlar. Örneğin, garsonların (API'lerin) ne gibi politikalara uyması gerektiğini yönetir ve belirler.
Sonuç
Restoran örneğiyle API Yönetimi şu şekilde özetlenebilir:
- Restoran: Sistem mimarisi.
- Müşteri: İstemci uygulama.
- Menü: API spesifikasyonu.
- Mutfak: Arka plan uygulaması.
- Garson: API.
- Restoran Yöneticisi: API Yönetim Sistemi.
Bu anlatımla işimi anneme açıklamaya çalışıyorum ve umarım sizin gibi teknoloji sektöründe çalışanlar için de faydalı olur. Teknik terimleri sadeleştirmek, işimizi daha anlaşılır hale getirir ve bu da işbirliğini güçlendirir.
Son Düşünceler
Takımımızda gün boyunca gateway'ler, proxy'ler, politikalar, API, Web Servis xml, json vs gibi terimlerle konuşuyoruz. Ancak, önemli olan kullanıcıların neyi başarmaya çalıştığını anlamaktır. "Neden?" sorusunu sormak, yüzeyin altındaki gerçek ihtiyaçları anlamamızı sağlar ve daha iyi çözümler üretmemize yardımcı olur. Eğer bir şeyi altı yaşındaki bir çocuğa bile açıklayabiliyorsanız, o konuda gerçekten bilgi sahibi olduğunuz anlamına gelir!
Annemiz ve ya Babamız umarım bizleri anlamıştır