Manajemen API dulu berarti konsol GUI dan tagihan vendor. Itu masih ada, tetapi sebagian besar pekerjaan nyata sekarang dilakukan dari terminal. Anda menentukan rute, plugin, dan batas tarif dalam file konfigurasi, menerapkannya ke Git, dan membiarkan CLI mendorongnya ke gateway. Tidak perlu mengklik dasbor, tidak ada perbedaan antara yang diterapkan dan yang ditinjau.
Aspek sumber terbuka penting di sini. Jika Anda menjalankan gateway Anda sendiri, lisensi menentukan apa yang dapat Anda host sendiri, forked, dan kirim tanpa membayar per pengguna. Sebagian besar alat di bawah ini adalah Apache 2.0 atau MPL 2.0, yang berarti sumbernya tersedia, Anda dapat menjalankannya di mana saja, dan tidak ada biaya per pengguna yang melekat. Itu adalah sudut pandang yang berbeda dari memilih biner terkecil; di sini pertanyaannya adalah lisensi, hosting mandiri, dan seberapa aktif repositori GitHub.
Ini adalah daftar gateway sumber terbuka asli dengan cerita baris perintah yang nyata: Kong Gateway OSS dengan decK, Tyk, KrakenD Community Edition, Apache APISIX, dan Gravitee. Untuk setiap satu Anda akan mendapatkan lisensi, apa yang sebenarnya dilakukan CLI, dan perintah instal-dan-jalankan nyata yang dapat Anda tempel. Jika Anda menginginkan bidang yang lebih luas, rangkuman alat manajemen API sumber terbuka mencakup platform; bagian ini adalah potongan utamanya yang berfokus pada terminal. Teks lisensi Apache 2.0 resmi patut dibaca sekilas jika Anda belum pernah membaca ketentuan yang Anda gunakan.
tombol
Satu catatan jujur di awal. Apidog muncul di akhir, tetapi bukan sebagai entri sumber terbuka, karena memang bukan itu. Ini adalah produk komersial dengan tingkatan gratis. Saya akan menjelaskan di mana posisinya tanpa berpura-pura menjadi sesuatu yang bukan.
Apa yang membuat alat CLI “sumber terbuka” untuk manajemen API
Tiga hal membedakan opsi sumber terbuka nyata dari uji coba gratis dengan hitungan mundur.
Lisensi. Cari Apache 2.0, MIT, atau MPL 2.0 pada gateway inti, bukan hanya SDK klien. Apache 2.0 memungkinkan Anda melakukan hosting mandiri dan memodifikasi secara bebas. MPL 2.0 (pilihan Tyk) adalah copyleft tingkat file; Anda dapat menggabungkannya dengan kode proprietary selama file MPL tetap terbuka. Apa pun yang diberi label “source-available” atau BSL bukanlah hal yang sama, jadi bacalah file LICENSE sebenarnya di repo.
Hosting Mandiri. Gateway berjalan di infrastruktur Anda tanpa server lisensi yang memanggil pulang. Anda mengontrol bidang data. Jika “edisi komunitas” cacat sampai menjadi demo, itu tidak dihitung.
Repo yang dikelola dan CLI yang berfungsi. Periksa bintang GitHub, tetapi periksa riwayat komit lebih jauh. Gateway yang dapat Anda konfigurasikan secara deklaratif dari baris perintah, versi di Git, dan jalankan di CI adalah inti dari daftar ini. Untuk konsep manajemen umum di balik semua ini, lihat apa yang sebenarnya dicakup oleh manajemen API.
Kong Gateway OSS (dengan decK)
Kong Gateway OSS adalah build Kong berlisensi Apache 2.0. Kong Inc. terus mengirimkan build OSS untuk orang-orang yang hanya menginginkan kode Apache 2.0, terpisah dari edisi Enterprise. Gateway itu sendiri dikonfigurasi melalui API Adminnya, tetapi alat yang sebenarnya Anda gunakan adalah decK.
decK adalah CLI konfigurasi deklaratif Kong. Anda membuang status gateway yang sedang berjalan ke file YAML, mengeditnya, dan menyinkronkannya kembali. Ini pertama-tama membuat perbedaan, sehingga Anda melihat persis apa yang akan berubah sebelum berubah, yang membuat perbedaan konfigurasi terlihat daripada tersembunyi.
# Ekspor konfigurasi Kong saat ini ke file
deck gateway dump -o kong.yaml
# Dorong konfigurasi deklaratif kembali ke gateway
deck gateway sync kong.yaml
Terbaik untuk: infrastruktur-sebagai-kode untuk Kong. Jika Anda sudah menjalankan Kong dan menginginkan rute dan plugin Anda di Git dengan tinjauan dan CI, decK adalah jawabannya. Batasan jujur: ini spesifik Kong, dan mengelola konfigurasi daripada melakukan dokumen atau pengujian. Anda juga menjalankan tumpukan penuh Kong, yang lebih berat daripada gateway satu-biner.
Tyk
Gateway Tyk adalah sumber terbuka di bawah Mozilla Public License 2.0. MPL adalah copyleft tingkat file: perubahan pada file berlisensi MPL harus tetap terbuka, tetapi Anda dapat menggabungkan gateway dengan plugin proprietary selama itu berada di file terpisah. Gateway inti, yang ditulis dalam Go, mendukung REST, GraphQL, TCP, dan gRPC.
Bagian baris perintah yang paling sering digunakan orang adalah bundler, yang dikirimkan di dalam biner gateway sejak v2.8. Ini mengemas plugin middleware kustom Anda menjadi bundel yang ditandatangani yang dapat dimuat oleh gateway.
# Bangun bundel plugin dari manifes dan file middleware Anda
tyk bundle build -o bundle.zip
Terbaik untuk: tim yang ingin memperluas gateway dengan otentikasi kustom atau plugin transformasi dan membutuhkan cara yang dapat diulang untuk mengemasnya. Batasan jujur: CLI terbatas pada bundling, bukan konfigurasi deklaratif penuh dari seluruh gateway; banyak manajemen Tyk masih berjalan melalui Dashboard-nya (yang merupakan bagian berbayar) atau langsung melalui API Gateway.
KrakenD Community Edition
KrakenD adalah gateway tanpa status, berkinerja tinggi, dan Community Edition mengirimkan set fitur inti penuh di bawah Apache 2.0. Tanpa status adalah bagian yang menarik: tidak ada basis data. Gateway sepenuhnya ditentukan oleh file konfigurasi, yang membuatnya cocok secara alami untuk Git dan CI.
Biner krakend adalah CLI. Anda memvalidasi konfigurasi dengan check dan menjalankan gateway dengan run. Karena ini adalah satu biner Go, instalasinya hanya satu unduhan.
# Validasi dan lint konfigurasi Anda sebelum menerapkan
krakend check -c krakend.json --lint
# Jalankan gateway dengan konfigurasi itu
krakend run -c krakend.json
Fitur Konfigurasi Fleksibel (FC_ENABLE=1) memungkinkan Anda membagi satu konfigurasi besar menjadi file template dengan variabel, sehingga Anda dapat menjaga lingkungan tetap DRY. Terbaik untuk: gateway deklaratif, tanpa status di mana file konfigurasi adalah satu-satunya sumber kebenaran. Batasan jujur: tidak ada persistensi bawaan atau UI admin di CE; Anda menyusun perilaku dalam konfigurasi daripada mengklik tombol, yang merupakan fitur jika Anda menyukai IaC dan gesekan jika tidak.
Apache APISIX
Apache APISIX adalah proyek Apache Software Foundation tingkat atas, berlisensi Apache 2.0. Tata kelola itu penting untuk pertanyaan sumber terbuka: ini adalah proyek yayasan, bukan edisi komunitas vendor tunggal, jadi build OSS adalah proyek nyata daripada teaser yang disederhanakan.
APISIX memiliki CLI kontrol untuk operasi siklus hidup, dan REST Admin API (terikat ke 127.0.0.1 secara default) untuk mengelola rute dan plugin. CLI memulai, menghentikan, dan memuat ulang gateway; apisix reload mengambil perubahan konfigurasi tanpa menjatuhkan koneksi.
# Lihat perintah kontrol yang tersedia
apisix help
# Mulai gateway, lalu hot-reload setelah perubahan konfigurasi
apisix start
apisix reload
Terbaik untuk: perutean dinamis, throughput tinggi di mana Anda ingin mengubah rute dan plugin saat runtime tanpa restart, didorong oleh Admin API. Batasan jujur: konfigurasi perutean berada di Admin API daripada satu dorongan CLI deklaratif, sehingga alur kerja “konfigurasi di Git” Anda biasanya berarti membuat skrip panggilan Admin API atau menambahkan alat seperti ADC APISIX di atasnya.
Gravitee
Platform manajemen API inti Gravitee adalah sumber terbuka di bawah Apache 2.0. Ini lebih dari sekadar gateway: Community Edition mencakup APIM Gateway (runtime), APIM API (antarmuka manajemen REST), dan APIM Console. Fitur Enterprise seperti API asinkron event-native berada di edisi berbayar, tetapi inti yang berpusat pada REST adalah OSS asli yang dapat Anda host sendiri.
Kisah baris perintah membutuhkan peringatan jujur. Admin harian Gravitee berjalan melalui REST Management API dan Console-nya, dan instalasi mandiri resmi sering kali didorong dengan Docker CLI. Ada graviteeio-cli yang dikelola komunitas di GitHub yang membungkus Management API untuk mengotomatiskan tindakan di seluruh modul, tetapi ini adalah alat komunitas, bukan biner pihak pertama, jadi perlakukan status pemeliharaannya seperti Anda memperlakukan proyek komunitas apa pun sebelum Anda bergantung padanya.
# Jalankan kontainer gateway Gravitee APIM (self-hosted, OSS)
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest
Terbaik untuk: tim yang menginginkan lapisan manajemen sumber terbuka penuh (gateway ditambah konsol ditambah API manajemen untuk scripting) daripada hanya proksi. Batasan jujur: permukaan otomatisasi pihak pertama adalah REST Management API, bukan CLI tunggal yang dipoles; CLI komunitas mengisi celah tersebut tetapi Anda mengambil risiko pemeliharaannya.
Di mana Apidog cocok (dan mengapa tidak ada di daftar sumber terbuka)
Apidog bukan sumber terbuka, jadi tidak seharusnya masuk sebagai entri di atas. Ini adalah produk komersial dengan tingkatan gratis, dan saya akan menyesatkan Anda jika menempatkannya di bawah Apache 2.0.
Berikut adalah penjelasan jujur. Alat di atas adalah gateway; mereka mengelola lalu lintas, rute, dan plugin. Mereka tidak merancang skema API Anda, menjalankan pengujian titik akhir Anda, membuat dokumen Anda, atau memalsukan respons sebelum backend ada. Menggabungkan pekerjaan-pekerjaan itu biasanya berarti Spectral ditambah openapi-generator ditambah server mock ditambah Newman, masing-masing dengan konfigurasinya sendiri. Apidog melipat desain, pengujian, mocking, dan dokumen menjadi satu ruang kerja, dan apidog-cli memberi Anda jalur terminal untuk semuanya.
# Instal dan otentikasi Apidog CLI
npm install -g apidog-cli
apidog login --with-token <TOKEN>
# Jalankan skenario pengujian di CI (keluar non-nol jika gagal)
apidog run
CLI mengeluarkan JSON terstruktur dengan agentHints.nextSteps, sehingga dapat dimasukkan dengan rapi ke dalam CI dan alur kerja agen AI; jika Anda merutekan pekerjaan API melalui Claude Code atau yang serupa, mengelola API tanpa meninggalkan agen AI Anda mencakup pola tersebut. Ini juga mendukung impor dan ekspor OpenAPI, menjalankan skenario, dan mendorong mock dari baris perintah. Panduan lengkap Apidog CLI membahas grup perintah. Anggap saja sebagai opsi tingkatan gratis terintegrasi di samping gateway OSS yang dihosting sendiri, bukan pengganti.
Cara memilih
| Alat | Terbaik untuk | Lisensi | Sumber terbuka? | CLI/perintah |
|---|---|---|---|---|
| Kong Gateway OSS + decK | Konfigurasi IaC untuk Kong di Git | Apache 2.0 | Ya | deck gateway sync |
| Tyk | Bundling plugin kustom, multi-protokol | MPL 2.0 | Ya | tyk bundle build |
| KrakenD CE | Gateway tanpa status, konfigurasi-sebagai-kode | Apache 2.0 | Ya | krakend run |
| Apache APISIX | Perutean dinamis throughput tinggi | Apache 2.0 | Ya (proyek ASF) | apisix start/reload |
| Gravitee | Lapisan manajemen OSS penuh + konsol | Apache 2.0 | Ya (inti) | Docker CLI / REST API |
| Apidog CLI | Desain + uji + mock + dokumen dalam satu | Freemium | Tidak | apidog run |
Pilih berdasarkan alur kerja, bukan jumlah bintang. Jika Anda sudah menjalankan Kong, decK adalah kemenangan tercepat. Jika Anda menginginkan gateway tanpa status yang ditentukan sepenuhnya oleh file, KrakenD cocok. APISIX menang pada perubahan perutean dinamis, runtime; Gravitee memberi Anda seluruh lapisan manajemen dengan konsol. Untuk perbandingan yang lebih luas termasuk platform komersial, lihat alat manajemen API terbaik untuk tahun 2026 dan sudut manajemen API tanpa kepala jika Anda membangun tumpukan API-first.
Kesimpulan
Manajemen API sumber terbuka dari CLI sudah matang. Kong Gateway OSS dengan decK, Tyk, KrakenD CE, Apache APISIX, dan Gravitee semuanya Apache 2.0 atau MPL 2.0, semuanya dapat dihosting sendiri, dan semuanya dapat dikendalikan dari terminal, yang berarti Git, tinjauan, dan CI alih-alih mengklik dasbor. Pilih yang modelnya sesuai dengan cara Anda menerapkan.
Untuk desain, pengujian, mocking, dan dokumen yang tidak ditangani oleh gateway, alat terintegrasi mengisi celah tersebut. Unduh Apidog dan jalankan apidog run di pipeline Anda untuk melihat jalur CLI, lalu sambungkan ke CI di samping gateway OSS mana pun yang Anda gunakan.
