Amazon API Gateway nedir?

Amazon API Gateway, uygulamalarınızın sunduğu API'leri oluşturmanızı, yayınlamanızı, korumanızı ve izlemenizi sağlayan yönetilen AWS hizmetidir. İstemci ile arka uç sistem arasında bir geçit gibi çalışır: gelen isteği uygun endpoint'e yönlendirir, kimlik doğrulama ve yetkilendirme uygulayabilir, istekleri sınırlayabilir ve cevabı istemciye iletir. Arka uç olarak AWS Lambda, bir HTTP sunucusu, konteyner servisi veya başka bir AWS hizmeti kullanılabilir.

API Gateway bir veritabanı, kullanıcı arayüzü veya iş mantığının kendisi değildir. Örneğin sipariş oluşturma kurallarınız Lambda ya da kendi uygulama sunucunuzda bulunur; API Gateway ise bu işlevin dışarıya hangi URL ve yöntemle açılacağını, hangi istemcilerin erişebileceğini ve trafiğin nasıl yönetileceğini belirler.

Nasıl çalışır?​

Bir mobil uygulama, web arayüzü veya başka bir servis API Gateway üzerinde yayınlanan endpoint'e HTTP isteği gönderir. Gateway isteğin yöntemini ve yolunu eşleştirir; gerekiyorsa token doğrulaması, seçilen API türünde destekleniyorsa API anahtarı/kullanım planı veya istek sınırlaması uygular. REST API kullanım planı anahtarları kimlik doğrulama ve yetkilendirme mekanizması değildir. Ardından isteği yapılandırılmış entegrasyona iletir. Arka uçtan gelen durum kodu, başlıklar ve gövde istemciye döndürülür.

Somut bir örnekte, sipariş uygulamanızda GET /orders/42 isteği olsun. İstemci bu isteği API Gateway'e gönderir. Gateway, kullanıcının erişim belirtecini kontrol ettikten sonra isteği sipariş Lambda işlevine aktarır. Lambda veritabanından 42 numaralı siparişi okur ve sonucu JSON olarak döndürür. Sipariş bulunamazsa arka uç uygun bir hata kodu üretir; Gateway de bu cevabı istemciye iletir.

Bu yapı sayesinde istemcinin Lambda adı, iç servis adresi veya veritabanı bağlantısı gibi ayrıntıları bilmesi gerekmez. Ancak iş mantığı ve veri doğrulama yalnızca Gateway'e bırakılmamalıdır; asıl yetki kontrolü ve iş kuralları güvenilir biçimde arka uçta da uygulanmalıdır.

API türünü seçme​

İhtiyaca göre API Gateway'in sunduğu API türlerinden biri tercih edilir:


Bu seçim yalnızca isim farkı değildir. Gereken doğrulama yöntemi, dönüşüm, istemci tipi, bağlantı modeli ve operasyonel ihtiyaçlar önce belirlenmelidir. Basit bir HTTP servisi için daha kapsamlı bir API türü seçmek gereksiz yapılandırma getirebilir; özellik matrisi kontrol edilmelidir. REST API ve HTTP API ikisi de RESTful yaklaşımı destekler; AWS ürün adlarındaki fark mimari REST/HTTP karşıtlığı değildir. Kullanım planları ve API anahtarları gibi REST API özelliklerinin HTTP API’de de bulunduğunu varsaymayın.

Uygulamada izlenecek yol​

1. API'nin kaynaklarını ve yöntemlerini belirleyin. Örneğin /orders için listeleme, tek sipariş görüntüleme ve oluşturma işlemlerini ayrı endpoint'ler olarak tanımlayın. Her işlem için beklenen istek gövdesini, başarı durumunu ve hata durumlarını yazılı hale getirin.
2. Arka uç entegrasyonunu seçin. Lambda kısa süreli ve olay temelli işlemler için, mevcut HTTP uygulamanız ise servis adresini koruyarak yayınlama için uygun olabilir. Gateway'in iş mantığını değil, yönlendirme ve API katmanını üstlendiğini unutmayın.
3. Kimlik doğrulama ve yetkilendirmeyi yapılandırın. Kullanıcının kim olduğunu doğrulamak ile o kullanıcının belirli siparişe erişip erişemeyeceği farklı kontrollerdir; kaynak sahipliği kontrolünü arka uçta da uygulayın.
4. İstek ve yanıt sözleşmesini kesinleştirin. Durum kodlarını, JSON alanlarını ve doğrulama hatalarını tutarlı biçimde belirleyin. Gerekirse API türünün desteklediği Gateway başlık, yol veya gövde dönüşümünü kullanın.
5. API'yi bir aşama veya ayrı yayın sürümü üzerinden test edin. Başarılı testte beklenen HTTP durum kodunu ve yanıt gövdesini alın. 4xx yanıtları çoğunlukla istemci isteği, kimlik bilgisi veya yetki sorunu; 5xx yanıtları ise entegrasyon ya da arka uç hatası araştırılması gerektiğini gösterir.
6. İzleme ve sınırları ekleyin. Trafik artışında arka uç için istek sınırlamayı değerlendirin. REST API kullanım planı kotaları best-effort uygulanır, kesin maliyet tavanı veya erişim engeli değildir; günlüklerde kimlik bilgileri ve hassas veri bırakmamaya dikkat edin.
7. İstemciyi yayınlanan API sözleşmesine bağlayın ve değişiklikleri geriye dönük uyumluluğu gözeterek yayınlayın. Kırıcı değişiklik gerekiyorsa eski istemcilerin geçişini planlamadan mevcut endpoint'i değiştirmeyin.

Sık yapılan hatalar​

En yaygın hata, API Gateway'i güvenlik mekanizmasının tamamı sanmaktır. Gateway'de erişim kontrolü bulunsa bile Lambda veya uygulama sunucusu gelen kullanıcının ilgili kaynağa yetkili olup olmadığını kontrol etmelidir. Başka bir hata, her isteği gereksiz yere yeni bir servis zincirinden geçirmek ve gecikme ile hata ayıklama karmaşıklığı oluşturmaktır.

CORS yapılandırmasını da yalnızca sunucu tarafında test etmek yanıltıcı olabilir. Tarayıcı, gerçek isteğin öncesinde ön kontrol isteği gönderebilir; bu isteğin yöntem ve başlıklarının da doğru yanıtlanması gerekir. Ayrıca Gateway'de tanımlanan yol ile arka uç uygulamasının beklediği yol uyuşmuyorsa endpoint var görünmesine rağmen entegrasyon hatası alınabilir.

Önce küçük bir endpoint'i uçtan uca doğrulamak, ardından ortak yetkilendirme, hata biçimi, günlükleme ve yayınlama kurallarını diğer kaynaklara uygulamak daha sağlıklı bir başlangıçtır. API sözleşmesi kararlı hale geldiğinde istemciler, arka uç uygulamasının iç ayrıntılarından bağımsız geliştirilebilir.

Sık sorulan sorular​

API anahtarını gizlemek kullanıcı yetkilendirmesi için yeterli mi?​

Hayır. AWS API Gateway kullanım planı anahtarları kimlik doğrulama veya yetkilendirme için kullanılmamalıdır. API türünün desteklediği IAM, JWT/Cognito ya da Lambda authorizer çözümünü seçin; kullanıcının ilgili kaynağa erişimini arka uçta da doğrulayın.

Gateway üzerinden HTML yanıtı döndürülebilir mi?​

Evet, uygun entegrasyon HTTP gövdesi ve Content-Type ile HTML döndürebilir. Gateway’in temel rolü yine API giriş katmanıdır; bunu dosya depolayan ve tüm site varlıklarını yöneten bir web barındırma ürünüyle karıştırmayın. Statik sitenin dosya dağıtımı ayrı tasarlanabilir.