Ana içeriğe atla
Restoran ve API analojisi 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 ve 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ş” diyorlar ama onları ikna etmiyor ya da yaptığım işi tam anlamaları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 ve birçok makalede karşınıza çıkmış olabilir.

​
Restoran Analojisi

  • Müşteri (client): API Yönetiminde de aynı terimi kullanırız. Müşteri, talebi gönderen (Request) taraftır ve bu talepleri API aracılığıyla yapar.
  • API Spesifikasyonu (menü): Restorandaki 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 yerdir. 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 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: 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; 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 mutfağa girmesi pek hijyenik değil; 50 müşterinin içeri girip siparişlerini bağırarak vermesi de pek pratik değil. 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 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 yapar:
  • Aşırı tüketimi önler (bence iki yemek yeterli — Rate Limit)
  • Menüde bir şey mevcut değilse uyarlamalar önerir (füme somon bitti, ama füme alabalık mükemmel bir alternatif)
  • Belirli durumlarda istek zamanlamasını ve varışını ayarlar (çocuklarınıza hemen biraz ekmek getireyim)
Yemekler hazır olduğunda 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:
  • 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ı?
  • Yanıtı işler (çorba sipariş ettiniz, bir kaşık getireceğim)
API’ler bu durumları nasıl ele alacaklarını nasıl bilir? 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 kuyruklarını ele almak, belirli siparişlere öncelik vermek veya restoranda uygulanması gereken belirli temel kurallar gibi ö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 ve babama 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 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 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 babamız umarım bizi anlamıştır.