“Listen to me, coppertop. We don’t have time for twenty questions. Right now, there is only one rule. Our way… or the highway.”

Bu sahneyi hatırlamayan var mı? Neo’nun “Ula nereye düştük!” bakışı, Trinity’den medet umuşu… Tam “iyi madem, ben de yürür giderim, ne uğraşacağım” diye arabadan çıkarken, Trinity’nin olaya müdahalesiyle arabada kalışı falan. Dile kolay, 25 sene geçmiş! Neyse, güzel filmdi. Bir ara tekrar seyredeyim.

Ne alaka diyorsanız, API Gateway konusunda da durum yukarıdakine biraz benziyor: “API Gateway or the code way” diyoruz.

Farklı olarak, 1- kimse kimseye silah çekmeyecek, 2- bizim sorular için vaktimiz var.

Bu yazıda “API Gateway ne işe yarıyor?”, “Neden API Gateway kullanmalıyız?” ya da “API Gateway kullanmalı mıyız?” gibi sorulara, Web Servis geliştirmeye yeni başlamış olanların da anlayabileceği şekilde cevap vermeye çalışacağım.

Başlamadan önce küçük bir hatırlatma: API sözcüğünün kelime anlamına takılmayalım lütfen. Bu yazının bağlamı Web Servisler ve biz de API olarak kullanılan Web Servislerden bahsedeceğiz. Genelde Web Servisler ile ilgili konuşurken “Web Servis” deyince akla SOAP, WSDL ve XML, “API” deyince akla REST, Swagger ve JSON gelse de, bu yazıda ben her iki terimi de; yani “Web Servis” ve “API” terimlerini aralarındaki küçük farkları umursamadan aynı anlamda kullanacağım.

Bir Web Servis edinelim

Örnek bir Web Servis yazarak başlayalım. Ancak bu yazının konusu API Gateway olduğu için, servis geliştirme konusunu şuradaki yazıya bırakıyorum: https://spring.io/guides/gs/rest-service/. Yazıyı takip edin, SpringInitializr ile aşağı yukarı 5 dakika içinde Web Servisiniz çalışır hale gelecektir.

Web Servisin hangi dilde yazıldığı, SOAP ya da REST olması önemli değil. API Gateway dilden ve protokolden bağımsız olarak bütün Web Servisler için kullanılabilir.

Sorun Ne?

“Ee, beş dakikada servisi yazdım, çalıştırdım. Birkaç metod (endpoint) daha eklemek ne kadar zor olabilir ki?” diyen var mı? Kesin vardır. Şimdi burada Cross-cutting Concerns, Containers ya da Proxy Objects gibi havalı terimlerle kod örnekleri verip birşeyler anlatmak mümkün tabi. Ancak o zaman yeni başlamış arkadaşları yazının başında kaybedebiliriz diye düşündüğüm için oralara girmeyeceğim. Zaten deneyimli arkadaşlar için de bunları yazmaya bile gerek yoktur diye düşünüyorum :). O yüzden daha basit ve sözel ilerleyelim.

Gördüğünüz gibi Web Servis geliştirmek çok da büyütülecek bir iş değil. “Gerçek hayatta servisler bu kadar basit olmaz.” diyeceksiniz ama emin olun genelde çok da karmaşık olmaz. Çoğu zaman Web Servisler geliştirerek veri tabanı işlemlerini, algoritmik çözümleri ya da başka uygulamalarımızla kurum içinde yapabildiğimiz ve zaten var olan bir takım işlevleri Internet/ağ üzerinden çağrılabilir hale getirmekten başka bir iş yapmayız. Zaten Web Servisin özü de budur: bir metodu HTTP ile çağrılabilir hale getirmek.

Web Servisler ile ilgili esas zorluk, servislerin ve istemcilerin sayısının hızla artması ile birlikte gelen yönetimsel problemlerin çözülmesidir. Bunlara birkaç örnek verelim:

1- Kimlik Doğrulama (Authentication): Web Servisleri sunucuya koyup Internet’e açtığınız zaman genellikle herkesin çağırmasını istemezsiniz. Bu durumda sadece tanımlı kullanıcıların erişmesine izin vermek için bir kimlik doğrulama mekanizması kurmanız gerekir.

2- Yetkilendirme (Authorization): Kullanıcı sayısı ile Web Servislerin ve/veya metodların (endpointlerin) sayısı arttıkça, “şu kişiler şu metodları çağırsın ama şu kişiler bu metodları çağıramasın” şeklinde talepler gelmeye başlar. Bunun için yetkilendirme yapmanız gerekir.

3- IP Kısıtlama: Sadece belirli IP’lerden gelen isteklerin kabul edilmesi, ya da belirli IP’lerden gelen isteklerin kabul edilmemesi istenebilir. Bunun için ağ ekibinden destek isteyip sizin servise gelen istekler için Firewall ayarlarını güncellemelerini isteyebilirsiniz. Ama emin olun, yeni IP’ler eklenmesi ya da sunucuyu değiştirmeniz, servisi taşımanız ya da yeni sunucular eklemeniz gerektiği zamanlar olacak ve ağ ekipleriyle kısa sürede sorun yaşamaya başlayacaksınız.

4- İçerik Filtreleme (Content Filtering): Gelen bütün istekler masum mu acaba? Belki saldırılar olacak. Bunları nasıl engelleyeceksiniz? Gene ağ ekibine mi başvuracaksınız? Ya da bu yeterli olacak mı?

5- Şifreli İletişim (Encryption/Decryption): Gelen giden mesajların şifrelenmesi istenebilir. “Servisi HTTPS ile açtım, ne gerek var?” diyemiyoruz maalesef. Bazen müşteriler ya da kurumlar “İlle şifreli isterim” diyebiliyor. Hatta bazen “İstekler imzalı gelsin, imzayı açıp doğrulayıp sen de imzalayarak gönder.” talebiyle de karşılaşabilirsiniz, hazırlıklı olun. Burada ağ ekibi de yardım edemeyecek.

6- WsSecurity diye birşey duydunuz mu? Bütün bu şifrele, şifreyi aç, imzala, doğrula işlerinin standardı var ve bazı kurumların SOAP servislerinde bu kullanılıyor. Böyle bir servise istemci olmak için kod yazacak arkadaşlara kolaylıklar diliyorum.

7- Mesaj Doğrulama (Schema Validation): Servisimize gönderilmesini beklediğimiz mesajın yapısı belli ise, örneğin “Şu alanda Integer, şu alanda Date bekliyorum” diyebiliyorsak, bunlara ilişkin kontrollerin de yapılması gerekmez mi?

8- Bazen kurumlar diyor ki: “Benim servisim yalnızca hafta içi şu günler, şu saatler arasında hizmet versin, diğer zamanlar çalışmasın”. Bunu nasıl ele alırdınız?

9- Mesaj Dönüşümleri (Message Transformation): İstemci sayısı arttıkça, “Mesajın yapısını şöyle değiştirebilir misiniz?”, “Null alanları hiç göndermeseniz olmaz mı?”, “Dizileri şöyle gönderin.” şeklinde talepler de artmaya başlar ve bazen bundan kaçamazsınız, yapmak zorunda kalırsınız.

10- İstemciye Göre Özelleştirilmiş Yanıtlar (Redaction): Servisiniz belirli bir yapıda cevap dönüyordur ama, bir süre sonra “Şu tipteki kullanıcılara şu bilgi de dönecek ama diğerleri bu bilgiyi göremeyecek.” şeklinde güncellemeler yapmanız istenir. Bu sefer ya servisleri çoklamanız ya da kişiye özel yanıt dönecek şekilde kod yazmanız gerekir.

11- Loglama: İlle de log istenir. Tipik sorular: “Kim çağırmış?”, “Ne zaman çağırmış?”, “Ne göndermiş?” “Biz ona ne göndermişiz?”, “Şu bilgiyi kimlere göndermişiz?”… Logları tutmak yetmez, sorgulayabilir olmanız istenir.

12- Servisin çalışıp çalışmadığının kontrolü (Monitoring): 7/24 hizmet vermesi gereken bir servis yazdınız. Peki ayakta olup olmadığını, düzgün cevap dönüp dönmediğini nasıl kontrol edeceksiniz? Bir şekilde durursa, hatalı cevaplar dönmeye başlarsa ya da yavaşlayıp da timeout yemeye başlarsa ne olacak? Bundan nasıl haberiniz olacak? Birilerinden şikayet telefonları ya da e-postaları gelmesini mi bekleyeceksiniz? Tabi ki hayır. Bunlar için bir takım önlemler almak lazım.

13- Hata Mesajları (Error Message Handling): Web Servisiniz hangi durumda hangi hata mesajını ya da HTTP kodunu dönecek? Bunları nasıl özelleştireceksiniz? “Buna gerek var mı? 500 koduyla beraber ‘hata oluştu’ mesajını dönsek olmaz mı?” diyebilirsiniz. Olmaz! Birçok istemci var ve hata mesajlarının anlamlı olması gerek. Hata mesajı istemciye eksik parametre gönderdiğini ya da IP’sinin hatalı olduğunu söylemezse istemci bunu nereden bilecek de hatayı düzeltecek? Herkesten telefon ya da e-mail ile “şöyle bir hata dönüyor, düzeltemiyorum, yardım et” talebi alıp tek tek uğraşmak istemiyorsanız anlamlı mesajlar dönmeniz lazım.

14- Bakım: Kullanılmakta olan bir sistemi çalışırken güncellemeyi hiç denediniz mi? Web servisiniz için bunu bir hayal edin.

15- Servis Taşıma: Bir sebeple servisin adresini değiştirmeniz gerekebilir. Çok sayıda istemciniz varsa ne olacak? Herkesin kendi kodunu güncelleyerek yeni adresi kullanmaya başlaması, ya da sizin bu değişikliği istemcilere hissettirmeden yapmanız gerekiyor. İkincisi çok daha iyi ama nasıl yapacaksınız?

16- Yük Dengeleme ve Hata Giderme (Load Balancing & Failover): Servisler kritik hale geldikçe üzerinizdeki baskı da artacak. Bir servisin çalışamaz hale gelmesi ya da performansın düşmesi kabul edilemez olacak ve bu sefer başka sunuculara da servisi yükleyip bir cluster oluşturmak isteyeceksiniz. Böylece hem yük sunuculara dağılsın, hem de herhangi bir sunucu sorun çıkarırsa isteği diğer sunuculardan biri yanıtlasın, istemcilerin trafiği aksamasın. Güzel. Peki nasıl yapacaksınız?

17- Servislerin sayısı arttıkça bunların varlığının takibi bile ayrı bir sorun oluyor. Bazı kurumlar Web Servislerini açmadan önce kullanacak kurumlarla protokol yapıyor. Hangi servisin, hangi tarihte, hangi protokol ile açıldığını, protokolün ne zamana kadar geçerli olduğunu yönetmek gerekiyor. Hatta bazen bunun otomatik yapılması isteniyor. Kolay gelsin.

18- Dokümantasyon: Servislerin nasıl kullanılacağının dokümante edilmesi gerekir. Bunun için Swagger ya da OpenAPI gibi standartlara güvenmek işi kolaylaştıracaktır. Peki acaba bu yazıyı okuyan ve Web Servis geliştiren/geliştirmiş olan kaç kişi şu ana kadar en az 1 tane Swagger ya da OpenAPI dosyası hazırlamıştır? Formatı biliyor musunuz?

Bu maddelerin sayısını arttırabilirim, ancak şimdilik bunlar yeterli diye düşünüyorum. Eğer sabırla hepsini okuduysanız ve şöyle bir an durup “Bunları nasıl yaparım?” diye düşündüyseniz, bir Web Servisin iş mantığını kodlamak dışında yapılması gereken ne kadar çok iş olduğunu fark etmişsinizdir. Bunların bir kısmı kod yazılarak ele alınabilir tabi ki. Ancak Web Servislerin sayısının 1 değil 100, 200, 500 olabileceğini, ekibinizde bu seviyede kod yazabilecek kaç kişi olduğunu, yazılan bütün kodların bakımının da yapılması gerekeceğini de bir düşünün. Ve hemen uzaklaşın o her şeyi kodlayarak çözme dürtüsünden!

Buraya kadar yazdıklarımın özeti olarak aşağıdaki çizimi hazırladım. Terimleri özellikle İngilizce yazdım, çünkü maalesef böyle daha anlaşılır oluyor.

İş mantığını kodlayıp Web Servisi hizmete almak buz dağının üst kısmıdır. Esas iş buzdağının altındadır ve bunları ihmal etmek ölümcül bir hata olabilir (bak şimdi de Leonardo geldi aklıma, arkadaş sen de çıksana kızın yanına, niye artistlik yapıp donuyorsun?!).

API Gateway ne işe yarar?

API Gateway, yukarıda değindiğim işleri ve çok daha fazlasını Web Servislerin koduna dokunmadan, konfigürasyon yaparak çözmeye yarayan yazılımların ortak adıdır. Web Servislerinizin önüne koyulur ve Web Servislerin mesaj trafiği API Gateway üzerinden geçer. Böylece bu mesajlar üzerinde her türlü kontrol, dönüşüm ya da özelleştirme olanaklı hale gelir.

Şekilde görüldüğü gibi, istemcinin gönderdiği istek (1. Adım) API Gateway üzerindeki Proxy tarafından karşılanır. Proxy, erişilecek Web Servis için API Gateway üzerinde oluşturulan vekil varlıktır ve İstemci (Client) aslında Proxy ile iletişime geçer. Proxy, Web Servise istemci olur (2. Adım) ve Web Servisin döndürdüğü yanıtları (3. Adım) alıp İstemci’ye kendisi yanıt döndürür (4. Adım). API Gateway yazılımı ile yapılan konfigürasyonlar aracılığı ile Proxy’nin davranışı özelleştirilir ve bu sayede güvenlik, trafik yönetimi, mesaj dönüşümleri, servis taşıma ve benzeri gereksinimler merkezi bir noktadan yönetilebilir hale gelir.

Bir API Gateway yazılımının düşük gecikmeli, yüksek performanslı ve ölçeklenebilir olması kadar, kolay kullanılabilen arayüzler sağlaması, Single Point of Failure oluşturmayacak şekilde konumlandırılabilmesi, farklı rollerde çok sayıda kullanıcıyı desteklemesi gibi özellikler taşıması da önemlidir. İhtiyaca bağlı olarak farklı ve çeşitli araçlarla/yazılımlarla entegre olabilmesi ya da bunları sunması da bir API Gateway’in tercih edilmesinde etkin rol oynayabilir.

Bütün bu işlerin sadece konfigürasyonla yapılabiliyor olmasının bariz faydalarını şöyle özetleyebiliriz:

1- Web servis geliştirme, iş mantığını kodlamaya indirgenir. Geri kalan bütün ihtiyaçlar için sadece konfigürasyon yapılır. Dolayısıyla daha az sayıda ve daha az uzman personel ile daha çok Web Servis/API geliştirip sunmak mümkün olur, verimlilik artar.

2- Zaman ve maliyet önemli ölçüde azalır.

3- Güvenlik ve loglama gibi alt düzeyli ve görece zor konular merkezi olarak ele alınır, kontrolü ve gerçekleştirilmesi çok daha kolaydır. Dolayısıyla acemi yazılımcıların yapmış olabileceği hatalar minimuma indirgenir; risk azalır, kalite artar.

4- Servislerin durumu sürekli izlenip hatalar anında tespit edilerek çözülebilir. Böylece prestij/müşteri/para kaybı önemli ölçüde engellenir.

API Gateway kullanmamış kimseler için bu kadar bariz olmayan faydalardan birkaçına da değinmeden bitirmeyelim:

1- Aşağıdaki sorular cevaplanabilir olur:

Kaç tane Web Servisim var?
Web Servislerime kimler erişiyor?
Hangisini ne zaman, neden açmışız?
Ne istek gelmiş, ne yanıt dönmüşüz?
En çok hata veren servislerimiz hangileri?
En çok kullanılan servislerimiz hangileri?
Web Servislerimizin performansı nasıl?
Hangi güvenlik önlemlerini almışız?

2-Kod miktarı ve dolayısıyla bakım maliyeti çok önemli oranda azalır.

3-Servisler kayıtlı hale gelir. Bir yerlerde çalışan ve varlığından haberdar olmadığınız servisler kalmaz.

4- Servis kataloğu oluşur. Böylece aynı servislerin tekrar tekrar yazılması sorunu çözülür.

5- Servislerin performansları izlenerek performans arttırmaya yönelik önlemler alınabilir.

6- Servis trafiği izlenebilir, raporlanabilir hale gelir.

Sonuç

Sadece birkaç Web Servisiniz var bunları da uygulamalarınız arası veri alış verişi için kullanıyorsanız, yani hem sunan hem de tüketen kendinizseniz, bir API Gateway kullanmaya ihtiyacınız olmayabilir. Ancak Web Servis sayısı artarsa, başka kurum/firmaların çağırması için Web Servisler geliştirmeye ya da başka firma/kurumların geliştirdiği Web Servislere birçok uygulama içinden istemci olmaya başlarsanız bir API Gateway kullanmayı değerlendirmekte fayda var.

Bir tanesini hızlıca denemek isterseniz, bir süredir üzerinde çalıştığımız bir tane var: https://demo.apinizer.com