API gateway nedir?

API gateway, istemci uygulamalar ile arka plandaki API ve mikroservisler arasında duran merkezi bir geçiş katmanıdır. İstemciden gelen isteği karşılar, uygun servise yönlendirir ve gerekiyorsa kimlik doğrulama, yetkilendirme, hız sınırlama, istek günlüğü, hata biçimlendirme veya yanıt önbellekleme gibi ortak işlemleri uygular. Böylece web sitesi, mobil uygulama ya da dış entegrasyonların her servisin adresini ve iç çalışma ayrıntılarını bilmesi gerekmez.

Gateway, işlevi istemci ile servisler arasındaki geçişi yönetmek olan bir yazılım veya yönetilen hizmettir; çoğunlukla ters proxy gibi çalışır. İstemci dışarıya tek bir API adresi görürken gateway içeride farklı servislerle haberleşebilir. Ancak gateway, servislerin içindeki iş kurallarının yerine geçmez. Kullanıcının belirli bir siparişi görmeye yetkili olup olmadığı gibi kaynak ve iş bağlamı gerektiren kontroller ilgili serviste de yapılmalıdır.

Nasıl çalışır?​

Örneğin istemci https://example.com/api/orders/42 adresine istek gönderdiğinde akış şu şekilde olabilir:

1. Gateway isteğin yolunu ve HTTP metodunu kontrol eder.
2. Gerekliyse erişim belirtecini doğrular ve isteğin hangi istemciye ait olduğunu belirler.
3. İsteği dahili sipariş servisine yönlendirir; istemci bu servisin iç adresini görmez.
4. Servisten gelen yanıtı istemciye iletir, gerekirse ortak hata biçimine dönüştürür.
5. Durum kodu, gecikme ve korelasyon kimliği gibi bilgileri izleme sistemine aktarır. Parola, belirteç ve hassas istek gövdeleri günlüklere gelişigüzel yazılmaz.

Bir gateway tek isteği tek servise yönlendirebileceği gibi, birden fazla servisten veri toplayıp istemciye tek yanıt da sunabilir. Örneğin mobil uygulamanın ana ekranı için profil, bildirim ve sipariş servislerine ayrı ayrı istek göndermek yerine bunları birleştiren bir gateway uç noktası tasarlanabilir. Bu yaklaşım istemci tarafındaki ağ trafiğini azaltabilir; fakat gateway üzerinde gereksiz iş mantığı biriktirilmemelidir.

Hangi sorunu çözer?​

Gateway kullanımı özellikle birden fazla API veya mikroservis olduğunda anlamlıdır. Dış API sözleşmesini içerideki servislerden ayırır, istemcinin dahili servis adreslerine bağımlılığını azaltır ve ortak politikaları tek noktadan uygulamayı kolaylaştırır. Fakat gateway tek başına güvenlik çözümü değildir. Gateway kontrolleri atlanmamalı, dahili servisler doğrudan erişime kapatılmalı ve servisler kendi hassas yetkilendirme kurallarını uygulamaya devam etmelidir.
Bu ayrım, gateway’in büyüyerek bütün uygulama mantığını taşıyan kırılgan bir katmana dönüşmesini önler.

Uygularken izlenecek yol​

1. Dışarıya sunulacak yolları belirleyin. Örneğin /api/users ve /api/orders gibi istemci sözleşmelerini, dahili servis adlarından bağımsız tasarlayın.
2. Her yol için hedef servisi, izin verilen HTTP metotlarını, kimlik doğrulama gereksinimini ve beklenen hata biçimini tanımlayın.
3. Gateway’de kaba erişim politikalarını uygulayın: kimlik doğrulama, temel yetki kapsamı, istek boyutu, hız limiti ve uygun HTTP metodu kontrolü.
4. Dahili servisleri yalnızca gateway’den veya güvenilir servis ağı üzerinden erişilebilir hâle getirin. Aksi durumda istemci gateway kontrollerini atlayabilir.
5. Kimlik bilgisini istemciden gelen rastgele başlıkları olduğu gibi güvenerek aktarmayın. Gateway’in doğruladığı bağlamı kontrollü biçimde iletin; servis de bu bağlamı doğrulasın.
6. Başarılı istekleri ve hataları korelasyon kimliğiyle izleyin. Gateway’in yanıt vermemesi, yanlış yönlendirme veya aşırı yük gibi durumlar için sağlık kontrolü ve geri dönüş davranışı tanımlayın.
7. Önce tek bir düşük riskli uç noktada deneyin. Beklenen sonuç, dış istemcinin gateway adresinden başarılı yanıt alması ve güvenilmeyen ağdan dahili servise erişimin reddedilmesidir.

Güvenilmeyen dış istemci dahili servise doğrudan ulaşabiliyorsa ağ erişim kuralları incelenmelidir. Güvenilir servis ağına bilinçli olarak verilen erişim bununla aynı durum değildir. Gateway yanıt veriyor fakat servis bulunamıyorsa yönlendirme yolu, port veya servis keşfi ayarlarını kontrol edin. Gateway kimlik doğrulamasını geçirdiği hâlde hassas bir nesneye yetkisiz erişim mümkünse sorun gateway’den çok servis seviyesindeki kaynak yetkilendirmesindedir.

Sık yapılan hatalar​

Gateway’de bütün iş kurallarını toplamak, zamanla tek ve zor değiştirilen bir monolit oluşturur. Sadece gateway’e güvenmek de hatalıdır; dahili servise doğrudan erişim veya alternatif bir uç nokta varsa kontroller aşılabilir. Her isteğe sınırsız izin vermek, yalnızca kimlik doğrulamayı yeterli saymak ve belirteçleri URL içinde taşımak da risklidir. Ayrıca gateway’e fazla sayıda görev yüklemek gecikmeyi ve tek hata noktası etkisini artırabilir. Merkezi katman için izleme, yedeklilik ve kontrollü hata davranışı baştan planlanmalıdır.

Sık sorulan sorular​

API gateway ile load balancer aynı şey midir?​

Hayır. Load balancer öncelikle trafiği birden fazla sunucuya dağıtır. API gateway ise yönlendirmeye ek olarak API kimliği, politika, istek biçimi, kota ve gözlemlenebilirlik gibi API’ye özgü işlemleri de üstlenebilir. Bazı ürünler iki rolü birlikte sunabilir.

Küçük bir uygulamada API gateway gerekli midir?​

Tek bir backend ve basit bir istemci varsa ayrı bir gateway katmanı gereksiz karmaşıklık yaratabilir. Birden fazla istemci, servis, dış entegrasyon veya merkezi trafik politikası oluşmaya başladığında kullanımı daha anlamlı hâle gelir.

Her API gateway aynı özellikleri sunar mı?​

Hayır. Yönlendirme ortak bir ihtiyaç olsa da kimlik doğrulama, kota, önbellek, protokol dönüşümü ve birden fazla yanıtı birleştirme desteği ürüne göre değişir. Kullanacağınız ürünün bu özellikleri hangi yapılandırma ve çalışma koşullarıyla sunduğunu doğrulayın.