API yönetimi eskiden bir GUI konsolu ve bir satıcı faturası anlamına gelirdi. Bu hâlâ geçerli, ancak günlük işlerin çoğu artık terminalden yürütülüyor: rotaları, eklentileri ve hız sınırlarını bir yapılandırma dosyasında tanımlar, Git’e kaydeder ve bir CLI ile ağ geçidine uygularsınız. Böylece kontrol panelinde tıklama ihtiyacı ve gözden geçirilen yapılandırma ile dağıtılan yapılandırma arasındaki sapma azalır.
Açık kaynak boyutu burada önemlidir. Kendi ağ geçidinizi çalıştırdığınızda lisans; neleri barındırabileceğinizi, çatallayabileceğinizi ve dağıtabileceğinizi belirler. Bu listedeki araçların çoğu Apache 2.0 veya MPL 2.0 lisansına sahiptir. Bu da kaynak koduna erişim, kendi altyapınızda çalışma ve kullanıcı başına lisans maliyetinin olmaması anlamına gelir.
Bu yazıda gerçek komut satırı iş akışları sunan açık kaynak API ağ geçitlerini ele alıyorum:
- Kong Gateway OSS + decK
- Tyk
- KrakenD Community Edition
- Apache APISIX
- Gravitee
Her araç için lisansını, CLI'nin ne yaptığını ve doğrudan çalıştırabileceğiniz komutları göreceksiniz. Daha geniş platform karşılaştırması için açık kaynak API yönetim araçları özetine bakabilirsiniz. Lisans terimlerini doğrulamak için resmi Apache 2.0 lisans metni iyi bir başlangıç noktasıdır.
Not: Apidog bu listede açık kaynak bir araç olarak yer almıyor. Ücretsiz katmanı bulunan ticari bir üründür. Yazının sonunda, ağ geçitlerini tamamlayan kullanım alanını ayrı olarak ele alıyorum.
Bir CLI aracını API yönetimi için “açık kaynak” yapan nedir?
Bir aracın ücretsiz deneme sürümü değil, gerçek bir açık kaynak seçeneği olduğunu doğrulamak için üç noktayı kontrol edin.
1. Lisans
Yalnızca istemci SDK'larında değil, çekirdek ağ geçidinde de Apache 2.0, MIT veya MPL 2.0 lisansı arayın.
- Apache 2.0: Kendi kendine barındırma, değiştirme ve dağıtma özgürlüğü sağlar.
- MPL 2.0: Dosya düzeyinde copyleft lisansıdır. MPL lisanslı dosyalarda yaptığınız değişiklikler açık kalmalıdır; ayrı dosyalardaki özel kod veya eklentilerle birlikte kullanılabilir.
- “Source available” veya BSL: Açık kaynakla aynı anlama gelmez.
Uygulamada, ürün sayfasındaki etikete güvenmek yerine depodaki LICENSE dosyasını inceleyin.
2. Kendi kendine barındırma
Ağ geçidi, lisans doğrulamak için harici bir satıcı sunucusuna ihtiyaç duymadan altyapınızda çalışabilmelidir. Veri düzlemi sizin kontrolünüzde olmalıdır.
Kontrol listesi:
- Docker veya ikili dosya ile kendi ortamınızda çalışıyor mu?
- Kritik özellikler yalnızca ücretli kontrol düzlemine mi bağlı?
- Community Edition, üretim kullanımında temel işlevleri kısıtlıyor mu?
3. Bakımı yapılan depo ve çalışan CLI
GitHub yıldız sayısı tek başına yeterli değildir. Commit geçmişini, sürüm yayınlarını, açık issue'ları ve dokümantasyon güncelliğini kontrol edin.
CLI ile aşağıdaki iş akışlarından en az birini gerçekleştirebilmelisiniz:
- Yapılandırmayı doğrulamak
- Yapılandırmayı Git'te sürümlemek
- CI içinde dağıtım veya senkronizasyon yapmak
- Değişiklikleri gözden geçirmek veya farklarını görmek
Genel kavramlar için API yönetiminin gerçekte neleri kapsadığına da göz atabilirsiniz.
Kong Gateway OSS: decK ile yapılandırmayı Git'te yönetin
Kong Gateway OSS, Kong'un Apache 2.0 lisanslı sürümüdür. Ağ geçidini Yönetici API'si üzerinden yönetebilirsiniz; ancak terminal merkezli ve bildirimsel iş akışı için asıl araç decK'tir.
decK, çalışan Kong durumunu YAML olarak dışa aktarmanıza, değişiklikleri gözden geçirmenize ve yapılandırmayı yeniden senkronize etmenize yardımcı olur.
# Mevcut Kong yapılandırmasını bir dosyaya aktar
deck gateway dump -o kong.yaml
# Yapılandırmayı gözden geçirmek için dosyada değişiklik yapın,
# ardından ağ geçidiyle senkronize edin
deck gateway sync kong.yaml
Önerilen Git iş akışı:
# CI öncesinde değişiklikleri yerelde inceleyin
git diff -- kong.yaml
# İnceleme ve onaydan sonra senkronizasyonu çalıştırın
deck gateway sync kong.yaml
En uygun kullanım: Kong kullanan ve rotaları ile eklentileri Git, code review ve CI üzerinden yönetmek isteyen ekipler.
Sınırlamalar:
- Kong'a özgüdür.
- API tasarımı veya test otomasyonu yerine Kong yapılandırmasını yönetir.
- Kong yığını, tek ikili dosyadan oluşan ağ geçitlerine göre daha kapsamlıdır.
Tyk: özel eklentileri paketleyin
Tyk Gateway, Mozilla Public License 2.0 altında açık kaynaklıdır. Go ile yazılmış çekirdek ağ geçidi REST, GraphQL, TCP ve gRPC'yi destekler.
Komut satırı tarafında öne çıkan iş akışı, özel ara katman eklentilerini paketlemektir. tyk bundle build, manifest ve ara katman dosyalarınızı ağ geçidinin yükleyebileceği imzalı bir pakete dönüştürür.
# Bildirgenizden ve ara katman dosyalarınızdan bir eklenti paketi oluşturun
tyk bundle build -o bundle.zip
Bunu CI içinde tekrarlanabilir hâle getirmek için paket çıktısını artifact olarak saklayabilirsiniz:
tyk bundle build -o bundle.zip
# Örneğin CI artifact adımı için:
test -f bundle.zip
En uygun kullanım: Özel kimlik doğrulama, dönüşüm veya middleware eklentileri geliştiren ekipler.
Sınırlamalar:
- CLI, tüm ağ geçidinin bildirimsel yapılandırmasından çok eklenti paketlemeye odaklanır.
- Tyk yönetiminin önemli bölümü Kontrol Paneli veya doğrudan Gateway API üzerinden gerçekleştirilir.
- Kontrol Paneli ücretli ürün tarafında yer alır.
KrakenD Community Edition: yapılandırma dosyasını tek doğruluk kaynağı yapın
KrakenD Community Edition, Apache 2.0 lisanslı, durumsuz ve yüksek performanslı bir API ağ geçididir. Veritabanı gerektirmemesi, onu Git ve CI tabanlı dağıtımlar için doğal bir seçenek hâline getirir.
Ağ geçidinin davranışı yapılandırma dosyası ile tanımlanır. krakend CLI'si ile yapılandırmayı doğrulayabilir ve ağ geçidini çalıştırabilirsiniz.
# Dağıtımdan önce yapılandırmayı doğrulayın ve lint çalıştırın
krakend check -c krakend.json --lint
# Ağ geçidini belirtilen yapılandırmayla başlatın
krakend run -c krakend.json
CI hattına aşağıdaki gibi bir doğrulama adımı ekleyin:
set -e
krakend check -c krakend.json --lint
krakend run -c krakend.json
Esnek Yapılandırma özelliğiyle (FC_ENABLE=1) büyük bir yapılandırmayı değişkenler ve şablon dosyalarıyla bölebilirsiniz. Bu yaklaşım, ortamlar arasında tekrar eden değerleri azaltır.
FC_ENABLE=1 krakend check -c krakend.json --lint
En uygun kullanım: Tek bir yapılandırma dosyasını doğruluk kaynağı olarak kullanan, bildirimsel ve durumsuz ağ geçidi iş akışları.
Sınırlamalar:
- Community Edition'da yerleşik kalıcılık veya yönetici arayüzü yoktur.
- Davranışı kontrol paneli üzerinden tıklayarak değil, yapılandırma ile tanımlarsınız.
- Bu yaklaşım IaC seven ekipler için avantaj, GUI odaklı ekipler için sürtünme yaratabilir.
Apache APISIX: çalışma zamanında dinamik yönlendirme
Apache APISIX, Apache 2.0 lisanslı bir Apache Yazılım Vakfı projesidir. Bu yönetişim modeli önemlidir: araç, tek bir satıcının sınırlı topluluk sürümü değil, bir vakıf projesidir.
APISIX iki farklı yönetim yüzeyi sunar:
- Yaşam döngüsü işlemleri için CLI
- Rotalar ve eklentiler için REST Yönetici API'si
CLI ile ağ geçidini başlatabilir, durdurabilir ve yeniden yükleyebilirsiniz. apisix reload, bağlantıları kesmeden yapılandırma değişikliklerini yüklemek için kullanılır.
# Kullanılabilir kontrol komutlarını görüntüleyin
apisix help
# Ağ geçidini başlatın
apisix start
# Yapılandırma değişikliğinden sonra yeniden yükleyin
apisix reload
Örnek operasyon akışı:
# 1. Yönetici API üzerinden rota veya eklenti güncellemesi yapın
# 2. Gerekirse yapılandırmayı yeniden yükleyin
apisix reload
En uygun kullanım: Çalışma zamanında rota ve eklenti değiştirmek isteyen, dinamik ve yüksek verimli yönlendirme senaryoları.
Sınırlamalar:
- Yönlendirme yapılandırması genellikle tek bir CLI komutuyla itilen deklaratif dosyada değil, Yönetici API'sinde bulunur.
- Git tabanlı iş akışı için Yönetici API çağrılarını betikleyebilir veya APISIX ADC gibi ek araçlar kullanabilirsiniz.
- Yönetici API'si varsayılan olarak
127.0.0.1üzerinde bağlıdır; üretim erişim modelini buna göre planlayın.
Gravitee: ağ geçidinin yanında yönetim katmanı
Gravitee'nin temel API Yönetimi platformu Apache 2.0 altında açık kaynaktır. Community Edition; çalışma zamanı ağ geçidini, REST yönetim API'sini ve yönetim konsolunu içerir.
Gravitee'de günlük yönetim çoğunlukla Yönetim REST API'si ve Konsol üzerinden yapılır. Kendi kendine barındırılan başlangıç noktası olarak Docker CLI kullanılabilir.
# Gravitee APIM ağ geçidi konteynerini çalıştırın
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest
Konteyner durumunu kontrol edin:
docker ps --filter "name=gravitee-gateway"
docker logs gravitee-gateway
GitHub'da, modüller arası işlemleri otomatikleştirmek için Yönetim API'sini saran topluluk destekli bir graviteeio-cli de bulunur. Ancak bu birinci taraf ikili değildir. Üretimde buna bağımlı olmadan önce sürüm geçmişini, bakım durumunu ve uyumluluğunu kontrol edin.
En uygun kullanım: Sadece proxy değil; ağ geçidi, konsol ve betiklenebilir yönetim API'sinden oluşan tam bir açık kaynak yönetim katmanı isteyen ekipler.
Sınırlamalar:
- Birinci taraf otomasyon yüzeyi tek bir kapsamlı CLI değil, REST Yönetim API'sidir.
- Topluluk CLI'si yardımcı olabilir, ancak bakım riskini ayrıca değerlendirmeniz gerekir.
- Olay tabanlı asenkron API'ler gibi bazı kurumsal özellikler ücretli sürümde bulunur.
Apidog'un yeri: neden açık kaynak listesinde değil?
Apidog açık kaynaklı değildir; bu nedenle yukarıdaki araçlarla aynı kategoride değerlendirilmemelidir. Ücretsiz katmanı bulunan ticari bir üründür.
Yukarıdaki araçlar ağ geçitleridir: trafik, rotalar ve eklentiler üzerinde çalışırlar. API şeması tasarlama, uç nokta testlerini yürütme, dokümantasyon üretme veya arka uç hazır değilken yanıt taklit etme gibi işler farklı araçlar gerektirir.
Bu ihtiyaçları ayrı araçlarla kurmak genellikle şunları içerir:
- Şema kontrolleri için Spectral
- Kod üretimi için
openapi-generator - Yanıt taklitleri için bir mock sunucusu
- Test çalıştırma için Newman
Apidog, tasarım, test, mock ve dokümantasyonu tek çalışma alanında birleştirir. apidog-cli ise bu iş akışları için terminal arayüzü sağlar.
# Apidog CLI'yi yükleyin ve kimlik doğrulayın
npm install -g apidog-cli
apidog login --with-token <TOKEN>
# CI içinde bir test senaryosu çalıştırın
# Başarısızlıkta sıfır olmayan çıkış kodu döndürür
apidog run
Örnek CI adımı:
set -e
apidog login --with-token "$APIDOG_TOKEN"
apidog run
CLI, agentHints.nextSteps içeren yapılandırılmış JSON çıktısı üretir. Bu yapı, CI süreçleri ve AI ajanı tabanlı iş akışları için kullanılabilir. API işlerini Claude Code veya benzeri araçlarla yönlendiriyorsanız, AI ajanlarınızdan ayrılmadan API yönetme rehberi bu yaklaşımı ele alır.
CLI ayrıca OpenAPI içe/dışa aktarma, senaryo çalıştırma ve mock yönlendirme işlemlerini destekler. Komut grupları için Apidog CLI kılavuzunun tamamına bakabilirsiniz.
Bunu kendi kendine barındırılan bir OSS ağ geçidinin yerine değil, API tasarımı ve test süreçlerini tamamlayan bir seçenek olarak düşünün.
Nasıl seçmeli?
| Araç | En iyi olduğu durum | Lisans | Açık kaynak mı? | CLI/komut |
|---|---|---|---|---|
| Kong Gateway OSS + decK | Kong için Git'te IaC yapılandırması | Apache 2.0 | Evet | deck gateway sync |
| Tyk | Özel eklenti paketleme, çoklu protokol | MPL 2.0 | Evet | tyk bundle build |
| KrakenD CE | Durumsuz, kod olarak yapılandırma ağ geçidi | Apache 2.0 | Evet | krakend run |
| Apache APISIX | Dinamik, yüksek verimli yönlendirme | Apache 2.0 | Evet, ASF projesi |
apisix start / apisix reload
|
| Gravitee | Tam OSS yönetim katmanı ve konsol | Apache 2.0 | Evet, çekirdek | Docker CLI / REST API |
| Apidog CLI | Tasarım, test, mock ve dokümantasyon | Freemium | Hayır | apidog run |
Yıldız sayısına göre değil, çalışma modelinize göre seçim yapın:
-
Zaten Kong kullanıyorsanız: Yapılandırmayı Git'e almak için
decKile başlayın. - Tek dosya ve durumsuz dağıtım istiyorsanız: KrakenD Community Edition'ı değerlendirin.
- Çalışma zamanında dinamik yönlendirme gerekiyorsa: Apache APISIX uygun olabilir.
- Konsol ve yönetim API'siyle daha geniş bir katman istiyorsanız: Gravitee'ye bakın.
- Özel eklentileri paketlemek önceliğinizse: Tyk'in bundle iş akışını kullanın.
Ticari platformları da içeren daha geniş değerlendirme için 2026 için en iyi API yönetim araçları yazısına bakabilirsiniz. API öncelikli bir mimari kuruyorsanız başsız API yönetimi yaklaşımı da yararlı bir çerçeve sunar.
Sonuç
CLI üzerinden açık kaynak API yönetimi olgunlaşmış durumda. Kong Gateway OSS + decK, Tyk, KrakenD CE, Apache APISIX ve Gravitee; kendi kendine barındırılabilen, terminalden yönetilebilen ve Git ile CI süreçlerine bağlanabilen seçenekler sunar.
Başlangıç için şu sırayı izleyin:
- Lisansı ve depo bakım durumunu doğrulayın.
- Yerel ortamda ağ geçidini çalıştırın.
- Yapılandırmayı Git'e alın.
- Doğrulama komutlarını CI'a ekleyin.
- Dağıtım veya senkronizasyonu onaylı değişikliklerden sonra otomatikleştirin.
Ağ geçitlerinin doğrudan çözmediği tasarım, test, mock ve dokümantasyon ihtiyaçları için entegre bir araç kullanabilirsiniz. Apidog'u indirin, hattınızda apidog run komutunu deneyin ve seçtiğiniz OSS ağ geçidiyle CI seviyesinde birleştirin.
Top comments (0)