Anahtar Kavramlar (Key Concepts)

API Yönetimi

(API Management)

API yönetimi, API'leri güvenli 775px ve ölçeklenebilir bir ortamda denetleme, biçimlendirme, hizmete alma ve bunlarla ilgili olarak yapılacak işlemler bütünüdür. API yönetiminin amacı, API paydaşlarının gereksinimlerini kaliteli bir şekilde ve düşük maliyetle karşılamaktır.

API yönetimi ihtiyaçları kuruluştan kuruluşa farklılık gösterebilir, ancak API güvenlik, izleme ve sürüm kontrolü gibi temel işlevler genelde ortaktır.

Apinizer bir API Yönetim Platformudur.

API Yaşam Döngüsü

(API Lifecycle)

Bir API'nin fikrinin oluşturulması, gereksinimlerinin belirlenmesi, tasarlanıp geliştirilmesi, test edilmesi, hizmete alınıp güvenlik isterlerinin yerine getirilmesi, desteğinin verilmesi, çalışma durumunun izlenmesi, performansının iyileştirilmesi, ücretlendirilip satılması, kullanılması, geri dönüşlerin yapılması, güncellenmesi, versiyonlanması ya da bir versiyonun kullanımdan kaldırılması gibi adımların tamamı API Yaşam Döngüsünü oluşturur. 

Kuruluşlar kendi ihtiyaçları çerçevesinde yaşam döngüsünün adımlarını nasıl işleteceklerini özelleştirebilirler.

Apinizer, API Yaşam Döngüsünü destekler ve API Paydaşlarının kendi rolleri çerçevesinde iş birliği içinde çalışabilecekleri bir platform sunar. Özet bilgi için tıklayınız.

API Paydaşı

(API Stakeholder)

API Yaşam Döngüsü adımlarının bir ya da daha fazlasında sürece dahil olan herkes bir API Paydaşıdır. 

API Ürün Yöneticisi (API Product Manager): API Ürününün (API Product) sağlaması gereken özellikleri, kalite gereksinimlerini, yeteneklerini, müşterinin hangi ihtiyaçlarını karşılayabileceğini, maliyetini ve satış fiyatını, nasıl pazarlanacağını... düşünen, belirleyen, yöneten roldür. 

API Gereksinim Çözümleyici (API Requirements Analyzer): API isterlerini belirleyip dokümante eder.  

API Tasarımcısı (API Designer): API tarafından sunulacak olan uç noktaların (endpoints) alacağı ya da döndüreceği mesajlara ilişkin parametreler, başlıklar, mesaj yapısı gibi detayları tasarlar, bunları bir API Specification olarak API Geliştiricilerin anlayıp kullanabileceği formatta yayınlar.

API Geliştirici (API Developer):

• Fiilen yazılım geliştirme işi olarak API kodunu yazar.
• API Proxy'leri oluşturup konfigürasyonunu yapar.
• Entegrasyonlar gerçekleştirecek konfigürasyonları yapar.

API Test Uzmanı (API Tester): API Proxy'leri işlevsel doğruluk, performans, güvenlik gibi kriterler ile test eder.

API Kalite Uzmanı (API QA Specialist): API Proxy'leri ya da API Ürünlerini istemci ihtiyaçlarını karşılama düzeyi, doğru çalışma ve performans gibi farklı kriterler ile sürekli izler, gerekli iyileştirmeleri tespit edip API Geliştiricilere geri bildirim sağlar.

API Destek Uzmanı (API Support Specialist): API Ürünleri ile ilgili olarak gelen API Tüketici şikayet, talep ya da bildirimlerini değerlendirip sorunları giderir, API Geliştiricileri ya da API Ürün Yöneticisine girdi oluşturur. 

API Portal Yöneticisi (API Portal Manager): API Ürünlerinin API Tüketicilere ulaştırıldığı API Portal uygulamasını yönetir.

API Analizi Uzmanı (API Analytics Specialist): API loglarını yönetir, inceler, raporlar ve API'lerin genel performans, hata oluşturma sıklıkları, en sorunlu ya da en yoğun kullanılan API'ler gibi metrikleri toplayarak gerekli iyileştirme ve düzenlemelerin yapılabilmesi için API Ürün Yöneticisi ya da API Geliştiricilerine girdi sağlar.

API Güvenlik Yöneticisi (API Security Manager): İstemci kimliklerinin yönetilmesi, hassas verilerin nasıl ve ne kadar loglanacağının belirlenmesi, şifre gerektiren bağlantı tanımlarının yapılması gibi işleri gerçekleştirir. 

API Tüketici (API Consumer): API Proxy'lere istemci olur ya da API Ürünlerini satın alıp kullanır. 

Apinizer, dinamik rol yönetimi yetenekleri ile ilgili paydaşların oluşturulması ve diğer paydaşlarla işbirliği içinde çalışabilmesi için gerekli yönetimsel araçlar ve altyapıyı sağlar.

API Gateway üzerinde oluşturularak orijinal API'yi taklit eden vekil varlıktır. Böylece istemciden gelen mesajlar orijinal API (Backend API)'ye iletilmeden önce ya da orijinal API'nin yanıtı istemciye gönderilmeden önce çeşitli işlemler yapmak mümkün olur. 

API Proxy orijinal API için bir sanallaştırma noktası sağlar ve böylece bir Politika Uygulama Noktası (Policy Enforcement Point - PEP) ortaya çıkar.  

API Proxy,

• API Gateway üzerinde çalışan paydaşlar (API Tasarımcı, API Geliştirici, API Testçi vb) için API Proxy,
• API Tüketiciler (istemciler) açısından API,
• API Ürün Yöneticileri tarafından, dokümantasyon, Sandbox ortamı erişimi ve ücretlendirme planları oluşturularak Yayına Alındığında ise API Ürünü (API Product)

olarak görülür. 

Apinizer, API Proxy oluşturmak için dosya içe aktarma, URL adresinden API özelliklerini tanıma, manuel olarak uç noktaları ekleme, klonlama ya da hazır tanımlardan seçilenle ilerleme gibi, kullanıcıların farklı ihtiyaçlarını kolayca karşılayabilecekleri araçlar sunar.

Önüne koyulan API Proxy ile istemcinin doğrudan erişimine kapatılan, bunun yerine istekleri API Proxy'den alıp yanıtlarını API Proxy'e döndüren orijinal API'nin, API Gateway kullanılan senaryoda aldığı isimdir.

Apinizer, WSDL, Swagger ve OpenAPI 3.0 standartlarını destekler, bu standartlardaki API'lerin tanım dosyalarını kullanarak kolayca API Proxy oluşturulmasına olanak verir. Tanım dosyası olmayan API/Web Servislerin kolayca tanımlanmasına ya da Reverse Proxy özelliği ile herhangi bir tanım dosyası oluşturmadan API Proxy açmaya izin verir.

API Tanım Dosyaları

(API Definition Files - API Spec Files)

Bir API'nin yapısını, fonksiyonlarını, başlık, parametre ve döndüreceği değerleri tanımlayan, yazılımsal olarak yorumlanmak üzere oluşturulmuş tanım dosyalarıdır.

Apinizer, WSDL, Swagger ve OpenApi 3.0 standartlarında tanım dosyalarını kullanarak API Proxy oluşturulmasını destekler. Oluşturulan API Proxy'lerin tanım dosyalarını farklı formatlarda dışarı açabilir. Ayrıca API Spec Creator aracı ile böyle bir tanım dosyasını oluşturma işini form tabanlı arayüzler üzerinden gerçekleştirme ve diğer standart formatlara dönüştürme imkanı verir.

Bir uygulamanın ya da entegrasyon işinin yapılması için bir API geliştirilmesi zaman alabilir. Öte yandan, bu API'nin istemcisi tarafındaki geliştirme işlerinin API'nin hazır olmasını beklemesine gerek yoktur. Eğer API'nin hangi parametreleri alıp nasıl veri döneceği belli ise, örnek değerler döndürecek bir API, istemcilerin kendi geliştirmelerini yaparak örneğin kullanıcı arayüzlerini kodlamak amacıyla kullanmaları için yeterlidir.

Bu ihtiyacı karşılayacak şekilde önceden tanımlanmış ya da çalışma zamanında ürettiği rastgele değerleri döndüren API'lere Mock API adı verilir. 

Apinizer, kullanıcıların hızla ve kolayca Mock API oluşturabilecekleri bir modül sunar. Kullanıcılar isterse bu Mock API üzerinde koşullar tanımlayıp bu koşullara göre farklı yanıtlar döndürülmesini sağlayabilir ya da Politikalar uygulayabilirler. 

Bazen istemcilere geliştirme ya da geliştirdiklerini sınama sırasında, işlevsel olmasa da sadece çağırabilmenin yeterli olduğu bir API, bazen de gönderdiği isteği kendisine yanıt olarak döndürecek bir API gerekir. Mirror API, kendisine gönderilen isteği yanıt olarak geri gönderen API'ye verilen isimdir. Echo API olarak da anlandırılır.

Apinizer ile Mirror API oluşturulabilir ve Politikalar ile davranışı özelleştirilebilir.

API Ürünü

(API Product)

API'ler genel olarak veri paylaşımı, entegrasyon ya da uygulama geliştirme amaçları ile kullanılmaktadır. Bununla birlikte özellikle son yıllarda uygulamalar gibi, API'lerin kendileri de belirlenen ücretler karşılığında satılmaya başlamıştır. Bu çerçevede artık API'ler bir ürün olarak üretilmekte, bir ürünün yaşam döngüsünü takip etmektedir. İşte böyle üretilen ve pazarlanan API'ler API Ürünü adını alır ve genellikle bir API Portal ya da API Pazar Yeri (API Market Place) üzerinden satışa çıkarılırlar.

Apinizer, API Gateway üzerindeki API Proxy'lerin tek adımda API Product olarak portalde yayınlanmasını, dokümantasyonun ve kullanım istatistiklerinin erişilebilir olmasını sağlayabilir.

API Tüketicilerinin, bir şirket veya kurumun sunduğu API'ler ile ilgili dokümantasyona ulaşabileceği, bunları test edebileceği, belirli kısıtlamalar dahilinde kullanabileceği, bunlar hakkında soru sorup cevaplayabileceği ve ücretli veya ücretsiz olarak müşteri olabileceği yazılımlardır.

Apinizer, birisi API Gateway ile entegre olan, diğeri istenirse başka bir API Gateway yazılımının önüne konumlandırılabilen ya da API Gateway kullanılmadan direkt olarak API'lerin yayınlanabileceği şekilde çalışabilen bağımsız bir API Portal olmak üzere iki farklı API Portal ürünü sunar.

API Pazar Yeri

(API Market Place)

Politika

(Policy) 

API Proxy üzerinde yapılan konfigürasyonlar ile güvenlik, mesajları filtreleme, doğrulama, dönüştürme ya da zenginleştirme, kısmen iş mantığı uygulama, hata yönetimi vb. işlemler yönetilir. Bu konfigürasyonlara genelde Politika denmekle birlikte, hangi politikaların var olduğu ve nasıl yapılacağı API Gateway yazılımlarına göre değişir.

Apinizer, birçok politika sunar ve API Geliştiricilere istek/yanıt mesajlarının içeriği üzerinde tam kontrol sağlar. Üstelik bunu bütün konfigürasyonların form-tabanlı olarak yapılabileceği arayüzler üzerinden yapma olanağı vererek kullanıcıları karmaşık konfigürasyon dosyaları ile çalışmaktan kurtarır.

API Proxy Şablonu

(API Proxy Template)

Çoğu zaman, aynı proje kapsamındaki API Proxy'lerin aynı ayarlar ile çalışması, ortak ayarların geliştiricilerin inisiyatifine bırakılmaması gerekir. Böylece örneğin bir uygulamanın parçası olan bütün API Proxy'ler, aynı güvenlik ya da hata mesajı ayarları ile çalışabilir.

Apinizer, API Proxy Şablonu ile önceden tanımlanmış bir grup ayarın her yeni API Proxy için otomatik olarak uygulanmasını mümkün kılar. 

Yerel Politika ve Genel Politika

(Local Policy and Global Policy)

Yerel Politika, bir API Proxy geliştirilirken oluşturulan ve yalnızca o API Proxy tarafından kullanılabilen Politikalar için kullanılan isimdir.

Genel Politikalar ise API Proxy'lerden bağımsız olarak oluşturulabilen ve birden çok API Proxy tarafından referans verilerek kullanılabilen Politikalardır. Bir Genel Politikada yapılan değişiklik, o Politikayı kullanan bütün API Proxy'leri etkiler.

Apinizer, hem Yerel hem Genel Politikaların oluşturulup kullanılmasına, dışa/içe aktarım yoluyla taşınabilmesine ya da Yerel Politikanın Genel Politikaya dönüştürülmesine izin verir. 

Politika Uygulama Noktası

(Policy Enforcement Point - PEP)

Tek Giriş Noktası

(Single Point of Entry)

API Gateway, arkasındaki API'ler için tek bir giriş noktası oluşturur. Böylece bütün denetim işlemleri tek noktadan yapılabilir.

Tek Giriş Noktası olan sistemlere ilişkin ilk akla gelen soru; "Bir Tek Giriş Noktası varsa Tek Hata Noktası da oluşmaz mı?" sorusudur.

Apinizer API Gateway ile bir Tek Giriş Noktası oluşturur, ancak Tek Hata Noktası oluşturmaz.

Tek Hata Noktası

(Single Point of Failure - SPoF)

Tek Giriş Noktası olan bir sistemde, bu nokta ile ilgili bir sorun, sistemin tamamının kullanılamaz hale gelmesine neden olabileceğinden, Tek Hata Noktası olarak adlandırılır.

Apinizer, Kubernetes üzerinde çalıştığı ve yatayda ölçeklendiği için Tek Hata Noktası oluşturmaz. 

Koşul

(Condition)

Apinizer, tanımlanan Politikaların yalnızca belirli koşullarda işletilmesi ya da örneğin bir Mock API'nin belirtilen koşullara uygun yanıtı döndürmesi gibi yeteneklere sahiptir. Bu bağlamda Koşul, bir mesajın içindeki herhangi bir veri parçasının içerik, yapı ya da tipi gibi özellikleri kullanılarak oluşturulan ve API Gateway tarafından kontrol edilerek gereği yapılan bir karar verme tanımıdır.

Koşul örnekleri:

"istek mesajının başlık bölümünde username adlı bir başlık varsa ve değeri ABC ise"

"istek mesajının employeeId adlı parametresinin değeri 1 ise ya da mesajın gövdesinin şu bölümündeki değer 123 ise"

Apinizer, bir Koşulu kontrol etmek ya da bir mesajın herhangi bir bölümündeki bir veriye ulaşmak için Değişkenleri kullanır. Kullanıcılar kendi Değişken tanımlarını yapabilirler.

Değişken örnekleri:

username adlı başlık

employeeId adlı parametre

Apinizer bazı ortak kullanılan Değişken tanımlarını varsayılan olarak hazır sunar.  

API Revizyonu ve API Versiyonu

(API Revision and API Version)

Geliştirme işi devam eden bir süreçtir. API Tüketicilerin geri bildirimlerine göre API Proxy üzerinde güncellemeler yapılması, yeni Politikalar eklenmesi ya da bir takım ayarların değiştirilmesi olağan bir durumdur. Ancak bir API Proxy üzerinde devam eden geliştirme işlerinin aktif olarak API'yi kullanmakta olan API Tüketicileri etkilememesi, yeni yapılanlarda herhangi bir hata belirlenmesi gibi bir durumda hızla eski ayarlara dönülmesi gerekir.

Bunun için API Revizyonları oluşturulur ve yeni revizyon olgunluğa eriştikten sonra kullanıcılara açılır. Bir revizyon, başlangıçta bir önceki revizyonun bütün ayarlarını içermeli, yenilerinin yapılmasına izin vermelidir.

Revizyon ile Versiyon karıştırılmamalıdır. Genellikle versiyon denildiğinde erişim adresi değişen, eski API'nin bir takım metodlarını ortadan kaldırırken yeni metodlar ekleyen yeni bir API ifade edilir. Bu durumda örneğin https://abc.com/api/v1/blabla adresinde çalışmakta olan API'nin yeni versiyonunun adresi https://abc.com/api/v2/blabla şeklinde olur. Bu senaryoda API Tüketicilerin kendi istemcilerini yeni versiyonun adresi ile ve yeni eklenen, silinen ya da güncellenen metodlara göre güncellemesi gerekir. Böyle bir geçiş zaman alıcı ve yorucudur. 

Revizyon oluşturmada ise API'nin adresi değişmez, metodlarda bu kadar büyük değişiklikler olması beklenmez. Bunun yerine yeni Politikalar eklenmesi gibi API Tüketicilere yansımayan, API Proxy'nin çalışma şeklini etkileyen değişiklikler yapılır. 

Apinizer, herhangi bir API Proxy'nin yeni revizyonlarının kolayca oluşturulmasına ve aynı anda birden çok revizyonun farklı Ortamlara (Development ve Production gibi) yüklenmesine izin verir. Herhangi bir revizyondan başka herhangi bir revizyona anında geçişi (how-swap) destekler. Erişim adresi değişmeyeceği için bu işlemler API Tüketiciler tarafından farkedilmez.

Apinizer, bir API Proxy'nin klonlanarak yeni bir adresten açılmasına, böylece versiyonlamaya da izin verir. Erişim adresleri farklı olduğu için aynı API'nin iki farklı versiyonu aynı anda çalıştırılabilir.  

Ortam

(Environment)

Apinizer, istenildiği kadar Ortam oluşturulmasına olanak verir ve bu Ortamlar için farklı kaynaklar ayrılabilir. Böylece Development & Test, Sandbox ve Production ortamlarını birbirlerinden ayırmak mümkün olduğu gibi, farklı istemci gruplarına farklı kaynaklar sağlayarak değişen performans gereksinimleri karşılanabilir. 

Geçit Adresi

(Relative Path)

Yükleme

(Deployment)

Bir API Proxy'nin erişilebilir hale gelmesi için önce API Gateway üzerinde bir Ortam'a yüklenmesi gerekir. Yükleme ile birlikte, API Proxy için yapılan ayarlar ve eklenen Politikalar aktif hale gelir. Yüklenmiş bir API Proxy üzerinde yapılan güncellemeler, API Proxy yeniden yüklenene (redeploy) kadar geçerli olmaz. API Proxy'nin erişime kapatılması için ise kaldırılması (undeploy) gerekir.

Apinizer, yükleme ve yeniden yükleme işlemlerini anında ve istemcilerin farkedemeyeceği şekilde yapar, trafik durdurulmaz.

Yayına Alma

(Publishing)

Kurum/firma içi kullanım senaryolarında bir API Proxy'nin yüklenerek istemcilerin kullanımına açılması yeterlidir. Ancak API Ürünü geliştiren firmaların ürünlerini hizmete sunması söz konusu olduğu zaman, bu API Proxy'lerin API Portal üzerinden dokümantasyon, ücretsiz Sandbox erişimi ve ücretlendirme planları ile birlikte kullanılma açılarak API Ürünü haline getirilmesi gerekir. Bu işlem, Yükleme işleminden farklı, daha sonraki bir adımdır ve Yayına Alma olarak adlandırılır. Başka bir bakışla, "Yüklenmiş" bir API Proxy, "Yayına Alındığı" zaman API Ürünü olarak adlandırılır.

Apinizer, API Proxy'leri kendi ürün yelpazesindeki API Portal ürünleri üzerinden API Ürünü olarak yayına alma yeteneğine sahiptir.

Loglama/Günlük Kayıtlarının Tutulması

(Logging)

Bilişim sistemlerinde, yapılan işlemlere ilişkin çeşitli log kayıtları saklanır.

• Yazılım kodlarının ürettiği, hangi kod kesiminde nasıl bir iş yapıldığının log kayıtları: Genelde TRACE, DEBUG, INFO, WARNING, ERROR, SEVERE gibi seviyeleri yazılım kodu dışından ayarlanarak, sistemdeki bir hatanın belirlenmesi amacıyla kullanılırlar. Apinizer, yönetim arayüzleri üzerinden yazılım loglarının seviyesinin değiştirilmesine ve log kayıtlarının sorgulanmasına izin verir. Böylece sistemde olabilecek herhangi bir hata için sunucu bağlantısı yapmak, log dosyalarını aramak, açmak, indirmek gibi görece zor işlere gerek kalmaz.
• Yapılan işlemlere ilişkin, kimin ne zaman ne yaptığına, neyi nasıl değiştirdiğine ilişkin kayıtlar: Bunlara Denetim kayıtları (Audit Records), işleme de Denetim Kaydı Tutma (Auditing) adı verilir. Apinizer, denetim kayıtlarını tutar ve yönetim arayüzleri üzerinden sorgulama imkanı verir.
• İşe özel kayıtlar: Bilişim sisteminin yaptığı işe özel kayıtlardır. Örneğin ağ yönetimi ile ilgili bir sistem, ağ üzerinden akan paketlere ilişkin kayıtlar saklarken, bir veri tabanı yönetim sistemi de işlettiği sorgulara ilişkin kayıtlar saklayacaktır. Apinizer bu çerçevede birkaç farklı kategoride log saklama ve yönetme olanağı sunar:
  • Bütün istek/yanıt mesajlarını saklayabilir ve neyin nasıl saklanacağını belirleme imkanı verir (bkz. Loglama Ayarları).
  • Mesaj trafiğine ilişkin performans metriklerini saklar ve bunları API Analizi, Anomali Tespiti, adım adım izleme gibi amaçlarla kullanma imkanı verir.
  • Hassas verilerin nasıl loglanacağına ilişkin ayarları yönetme (bkz. Gizlilik Yönetimi) imkanı verir.
  • İstemcilere verilen erişim anahtarlarını (kime ne zaman hangi anahtarın verildiğini) izleme imkanı verir.

Loglama Ayarları

(Log Settings)

Apinizer, üzerinden geçen bütün istek/yanıt mesajlarını saklayabilir ve bunları birçok farklı amaçla kullanma olanağı sunar.

Mesajların hangi bölümlerinin loglanacağını API Proxy bazında yönetme yeteneğinin yanısıra, Proje bazlı olarak ve bütün API Proxy'ler için geçerli olacak şekilde ayar yapma özelliği sağlar. 

Gizlilik Yönetimi

(Privacy Management)

İstek/Yanıt trafiğinin loglanması, mesajlar içerisinde taşınıyor olabilecek hassas verilerin de loglanması anlamına gelir. Bu istenen bir durum değildir. Kişisel verilerin korunması kapsamında, hassas verilerin belirlenerek loglanmaması ya da maskelenerek, değiştirilerek loglanması gibi önlemler alınması gerekir.

Apinizer, hassas verilerin belirlenerek loglanmaması ya da maskelenerek veya şifrelenerek loglanabilmesi için konfigürasyon olanağı sunar.

API İzleme

(API Monitoring)

Bir sistemin düzgün, sağlıklı ve doğru çalışmakta olduğundan emin olmak için sistemin sürekli takip edilmesi işine İzleme (Monitoring) denir. Bu işlem API'ler bağlamında yapıldığında API Monitoring adını alır. 

Apinizer, İzleme için 2 farklı araç ve yöntem sunar:

• Çalışma Zamanı İzleme (Uptime Monitoring)
• Anomali Tespiti (Anomaly Detection)

API İzlemenin neden gerekli olduğu ve nasıl yapılabileceğini anlattığımız yazımızı okumak için tıklayınız.

Çalışma Zamanı İzleme

(Uptime Monitoring)

Anomali Tespiti

(Anomaly Detection)

Bir sistemin izlenmesinin bir şekli de log kayıtlarının incelenmesidir. Böylece API'ler kadar istemciler de izlenebilir. Beklenmeyen büyüklükteki mesajlar, bazen geçici olarak yavaşladığı için monitörler tarafından yavaşladığı tespit edilemeyen API'ler, belki hiç monitör tanımlanmamış API ya da uç noktalar ya da kötü konfigürasyondan kaynaklanan anormal durumlar bu şekilde belirlenebilir.

Apinizer, kullanıcıların form tabanlı arayüzler yardımı ile log kayıtları üzerinde çalışacak özelleşmiş sorgular oluşturmalarına izin verir. Sorgular kullanıcıların belirleyeceği aralıklarla işletilerek sonuçlar yine kullanıcılar tarafından verilen sınır değerler (thresholds) ile karşılaştırılır ve bu değerler aşılırsa tanımlı Aksiyonlar tetiklenir.

Aksiyon

(Action)

Görev Akışı

(Task Flow)

Apinizer, özellikle birden çok sisteme yayılan entegrasyon isterlerini karşılayabilmek için tasarlanmış olan, birden çok görev tanımının bir zincir gibi birbirlerine bağlanarak işletilmesini mümkün kılan Görev Akışları tanımlama imkanına sahiptir. Böylece örneğin veri tabanından çekilecek kayıtların belirli kolonlarındaki bilgiler kullanılarak birilerine mail göndermek, sonra başka kolonlardaki bilgileri kullanarak bir API çağrısı yapıp dönen sonuçları başka bir veri tabanına yazmak ve sonra da bir Shell Script çalıştırmak mümkündür. 

Apinizer bu Görev Akışlarının manuel olarak işletilmesine, bir zamanlayıcı tanımlanarak belirlenen aralıklarla otomatik işletilmesine, bir aksiyon olarak başka bir olaya bağlanmasına ya da bir adres üzerinden API olarak açılmasına izin verir.

Konnektör

(Connector)

Aksiyon ve Görev Akışlarının alt yapısında Konektörler vardır. Bir Konektör, bir başka sisteme bağlanma ve bir görevi işletme olanağı sağlar. 

Apinizer, veri tabanı konektörleri, e-mail konektörü, API konektörü, Shell Script, JavaScript, Groovy Script konektörü gibi çeşitli konektörler sunar.

Bağlantı Havuzu

(Connection Pool)

Oluşturması maliyetli olup kısa bir işlem için kullanıldıktan sonra kendilerine ihtiyaç kalmayan kaynakların, tekrar gerektiği zaman yeniden oluşturularak işlem yapılması performansı kötü etkileyen bir yöntemdir. Bu nedenle bu tip kaynaklar için kaynak havuzları oluşturulur ve bu kaynaklar havuzdan alınıp kullanıldıktan sonra havuza geri bırakılır. Böylece kaynakların tekrarlayan oluşturma maliyetleri ortadan kaldırılarak sistemin performansı iyileştirilir. Özellikle veri tabanı sunucusu kaynaklara yapılan bağlantılar için oluşturulan bu havuzlara Bağlantı Havuzu adı verilir.

Apinizer, konektörlerinin kullandığı bağlantıları havuzlarda yöneterek dış sistemler ile kurduğu iletişimin performansını yüksek tutar.

API Analizi

(API Analytics)

Verilen hizmetin kaliteli olabilmesi için, API Proxy'lerin performans ve hata verme durumlarının izlenmesi gerekir. Bu izleme, API İzleme'den farklı olarak, en yoğun kullanılan, en çok hata veren ya da en geç yanıt döndüren API'lerin belirlenmesi gibi, sistemin genel kullanım durumuna raporlama ya da grafiksel gösterimlerle yakından bir bakış sağlar.

Apinizer, log kayıtlarını Elasticsearch üzerinde saklaması ve sağladığı form tabanlı arayüzler sayesinde, kullanıcılara Elasticsearch bilme zorunluluğu getirmeden karmaşık sorgular oluşturma, API Proxy ya da endpoint bazlı raporlar tanımlama, full-text search yapma gibi olanaklar sunar. Daha deneyimli kullanıcılar ise Kibana veya Grafana ile verileri görselleştirmekte özgürdür.

Kimlik Doğrulama ve Kimlik Yönetimi

(Authentication and Identity Management)

Bir API Proxy erişime açıldığı zaman adresini bilen herkes o API Proxy'nin herhangi bir metodunu çağırabilir. Tahmin edileceği gibi, bu istenen bir durum değildir. Bu nedenle oluşturulan API Proxy için kimlik doğrulama politikalarından (OAuth2, JWT, Basic, Digest vb.) birinin uygulanması gerekir. Uygulanan politika, API Gateway'in gelen isteklerin izin verilen istemcilerden gelip gelmediğini sınamasını sağlar. Bu sınama işlemi için; mesajın bir bölümünden alınan kullanıcı adı/parola, API Key ya da Access Token gibi bilgilerin, geçerli kimlik bilgileri kümesi içinde doğrulanması gerekir. Bu işleme kimlik doğrulama, doğrulamada kullanılacak kimlik bilgilerinin yönetilmesi işine de Kimlik Yönetimi adı verilir.

Apinizer birçok kimlik doğrulama yöntemini politika olarak sunar. Buna ek olarak farklı şekillerde kullanılabilecek esnek kimlik yönetim araçları sağlar.

• İstemci Kimlikleri (Credentials)
• Erişim Denetimi Listeleri (Access Control Lists)
• Kimlik Sağlayıcılar (Authentication Providers)

İstemci Kimlikleri

(Credentials)

Apinizer, Güvenlik Yöneticisi rolüne sahip kullanıcılara, API Proxy'lere erişebilecek istemcilerin kimliklerini tanımlayabilecekleri arayüzler sunar. Oluşturulan kimliklere Roller atanabilir ve bu kimlikler Organizasyonlar ile ilişkilendirilerek daha kolay yönetilebilir. Her bir kimlik için hangi API Proxy'lere erişebileceği belirlenebilir. Kimlikler istendiği zaman pasife alınabileceği gibi, Sözleşme/Protokoller ile ilişkilendirilerek Sözleşme/Protokol süresinin bitiminde otomatik olarak devre dışı bırakılabilir. Ayrıca kimlik bazlı olarak IP kısıtlaması yapılabilir, kota ya da daraltma (throttling) belirlenebilir.

API Proxy'lere erişebilecek istemci kümesinin belirli ve statik olduğu senaryolarda İstemci Kimliklerinin kullanılması hem kolay, hem de yüksek performanslı bir çözüm sağlar.

İstemci Rolleri

(Credential Roles)

Organizasyon

(Organization)

B2B ya da G2G senaryolarda API Proxy'lere erişimler kimlik bazlı gerçekleşse de, anlaşmalar firma ya da kurumlarla yapılır ve API'ler de kişilere değil anlaşma yapılan firma ya da kurumlara açılır. Bununla birlikte, o firma/kurumdan kimlere erişim yetkisi verildiği de takip edilmelidir. Dolayısıyla istemci kurum/firma için tek bi kimlik tanımlamak yerine, bu firma/kurumun yetkilendirdiği kişilerin her birisi için ayrı birer kimlik oluşturulur. 

Apinizer, kullanıcılarına İstemci Kimliği oluşturulan firma ya da kurumlara genel olarak Organizasyon adını verir. Organizasyonların hiyerarşik bir şekilde tanımlanmasına olanak sağlar.

Erişim Denetimi Listeleri

(Access Control Lists)

Bir varlığa hangi kimliklerin erişebileceğinin belirlenmesiyle hazırlanan tablolara Erişim Denetimi Listesi adı verilir.

Apinizer, İstemci Kimliğini baz alarak hangi API Proxy'lere erişebileceğini belirleme ya da API Proxy'i merkeze koyup buna kimlerin erişebileceğini belirleme şeklinde hızla ve kolayca Erişim Denetim Listeleri hazırlanmasını sağlayan arayüzler sunar.

Kimlik Sağlayıcılar/Doğrulayıcılar

(Authentication Providers)

İstemcilerin daha dinamik belirlenmesi istenen senaryolar da olabilir. Örneğin bir firma kendi geliştirdiği bir merkezi uygulama ile hangi kullanıcının (istemcinin) nereye erişebileceğini yönetiyor ve bu bilgileri veri tabanında saklıyor, kullanıcılarını LDAP ya da Active Directory gibi bir yazılım ile yönetiyor ya da kendi geliştirdiği bir API üzerinden erişim denetimi gerçekleştiriyor olabilir. 

Bir kaynağa erişebilecek kullanıcı ya da istemcilerin kümesini sağlayan ve bu küme ile kimlik doğrulaması yapan/yapmayı mümkün kılan bileşenlere genel olarak Kimlik Sağlayıcı ya da Kimlik Doğrulayıcı adı verilir.

Apinizer, yaygın kullanılan veri tabanı yönetim sistemleri, LDAP/ACtive Directory ya da özel API'lerin kimlik sağlayıcı olarak kullanılmasına ve istenildiği şekilde konfigüre edilmesine izin verir. 

Sözleşme/Protokol

(Contract/Protocol)

B2B ya da G2G senaryolarda API'lerin erişime açılması genellikle bir sözleşme/protokol çerçevesinde ve süreli olarak gerçekleştirilir. 

Apinizer bu sözleşme/protokollerin API Gateway üzerinden yönetilerek hangi API'nin ne zaman hangi sözleşeme/protokol ile hangi istemcilerin erişimine açıldığının takip edilebilmesi ve istenirse süresi dolan sözleşme/protokol kapsamında erişimlerin otomatik kapatılması gibi özelliklere sahiptir.

Proje

(Project)

Birçok paydaşın işbirliği içinde çalıştığı bir platformda, kullanıcı yetkilendirme, gruplama, varlıkların yönetilmesi gibi çeşitli gereksinimleri ele alınması gerekir. 

Apinizer bu ihtiyacı karşılayacak şekilde Proje tabanlı çalışmayı benimsemiştir. Bir Proje, ilgili varlık ve kullanıcıların diğer Projelerden izole edildiği bir çalışma alanı (Workspace) sağlar. Böylece aynı kullanıcıların fakrlı projelerde farklı roller üstlenmesi, API Proxy'lerin, Politikaların ya da diğer tanımların Proje bazlı olarak yönetilebilmesi mümkün olur.

Takım

(Team)

Takım, bir projede çalışan üyelerin oluşturduğu gruptur. Kullanıcıların Projelere üye yapılması ya da Rol ataması gibi işlemlerin Takımlar üzerinden toplu olarak yapılabilmesini sağlar.

Apinizer, Takımlar oluşturulmasına, Kullanıcıların Takımlara farklı Roller ile üye yapılmasına, Takımların Projelere farklı rollerle atanmasına ya da Takımlara Rol atanmasına izin verir.

Kullanıcı

(User)

Apinizer arayüzlerini kullanan paydaşlara verilen isimdir. Bu bakışla API Tüketici dışındaki bütün paydaşlar Kullanıcıdır. API Proxy'lere erişen İstemciler ile karıştırılmamalıdır. 

Rol

(Role)

Yetki gruplarına verilen isimdir.   

Apinizer belirli rolleri varsayılan değerler olarak sunar, yeni rollerin oluşturulmasına izin verir.

Yetki

(Privilege)

Bir kullanıcının belirli bir işi yapabilmesi için o işle ilgili yetkiye sahip olması gerekir.

Apinizer bağlamında Yetkiler ön tanımlı olarak gelir ve Rollerin oluşturulması/güncellenmesi için kullanılır. Kullanıcılara doğrudan Yetki ataması yapılmaz.

Bazı API'ler bir algoritmanın dışarıya açılması ya da bir metodun başka paydaşlar tarafından işletilebilmesi için oluşturulur. Algoritma ya da metod hazır bulunabilir ya da  yeni geliştirilecek olabilir. Her iki durumda da bunun bir yazılım geliştirme ortamında yapılması, API'nin paketlenerek hizmete alınacağı bir sunucuya koyulması gibi adımları gerektirir. 

Apinizer, Script-2-API ile kullanıcıların JavaScript veya Groovy kodları yazarak (ya da var olanları yapıştırarak) anında bir API açmalarına olanak verir. Kodun içinde istek/yanıt mesajlarının istenen bölümlerinin kullanılması da mümkündür. Böylece API'nin hizmete alınması için ayrıca sunucu kurulması gibi işlere gerek kalmaz, dakikalar içinde API hizmete alınabilir.