API yönetimi eskiden bir GUI konsolu ve bir satıcı faturası anlamına gelirdi. Bu hala varlığını sürdürüyor, ancak gerçek işlerin çoğu artık terminalden yapılıyor. Rotaları, eklentileri ve hız sınırlarını bir yapılandırma dosyasında tanımlar, Git'e kaydedersiniz ve bir CLI'nin bunu ağ geçidine aktarmasına izin verirsiniz. Bir kontrol panelinde tıklama yok, dağıtılan ile gözden geçirilen arasında sapma yok.
Açık kaynak açısı burada önemlidir. Kendi ağ geçidinizi çalıştırırsanız, lisans, koltuk başına ödeme yapmadan neleri barındırabileceğinizi, çatallayabileceğinizi ve gönderebileceğinizi belirler. Aşağıdaki araçların çoğu Apache 2.0 veya MPL 2.0'dır; bu, kaynak kodun mevcut olduğu, her yerde çalıştırabileceğiniz ve kullanıcı başına maliyetin olmadığı anlamına gelir. Bu, en küçük ikiliyi seçmekten farklı bir bakış açısıdır; burada sorular lisans, kendi kendine barındırma ve GitHub deposunun ne kadar aktif olduğudur.
Bu, gerçek bir komut satırı geçmişine sahip, gerçekten açık kaynaklı ağ geçitlerinin bir listesidir: decK'li Kong Gateway OSS, Tyk, KrakenD Community Edition, Apache APISIX ve Gravitee. Her biri için lisansını, CLI'nin gerçekte ne yaptığını ve yapıştırabileceğiniz gerçek bir yükle-çalıştır komutunu bulacaksınız. Daha geniş alanı istiyorsanız, açık kaynak API yönetim araçları özeti platformları kapsar; bu parça ise bunun terminal öncelikli halidir. Güvendiğiniz terimleri daha önce hiç okumadıysanız, resmi Apache 2.0 lisans metnine göz atmaya değer.
Öncelikle dürüst bir not. Apidog en sonda görünür, ancak açık kaynaklı bir giriş olarak değil, çünkü açık kaynaklı değildir. Ücretsiz katmanı olan ticari bir üründür. Olmadığı bir şeymiş gibi davranmadan nerede durduğunu açıklayacağım.
Bir CLI aracını API yönetimi için "açık kaynak" yapan nedir?
Üç şey, gerçek bir açık kaynak seçeneğini geri sayımlı ücretsiz bir denemeden ayırır.
Lisans. Sadece istemci SDK'larında değil, çekirdek ağ geçidinde Apache 2.0, MIT veya MPL 2.0 arayın. Apache 2.0, serbestçe kendi kendine barındırmanıza ve değiştirmenize olanak tanır. MPL 2.0 (Tyk'ın tercihi) dosya düzeyinde copyleft'tir; MPL dosyaları açık kaldığı sürece bunu özel kodla birleştirebilirsiniz. "Kaynak kodlu" veya BSL etiketli herhangi bir şey aynı şey değildir, bu nedenle depodaki gerçek LİSANS dosyasını okuyun.
Kendi kendine barındırma. Ağ geçidi, ana sunucuya bağlanmayan bir lisans sunucusu olmadan altyapınızda çalışır. Veri düzlemini siz kontrol edersiniz. "Topluluk sürümü" bir demo noktasına kadar sakatlanmışsa, sayılmaz.
Bakımı yapılan bir depo ve çalışan bir CLI. GitHub yıldızlarını kontrol edin, ancak commit geçmişini daha çok kontrol edin. Komut satırından bildirimsel olarak yapılandırabileceğiniz, Git'te sürümleyebileceğiniz ve CI'da çalıştırabileceğiniz bir ağ geçidi bu listenin tüm amacıdır. Tüm bunların arkasındaki genel yönetim kavramları için API yönetiminin gerçekte neleri kapsadığını görün.
Kong Gateway OSS (decK ile)
Kong Gateway OSS, Kong'un Apache 2.0 lisanslı sürümüdür. Kong Inc., Enterprise sürümünden ayrı olarak, yalnızca Apache 2.0 kodunu isteyenler için OSS sürümlerini yayınlamaya devam ediyor. Ağ geçidinin kendisi Yönetici API'si aracılığıyla yapılandırılır, ancak aslında içinde yaşadığınız araç decK'tir.
decK, Kong'un bildirimsel yapılandırma CLI'sıdır. Çalışan ağ geçidinin durumunu bir YAML dosyasına dökersiniz, düzenlersiniz ve geri senkronize edersiniz. İlk önce farklılıkları gösterir, böylece değişmeden önce tam olarak neyin değişeceğini görürsünüz, bu da yapılandırma kaymasının sessiz olmak yerine görünür olmasını sağlar.
# Mevcut Kong yapılandırmasını bir dosyaya aktar
deck gateway dump -o kong.yaml
# Bildirimsel bir yapılandırmayı ağ geçidine geri aktar
deck gateway sync kong.yaml
En iyi olduğu durum: Kong için kod olarak altyapı. Zaten Kong kullanıyorsanız ve rotalarınızı ve eklentilerinizi inceleme ve CI ile Git'te istiyorsanız, decK cevaptır. Dürüst sınırlamalar: Kong'a özgüdür ve belgeleri veya testleri yapmak yerine yapılandırmayı yönetir. Ayrıca Kong'un tek bir ikili ağ geçidinden daha ağır olan tüm yığınını çalıştırıyorsunuz.
Tyk
Tyk'ın ağ geçidi, Mozilla Public License 2.0 altında açık kaynaktır. MPL dosya düzeyinde copyleft'tir: MPL lisanslı dosyalardaki değişikliklerin açık kalması gerekir, ancak bu eklentiler ayrı dosyalarda yaşadığı sürece ağ geçidini tescilli eklentilerle paketleyebilirsiniz. Go ile yazılmış çekirdek ağ geçidi, REST, GraphQL, TCP ve gRPC'yi destekler.
Çoğu kişinin kullandığı komut satırı parçası, v2.8'den beri ağ geçidi ikilisinde bulunan paketleyicidir. Özel ara katman eklentilerinizi, ağ geçidinin yükleyebileceği imzalı bir pakette birleştirir.
# Bildirgenizden ve ara katman dosyalarınızdan bir eklenti paketi oluşturun
tyk bundle build -o bundle.zip
En iyi olduğu durum: Ağ geçidini özel kimlik doğrulama veya dönüşüm eklentileriyle genişletmek isteyen ve bunları paketlemenin tekrarlanabilir bir yoluna ihtiyaç duyan ekipler. Dürüst sınırlamalar: CLI, tüm ağ geçidinin tam bildirimsel yapılandırması yerine paketlemeye odaklıdır; Tyk yönetiminin çoğu hala Kontrol Paneli (ücretli kısım) veya doğrudan Ağ Geçidi API'si aracılığıyla çalışır.
KrakenD Community Edition
KrakenD, durumsuz, yüksek performanslı bir ağ geçididir ve Community Edition, Apache 2.0 altında tam çekirdek özellik setini sunar. Durumsuzluk ilginç kısım: veritabanı yok. Ağ geçidi tamamen bir yapılandırma dosyası tarafından tanımlanır, bu da onu Git ve CI için doğal bir uyum haline getirir.
krakend ikilisi CLI'dir. Yapılandırmaları check ile doğrular ve ağ geçidini run ile çalıştırırsınız. Tek bir Go ikilisi olduğu için kurulum tek bir indirmedir.
# Dağıtmadan önce yapılandırmanızı doğrulayın ve kontrol edin
krakend check -c krakend.json --lint
# Ağ geçidini o yapılandırma ile çalıştırın
krakend run -c krakend.json
Esnek Yapılandırma özelliği (FC_ENABLE=1), tek bir büyük yapılandırmayı değişkenlerle şablonlu dosyalara bölmenize olanak tanır, böylece ortamları DRY tutabilirsiniz. En iyi olduğu durum: Yapılandırma dosyasının tek doğruluk kaynağı olduğu bildirimsel, durumsuz ağ geçitleri. Dürüst sınırlamalar: CE'de yerleşik kalıcılık veya yönetici kullanıcı arayüzü yok; davranışı yapılandırmada oluşturursunuz, geçiş düğmelerini tıklamak yerine, bu IaC'yi seviyorsanız bir özellik, sevmiyorsanız bir sürtünmedir.
Apache APISIX
Apache APISIX, Apache 2.0 lisanslı üst düzey bir Apache Yazılım Vakfı projesidir. Bu yönetim, açık kaynak sorunu için önemlidir: tek bir satıcının topluluk sürümü değil, bir vakıf projesidir, bu nedenle OSS yapısı, kırpılmış bir teaser'dan ziyade gerçek projedir.
APISIX, yaşam döngüsü operasyonları için bir kontrol CLI'sına ve rotaları ve eklentileri yönetmek için bir REST Yönetici API'sine (varsayılan olarak 127.0.0.1'e bağlı) sahiptir. CLI ağ geçidini başlatır, durdurur ve yeniden yükler; apisix reload bağlantıları kesmeden yapılandırma değişikliklerini alır.
# Mevcut kontrol komutlarını görün
apisix help
# Ağ geçidini başlatın, ardından bir yapılandırma değişikliğinden sonra anında yeniden yükleyin
apisix start
apisix reload
En iyi olduğu durum: Yeniden başlatmaya gerek kalmadan çalışma zamanında rotaları ve eklentileri değiştirmek istediğiniz, Yönetici API'si tarafından yönlendirilen dinamik, yüksek verimli yönlendirme. Dürüst sınırlamalar: Yönlendirme yapılandırması, tek bir bildirimsel CLI itmesi yerine Yönetici API'sinde bulunur, bu nedenle "Git'teki yapılandırma" iş akışınız genellikle Yönetici API çağrılarını betiklemeyi veya üzerine APISIX'in ADC'si gibi bir araç eklemeyi gerektirir.
Gravitee
Gravitee'nin temel API Yönetimi platformu, Apache 2.0 altında açık kaynaktır. Bu bir ağ geçidinden fazlasıdır: Community Edition, APIM Ağ Geçidi (çalışma zamanı), APIM API (bir REST yönetim arayüzü) ve APIM Konsolunu içerir. Olay tabanlı asenkron API'ler gibi kurumsal özellikler ücretli sürümde bulunur, ancak REST merkezli çekirdek, kendi kendine barındırabileceğiniz gerçek OSS'dir.
Komut satırı hikayesi dürüst bir uyarı gerektiriyor. Gravitee'nin günlük yönetimi, Yönetim REST API'si ve Konsolu aracılığıyla yapılır ve resmi kendi kendine barındırılan kurulum genellikle Docker CLI ile çalıştırılır. GitHub'da modüller arası eylemleri otomatikleştirmek için Yönetim API'sini saran, topluluk tarafından bakımı yapılan bir graviteeio-cli vardır, ancak bu bir topluluk aracıdır, birinci taraf ikili değil, bu nedenle bağımlı olmadan önce bakım durumunu herhangi bir topluluk projesine davrandığınız gibi değerlendirmelisiniz.
# Gravitee APIM ağ geçidi konteynerini çalıştırın (kendi kendine barındırılan, OSS)
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest
En iyi olduğu durum: Sadece bir proxy yerine tam bir açık kaynak yönetim katmanı (ağ geçidi artı konsol artı betiklenecek bir yönetim API'si) isteyen ekipler. Dürüst sınırlamalar: birinci taraf otomasyon yüzeyi cilalı tek bir CLI değil, REST Yönetim API'sidir; topluluk CLI boşluğu doldurur ancak bakım riskini üstleniyorsunuz.
Apidog'un yeri (ve neden açık kaynak listesinde olmadığı)
Apidog açık kaynaklı değildir, bu yüzden yukarıdaki listeye ait değildir. Ücretsiz katmanı olan ticari bir üründür ve onu Apache 2.0 altında göstermem sizi yanıltırdı.
Yine de dürüst tanıtım burada. Yukarıdaki araçlar ağ geçitleridir; trafiği, rotaları ve eklentileri yönetirler. API şemanızı tasarlamazlar, uç nokta testlerinizi çalıştırmazlar, belgelerinizi oluşturmazlar veya arka uç mevcut olmadan yanıtları taklit etmezler. Bu işleri bir araya getirmek genellikle Spectral artı openapi-generator artı bir taklit sunucusu artı Newman anlamına gelir, her birinin kendi yapılandırması vardır. Apidog tasarımı, testi, taklidi ve belgeleri tek bir çalışma alanına birleştirir ve apidog-cli tüm bunlara bir terminal yolu sunar.
# Apidog CLI'yi yükle ve kimlik doğrula
npm install -g apidog-cli
apidog login --with-token <TOKEN>
# CI'da bir test senaryosu çalıştır (başarısız olursa sıfır olmayan bir çıkış kodu döndürür)
apidog run
CLI, agentHints.nextSteps ile yapılandırılmış JSON çıktısı verir, bu nedenle CI'ye ve AI-agent iş akışlarına temiz bir şekilde düşer; API çalışmalarını Claude Code veya benzeri aracılığıyla yönlendiriyorsanız, AI ajanlarınızdan ayrılmadan API'leri yönetme bu deseni kapsar. Ayrıca OpenAPI'yi içe ve dışa aktarmayı, senaryoları çalıştırmayı ve komut satırından taklitleri yönlendirmeyi de destekler. Apidog CLI kılavuzunun tamamı komut gruplarını adım adım açıklar. Bunu, kendi kendine barındırılan bir OSS ağ geçidinin yerine değil, onun yanında entegre ücretsiz katman seçeneği 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/reload |
| Gravitee | Tam OSS yönetim katmanı + konsol | Apache 2.0 | Evet (çekirdek) | Docker CLI / REST API |
| Apidog CLI | Tasarım + test + taklit + belgeler tek bir yerde | Freemium | Hayır | apidog run |
Yıldız sayısına göre değil, iş akışına göre seçin. Zaten Kong kullanıyorsanız, decK en hızlı kazançtır. Tamamen bir dosya tarafından tanımlanan durumsuz bir ağ geçidi istiyorsanız, KrakenD uyar. APISIX, dinamik, çalışma zamanı yönlendirme değişikliklerinde kazanır; Gravitee, bir konsolla birlikte tüm bir yönetim katmanı sunar. Ticari platformları içeren daha geniş karşılaştırma için, 2026 için en iyi API yönetim araçlarına ve API öncelikli bir yığın oluşturuyorsanız başsız API yönetimi açısına bakın.
Sonuç
CLI'dan açık kaynak API yönetimi olgunlaşmıştır. decK'li Kong Gateway OSS, Tyk, KrakenD CE, Apache APISIX ve Gravitee'nin hepsi Apache 2.0 veya MPL 2.0 lisanslı, hepsi kendi kendine barındırılabilir ve hepsi terminalden kontrol edilebilir, bu da kontrol paneline tıklamak yerine Git, inceleme ve CI anlamına gelir. Dağıtım modelinize uyanı seçin.
Ağ geçitlerinin yönetmediği tasarım, test, taklit ve belgeler için entegre bir araç bu boşluğu doldurur. Apidog'u indirin ve CLI yolunu görmek için hattınızda apidog run komutunu çalıştırın, ardından hangi OSS ağ geçidine karar verirseniz verin onu CI'ye bağlayın.
