Insomnia'yı CI ortamında çalıştırıyorsanız, inso'yu bilirsiniz. Kong'un açık kaynaklı Insomnia API istemcisinin komut satırı arkadaşıdır ve bir terminalden üç faydalı şey yapar: test paketlerini çalıştırma, istek koleksiyonlarını çalıştırma ve Spectral ile OpenAPI özelliklerini lintleme. Birçok ekip için bu yeterlidir. Diğerleri için sürtünme hızla ortaya çıkar.
Bu rehber, inso'nun aslında ne olduğunu, ekiplerin neden bir inso alternatifi aramaya başladığını ve yapmanız gereken işe bağlı olarak hangi araçların onu değiştirdiğini açıklıyor. Bazıları tam API platformlarıdır. Bazıları küçük, tek amaçlı çalıştırıcılardır. Hiçbiri mükemmel bir doğrudan ikame değildir, bu nedenle "en iyi insomnia cli alternatifi nedir" sorusunun dürüst cevabı "bugün inso'yu ne için kullandığınıza bağlıdır" olacaktır.
inso ne yapar ve sürtünme nerede başlar?
inso, çalışma dizininizdeki bir .insomnia dizininden (Insomnia'nın Git Senkronizasyonu tarafından oluşturulur) veya masaüstü uygulaması kuruluysa Insomnia uygulamasının veri dizininden okur. Özellikleri ve paketleri dosya yoluyla değil, adıyla referans alırsınız:
inso run test "API Test Paketim" --env "Hazırlık"
inso run collection "Smoke Testleri" --env "Hazırlık"
inso lint spec "Petstore Tasarım Belgesi"
inso export spec "Petstore Tasarım Belgesi" --output openapi.yaml
Kurulumu basittir. Homebrew (brew install inso), bir Docker imajı (docker pull kong/inso:latest) veya Windows, Linux ve macOS için doğrudan indirilebilir zip dosyaları. Stoplight OpenAPI linter'ı Spectral, inso lint spec'e güç verir. Bu lintleme gerçek bir güçtür ve geçiş yapmadan önce akılda tutulması gereken bir şeydir.
Peki neden bir inso alternatifi arayasınız? Birkaç tekrar eden neden:
- Insomnia uygulama veritabanına bağlılık. Test kaynağınız bir
.insomniadizini içinde veya uygulamanın veri klasöründe yaşar. Masaüstü uygulamasını kullanmıyorsanız, bu model geriye dönük hissettirir. - Ada dayalı referanslar. Paketler ve özellikler görünen adla referans alınır. GUI'de bir paketi yeniden adlandırırsanız, CI komutunuz sessizce bozulur. Adlar kararlı tanımlayıcılar değildir.
- Bulut hesabı olayı. Insomnia 8 (2023), gerçek tepkilere neden olan zorunlu bir bulut oturum açma hesabı tanıttı. O dönemde veri kaybı ve geçiş olayları da yaşandı. Mağdur olan ekipler, istek verilerini bir satıcı hesabına bağlamayan araçlar aramaya başladı.
- Lintleme ve testin ayrılması.
inso, özellik lintlemesini ve istek testini bir araya getirir. Sadece bunlardan birine ihtiyacınız varsa, diğerini yapmadan bunu yapan bir araç isteyebilirsiniz.
Eğer OpenAPI lintleme, inso'yu çalıştırmanızın ana nedeni ise, araçları değiştirmek size tasarruf ettiğinden daha pahalıya mal olabilir. Aşağıdaki çalıştırıcıların çoğu, Spectral tarzı stil rehberi kontrollerine değil, istekleri ve onaylamaları yürütmeye odaklanır. Okurken bu ayrımı aklınızda bulundurun.
Alternatiflere bir bakış
| Araç | Tip | Kaynak biçimi | Veri odaklı | Raporcular | Açık kaynak | En iyi için |
|---|---|---|---|---|---|---|
| Apidog CLI | Tam platform çalıştırıcısı | Apidog projesi / OpenAPI içe aktarma | Evet (-d CSV/JSON) |
CLI, HTML, JSON | Hayır (ücretsiz katman) | Tek platform: tasarım, mock, dokümanlar, test |
| Newman | Postman koleksiyon çalıştırıcısı | Postman koleksiyon JSON | Evet (-d CSV/JSON) |
CLI, HTML, JSON | Evet | Mevcut Postman koleksiyonları |
| Hoppscotch CLI | OSS koleksiyon çalıştırıcısı | Hoppscotch koleksiyon JSON / bulut kimliği | Evet (yineleme verileri CSV) | CLI, JUnit XML | Evet | Ücretsiz, kendi kendine barındırılabilir OSS işlem hatları |
| Step CI | Bildirimsel API testçisi | YAML / JSON iş akışı dosyaları | Sınırlı | CLI, JUnit | Evet | Özellik odaklı, kod olarak yapılandırma testleri |
| Hurl | Düz metin HTTP çalıştırıcısı | .hurl metin dosyaları |
Değişkenler aracılığıyla | CLI, JUnit, HTML | Evet | Hafif HTTP onaylamaları |
1. Apidog CLI (hepsi bir arada seçenek)
Apidog, tasarım, hata ayıklama, test, mock ve dokümantasyonu kapsayan hepsi bir arada bir API platformudur. Apidog CLI, test tarafını terminalinize ve CI/CD'nize getirir ve bu noktada doğrudan inso ile rekabet eder.
apidog run, komut satırından test senaryolarını ve koleksiyonlarını yürütür. -d (CSV veya JSON veri kümeleri) ile veri odaklı testleri, -e ile ortamları ve CLI, HTML ve JSON biçimlerinde raporcuları destekler. Ayrıca --upload-report ile bulut test raporlarını yükleyebilir, böylece sonuçlar sadece CI günlüklerinde kaybolmaz.
apidog run --access-token <token> -t <scenario-id> -e <env-id>
apidog run -t <scenario-id> -d ./users.csv -r html,cli
apidog run -t <scenario-id> --upload-report
Test çalıştırmalarının ötesinde, Apidog CLI, API kaynaklarını kod olarak yönetir: OpenAPI'yi içe aktarma ve uç noktalar, şemalar, ortamlar, dallar ve birleştirme istekleri ile terminalden çalışma. Bu dal-ve-kaynak-kod olarak modeli, .insomnia dizin modelinden daha çok Git-yerel bir iş akışına yakındır ve ekiplerin dikişsiz bir yığın yerine tek bir araç istediğinde Apidog'u seçmelerinin nedenidir.
Dürüstlük notu: Apidog CLI'nin bağımsız bir OpenAPI linter, stil rehberi, bölme, birleştirme veya paketleme komutu yoktur. Özellikleri içe aktarırken doğrular, ancak inso'nun Spectral ile yaptığı gibi lintleme yapmaz. Eğer terminal lintleme temel ihtiyacınız ise, bu gerçek bir eksikliktir ve inso (veya Redocly CLI) bu konuda avantajını korur. Apidog'un kazandığı yer entegrasyondur: tasarım, mock, dokümanlar ve test tek bir yerde yaşar, veri odaklı çalıştırmalar ve çok formatlı raporcular yerleşiktir.
Artıları
- Tasarım, mock, dokümanlar ve test için tek platform, bir araya getirilmiş ayrı araçlar değil
- Veri odaklı çalıştırmalar (
-d), üç raporcu biçimi, ortamlar, bulut raporları - Kaynaklar ve dallar CLI'den kod olarak yönetilir
Eksileri
- Bağımsız özellik linter'ı yok (içe aktarırken doğrular, Spectral gibi lintleme yapmaz)
- Tamamen açık kaynak yerine ücretsiz katman
Terminal çalıştırıcıları başa baş karşılaştırıyorsanız, Apidog CLI kapsamlı rehberi kurulumu adım adım anlatır ve Apidog CLI vs Newman ve Apidog CLI vs Postman CLI gibi doğrudan karşılaştırmalar mevcuttur. Otomasyona bağlamak için GitHub Actions rehberine bakın.
2. Newman (Postman CLI çalıştırıcısı)
Newman, Postman'ın açık kaynak komut satırı koleksiyon çalıştırıcısıdır. Ekibiniz zaten Postman kullanıyorsa, zaten oluşturduğunuz koleksiyonları çalıştırdığı için bu bariz bir inso cli alternatifidir.
newman run collection.json -e staging.json -d data.csv -r cli,html,json
Newman, -d ile veri odaklı yinelemeleri, -e ile ortam dosyalarını ve CLI, HTML ve JSON biçimlerinde raporcuları destekler. Olgun, iyi belgelenmiş ve CI örneklerinde yaygındır.
Artıları
- Mevcut Postman koleksiyonlarını yeniden düzenleme olmadan çalıştırır
- Açık kaynak, büyük topluluk, bol miktarda CI tarifi
- Sağlam raporcu ekosistemi
Eksileri
- Postman koleksiyon formatına ve senkronizasyon modeline bağlıdır
- Hiçbir OpenAPI lintleme özelliği yok
- Koleksiyonları düz özellik dosyaları olarak değil, Postman uygulamasında yönetirsiniz
Newman'ın nerede bittiğini ve bir platform çalıştırıcısının nerede başladığını yan yana görmek için, Apidog CLI vs Newman karşılaştırması raporcuları, veri odaklı çalıştırmaları ve bulut raporlamayı kapsar.
3. Hoppscotch CLI (açık kaynak çalıştırıcı)
Hoppscotch, Postman ve Insomnia alternatifi olarak konumlandırılmış açık kaynaklı bir API ekosistemidir (web, masaüstü, CLI ve kendi kendine barındırılabilir). CLI'si, @hoppscotch/cli, CI'de koleksiyonları çalıştırır.
Kurulum için Node.js v22 veya daha yenisi gerekir (Node 20 kullanıcıları CLI v0.26.0'da kalır):
npm i -g @hoppscotch/cli
hopp test ./collection.json -e ./env.json -d 100
hopp test <collection-id> --token <pat> --server https://hoppscotch.example.com
hopp test ./collection.json --reporter-junit ./report.xml
hopp test, bir koleksiyondaki her isteği özyinelemeli olarak çalıştırır, ön-istek ve test betiklerini (pw.test() paketleri, pw.expect() durumları) yürütür ve yanıtları doğrular. Herhangi bir onaylama başarısız olursa sıfır olmayan bir değerle çıkar. Bayraklar ortamları (-e), gecikmeyi (-d), kişisel erişim jetonlarını (--token), kendi kendine barındırılan sunucuları (--server), JUnit XML çıktısını (--reporter-junit) ve veri odaklı yinelemeleri (--iteration-count, --iteration-data) kapsar.
Artıları
- Tamamen açık kaynak ve kendi kendine barındırılabilir, zorunlu bir satıcı hesabı yok
- JUnit raporlama ve veri odaklı yinelemelerle gerçek ücretsiz OSS çalıştırıcısı
- Bulut veya kendi kendine barındırılan koleksiyon referansları
Eksileri
- Node v22+ gereksinimi eski CI imajlarını etkileyebilir
- Newman'dan daha küçük ekosistem
- OpenAPI lintleme özelliği yok
Açık kaynak yolunu düşünüyorsanız, Hoppscotch alternatifleri ve Postman vs Hoppscotch faydalı bağlam sağlar ve doğrudan bir Apidog CLI vs Hoppscotch CLI karşılaştırması vardır.
4. Step CI (bildirimsel seçenek)
Step CI farklı bir şekil alır. GUI'de oluşturulmuş bir koleksiyonu işaret etmek yerine, API testlerini deponuzda yaşayan bildirimsel YAML veya JSON iş akışı dosyaları olarak yazarsınız. Testler bir yapılandırmadır ve diğer kodlar gibi çekme isteklerinde incelenir.
version: "1.1"
name: Durum kontrolü
tests:
health:
steps:
- name: GET sağlık
http:
url: https://api.example.com/health
method: GET
check:
status: 200
inso'nun ada dayalı referanslarını kırılgan buluyorsanız bu çekicidir. Burada, test tanımı dosyadır ve dosya yolu tanımlayıcıdır. Step CI yerel olarak ve CI'de çalışır ve JUnit çıktısı verir.
Artıları
- Testler deponuzdaki bildirimsel dosyalardır, PR'larda incelenebilir
- Uygulama veritabanı yok, GUI bağımlılığı yok
- Özellik odaklı ekipler için iyi bir uyum
Eksileri
- Anlık hata ayıklama için GUI destekli bir çalıştırıcıdan daha az etkileşimli
- Daha küçük topluluk; daha fazlasını elle yazarsınız
- Veri odaklı destek, Newman veya Apidog'dan daha sınırlıdır
Step CI, test tanımlarının bir aracın veritabanı yerine uygulama kodlarının yanında yaşamasını isteyen ekipler için özel olarak temiz bir insomnia cli yerine geçen bir araçtır.
5. Hurl (düz metin seçeneği)
Hurl buradaki en minimal giriştir. HTTP isteklerini ve onaylamaları düz .hurl metin dosyalarına yazarsınız ve Hurl bunları çalıştırır. GUI yok, veritabanı yok, hesap yok, sadece metin.
GET https://api.example.com/users/1
HTTP 200
[Asserts]
jsonpath "$.id" == 1
jsonpath "$.name" exists
hurl --test users.hurl ile çalıştırın. İstekleri zincirler, aralarında değişkenleri yakalar ve JUnit ve HTML raporlarını destekler. Smoke testler ve sözleşme kontrolleri için hızlıdır ve neredeyse sıfır yapılandırma gerektirir.
Artıları
- Son derece basit düz metin biçimi, versiyon kontrolü temizdir
- Uygulama yok, hesap yok, CI'de küçük ayak izi
- Yakalanan değişkenlerle zincirlenmiş istekler
Eksileri
- Tam bir test çerçevesi değil; karmaşık senaryolar uzun olur
- Koleksiyon GUI'si yok, bu nedenle CLI kullanmayanlar için daha az erişilebilir
- OpenAPI lintleme özelliği yok
Nasıl seçilir?
Markaya göre değil, işe göre seçin:
- Tasarım, mock, dokümanlar ve test için tek bir araç istiyorsunuz. Apidog CLI'yi kullanın. En geniş alternatiftir ve burada kaynakları ve dalları kod olarak ele alan tek araçtır.
- Zaten Postman koleksiyonlarınız var. Newman'ı kullanın. Sahip olduğunuzu yeniden inşa etmeyin.
- Tamamen açık kaynak ve kendi kendine barındırılabilir istiyorsunuz. Hoppscotch CLI'yi veya daha hafif bir şey istiyorsanız Hurl'ü kullanın.
- Testleri deponuzda bildirimsel dosyalar olarak istiyorsunuz. Step CI'yi kullanın.
- Temel olarak
inso lint specçalıştırıyorsunuz. Geçiş yapmadan önce iki kez düşünün. Spectral lintleme,inso'nun gerçek gücüdür ve buradaki çoğu çalıştırıcı onu değiştirmez. Bir çalıştırıcıyı doğrudan Spectral ile eşleştirin veya özel bir lintleme CLI'sına bakın.
Sadece inso'dan değil, daha geniş Insomnia ekosisteminden geçiş yapıyorsanız, şunları okumaya değer: Apidog vs Insomnia, en iyi Insomnia uygulama alternatifleri ve Insomnia veri kaybı ve geçişi için kurtarma rehberi. Özellikle CLI'dan CLI'ye geçiş için inso'dan Apidog CLI'ye geçiş bölümüne bakın.
