Alat CLI Ringan Terbaik untuk Pengujian API

Sebagian besar alat pengujian API mengharuskan Anda membuka jendela, masuk, dan mengklik di sekitar ruang kerja sebelum Anda dapat mengirim satu permintaan. Itu baik-baik saja untuk pandangan pertama. Itu tidak cocok untuk terminal, di mana Anda ingin mengetik satu baris, membaca respons, dan melanjutkan. Alat baris perintah ringan membalik urutan: alat menyingkir, dan permintaan adalah seluruh interaksi.

Ringan di sini berarti sesuatu yang spesifik. Instalasi kecil, seringkali biner tunggal atau `npx` cepat. Startup cepat, sehingga memanggil endpoint terasa instan. Sedikit atau tanpa konfigurasi untuk menjalankan permintaan pertama. Output yang mengutamakan terminal yang dapat Anda salurkan ke `jq` atau grep. Ini adalah pertanyaan yang berbeda dari “alat mana yang sumber terbuka” atau “mana yang memiliki fitur terbanyak.” Ini tentang jejak dan gesekan. Untuk survei yang lebih luas yang juga mencakup GUI yang di-hosting, lihat rangkuman alat pengujian API gratis terbaik.

Di bawah ini adalah delapan alat CLI ringan untuk menguji API REST dan HTTP, diurutkan kira-kira dari yang terkecil dan paling manual hingga yang menjalankan rangkaian uji lengkap di CI. Setiap entri memiliki perintah instalasi yang nyata, satu perintah yang menunjukkan cara kerjanya, apa yang terbaik darinya, dan batasan jujur. Yang terakhir, Apidog CLI, adalah biner ringan yang menjalankan skenario yang Anda bangun secara visual dan mengamankan pipeline berdasarkan kode keluarnya.

Apa yang membuat alat CLI “ringan” untuk pengujian API

Banyak alat berjalan di terminal. Tidak semuanya terasa ringan. Untuk daftar ini, sebuah alat memenuhi syarat berdasarkan empat poin:

• Jejak kecil. Biner tunggal, instalasi `pip`/`npm`, atau satu baris `npx`. Tidak ada runtime yang harus Anda siapkan terlebih dahulu, idealnya tidak ada daemon.
• Startup cepat. Alat meluncur dan mengirim permintaan tanpa pemanasan. Biner Rust dan Go unggul di sini; apa pun yang memulai runtime yang berat akan kalah.
• Konfigurasi rendah atau nol. Anda dapat mengirim permintaan pertama tanpa file proyek, tanpa akun, tanpa login. Konfigurasi adalah opt-in, untuk saat Anda ingin menyimpan dan mengulang.
• Output asli terminal. Hasil dicetak dalam bentuk yang dapat Anda baca sekilas dan salurkan ke perintah lain. Kode keluar berarti sesuatu, sehingga CI dapat mengamankannya.

Alat-alat ini mengutamakan tiga yang pertama; dua yang terakhir bersandar pada yang keempat, karena di situlah biner ringan mendapatkan tempatnya dalam sebuah pipeline. Jika Anda ingin lebih mendalami sisi interaktif, memanggil endpoint secara manual, panduan alternatif curl untuk pengujian API REST membahas lebih dalam tentang klien manual.

curl: dasar yang sudah terinstal

curl adalah alat yang hampir pasti sudah Anda miliki. Ini disertakan di macOS, sebagian besar distro Linux, dan Windows modern, jadi instalasi paling ringan adalah tanpa instalasi. Ini mendukung HTTP, HTTPS, dan daftar panjang protokol lainnya, dan ini adalah referensi yang menjadi acuan setiap klien lain mengukur dirinya.

# Sudah ada di mesin Anda; periksa versinya
curl --version

# POST JSON dan cetak hanya status HTTP
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"user":"acme","plan":"pro"}'

Terbaik untuk: permintaan sekali pakai cepat, skrip, dan lingkungan apa pun di mana Anda tidak dapat menginstal apa pun yang baru. Batasan jujur: ergonominya sudah ketinggalan zaman. Anda mengatur header secara manual, JSON tidak dicetak dengan rapi, dan menegaskan pada respons berarti menyalurkannya ke `jq` dan memeriksa kode keluar sendiri. Ini mengirim dan menampilkan; tidak menguji.

HTTPie: curl untuk manusia

HTTPie membuat permintaan yang sama dengan curl, dengan sintaksis yang dibangun untuk manusia. Perintahnya adalah `http`, header dan bidang JSON adalah pasangan `key=value` sederhana, dan keluarannya berwarna dan diformat secara default. Ini ditulis dalam Python, jadi membutuhkan runtime Python, yang membuatnya lebih berat daripada biner tunggal tetapi tetap instalasi satu baris.

python -m pip install httpie   # atau: brew install httpie

# POST JSON: age:=24 mengirim angka, name= mengirim string
http POST httpbin.org/post name=acme age:=24 plan=pro

Terbaik untuk: menjelajahi API secara manual saat Anda menginginkan output yang mudah dibaca tanpa flag. Batasan jujur: startup Python terasa lebih lambat daripada biner terkompilasi, dan menginstal ke sistem yang bersih berarti harus menginstal Python jika belum ada. Seperti curl, ini adalah klien, bukan test runner; Anda membaca responsnya, Anda tidak menegaskannya.

xh: Kecepatan HTTPie dalam satu biner

xh mengimplementasikan ulang sintaksis ramah HTTPie dalam Rust dan dikirimkan sebagai satu biner yang terhubung secara statis. Anda mendapatkan ergonomi `key=value` yang sama dan output berwarna, dengan startup yang lebih cepat dan tidak ada yang perlu diinstal selain biner itu sendiri. Ini mendukung HTTP/2 dan bahkan dapat mencetak perintah curl yang setara dengan `--curl`.

brew install xh   # atau: cargo install xh --locked

# Sintaks yang sama dengan HTTPie, startup lebih cepat
xh POST httpbin.org/post name=acme age:=24 plan=pro

Terbaik untuk: pengembang yang menyukai nuansa HTTPie tetapi menginginkan satu biner cepat tanpa runtime. Batasan jujur: ia tidak mengimplementasikan setiap fitur HTTPie, dan tidak ada sistem plugin. Ini lebih muda dari HTTPie, sehingga ekosistem di sekitarnya lebih kecil. Masih klien, bukan mesin penegasan.

Hurl: pengujian teks biasa yang berjalan di CI

Hurl adalah tempat daftar ini beralih dari “mengirim permintaan” ke “menguji respons.” Ini menjalankan permintaan HTTP yang ditulis dalam file `.hurl` teks biasa dan menegaskan hasilnya. Ini ditulis dalam Rust, didukung oleh libcurl di bawahnya, dan dikirimkan sebagai biner tunggal tanpa runtime. Pengujian terbaca hampir seperti permintaan itu sendiri, yang membuatnya mudah ditinjau dalam permintaan tarik.

brew install hurl   # atau: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF

hurl --test login.hurl   # keluar non-nol jika penegasan gagal

Terbaik untuk: pemeriksaan gaya kontrak dan smoke test yang Anda simpan di kontrol versi sebagai teks yang mudah dibaca. Flag `--test` menjadikannya gerbang CI yang bersih; penegasan yang gagal mengembalikan kode keluar non-nol. Batasan jujur: ini berfokus pada HTTP, jadi tidak akan menggerakkan gRPC atau menghasilkan beban nyata. Alur yang kompleks berarti lebih banyak file `.hurl` daripada bahasa skrip.

Step CI: satu file YAML untuk alur multi-langkah

Step CI menjalankan alur kerja API yang dijelaskan dalam satu file YAML. Ini mencakup REST, GraphQL, gRPC, tRPC, dan SOAP dalam satu alur kerja, dan dapat memvalidasi terhadap skema OpenAPI. Anda menginstalnya dari npm dan menjalankan file yang sama secara lokal dan di CI. Ini terbaca dengan baik ketika sebuah pengujian benar-benar merupakan urutan: masuk, ambil token, gunakan pada panggilan berikutnya, periksa hasilnya.

npm install -g stepci

# workflow.yml menjelaskan langkah-langkah, penangkapan, dan pemeriksaan
stepci run workflow.yml

Terbaik untuk: tim yang menginginkan satu file deklaratif yang menjelaskan alur API multi-langkah, berjalan secara identik di laptop dan di pipeline. Batasan jujur: ini adalah paket Node, jadi lebih berat daripada biner Rust atau Go, dan membawa runtime. Frekuensi rilis telah melambat, jadi periksa aktivitas terbaru repo sebelum Anda membangun pipeline di atasnya. Untuk bagaimana bagian-bagian ini cocok dengan rencana pengujian yang lebih lengkap, lihat strategi pengujian API.

k6: pengujian beban ringan dari terminal

k6 menjawab pertanyaan yang berbeda: bukan “apakah respons ini benar” tetapi “apakah respons ini bertahan di bawah beban.” Ini ditulis dalam Go, dikirimkan sebagai biner statis tunggal, dan skripnya adalah JavaScript biasa. Ini dibangun untuk penggunaan sumber daya minimal, sehingga Anda dapat mendorong lalu lintas nyata dari laptop. Ambang batas mengubah uji beban menjadi gerbang lulus/gagal; jika salah satu terlampaui, k6 keluar dengan kode 99, yang dibaca oleh pipeline sebagai kegagalan.

brew install k6   # atau jalankan via Docker: docker run grafana/k6

cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';
export const options = {
  vus: 10, duration: '30s',
  thresholds: { http_req_duration: ['p(95)<500'] },
};
export default function () {
  const res = http.get('https://httpbin.org/get');
  check(res, { 'status is 200': (r) => r.status === 200 });
}
EOF

k6 run load.js

Terbaik untuk: pemeriksaan kinerja dan beban yang ingin Anda skrip dan jalankan di CI tanpa menyiapkan klaster. Batasan jujur: ini adalah alat beban, bukan klien uji fungsional; Anda tidak akan menggunakannya untuk memeriksa satu respons secara visual. Menulis skenario yang bermakna berarti mempelajari API JavaScript-nya.

Newman: jalankan koleksi Postman tanpa kepala

Newman adalah runner baris perintah untuk koleksi Postman. Jika tim Anda sudah membangun permintaan dan pengujian di Postman, Newman menjalankan koleksi persis itu dari terminal tanpa GUI, itulah yang Anda butuhkan di CI. Anda mengekspor koleksi (dan secara opsional lingkungan) sebagai JSON dan menunjuk Newman ke sana.

npm install -g newman

# collection.json diekspor dari Postman; -e meneruskan lingkungan
newman run collection.json -e staging.json

Terbaik untuk: tim yang berinvestasi di Postman yang ingin koleksi mereka yang sudah ada berjalan tanpa kepala di pipeline. Newman mengembalikan kode keluar non-nol saat pengujian gagal, sehingga ia menjaga CI dengan bersih. Batasan jujur: ini adalah paket Node, dan hanya menjalankan koleksi format Postman, jadi ini paling berguna jika Anda sudah berada di ekosistem itu. Ini menjalankan pengujian yang dibuat seseorang di GUI; pembuatannya masih terjadi di sana.Apidog CLI: jalankan skenario yang Anda bangun, amankan CI berdasarkan kode keluar

Apidog CLI adalah ujung ringan dari Apidog. Ini adalah paket npm, `apidog-cli`, yang menjalankan skenario pengujian yang Anda rancang secara visual di Apidog langsung dari terminal. Bagian pembangunan pengujian tetap di GUI, di mana mengurutkan permintaan, mengekstrak variabel, dan menulis penegasan cepat; CLI adalah bagian kecil yang menjalankan salah satu skenario tersebut tanpa kepala dan memberi Anda kode keluar. Apidog bukan sumber terbuka, tetapi tingkat gratisnya ditambah CLI ini memberi Anda alternatif terintegrasi untuk menyatukan klien, runner, dan alat beban yang terpisah.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Salin perintah persis dari tab CI/CD skenario Anda
apidog run -t <scenario_id> -e <env_id> -r cli

Anda tidak menebak ID skenario dan lingkungan. Buka skenario pengujian Anda di Apidog, buka tab CI/CD, dan salin perintah `apidog run` yang dihasilkan dengan ID yang sudah terisi. Reporter `-r cli` mencetak hasil langkah demi langkah dan ringkasan di terminal; tambahkan `-r cli,junit` ketika dasbor CI perlu mengurai hasilnya. Seperti alat-alat di atas, `apidog run` keluar `0` ketika setiap penegasan lulus dan non-nol ketika ada yang gagal, sehingga pipeline memperlakukannya sebagai gerbang yang bersih. Outputnya adalah JSON terstruktur dengan `agentHints.nextSteps`, yang memudahkan agen pengkodean AI untuk menjalankan dan membacanya juga.

Terbaik untuk: tim yang ingin membuat skenario kompleks multi-langkah di editor visual tetapi menjalankannya tanpa kepala di CI atau dari agen. Batasan jujur: tidak seperti curl atau xh, ini terikat pada skenario yang Anda simpan dalam proyek Apidog, jadi ini adalah opsi platform terintegrasi, bukan klien HTTP biasa. Untuk set perintah lengkap, lihat panduan lengkap Apidog CLI, referensi perintah apidog run, dan panduan langkah demi langkah tentang cara menguji REST API dari baris perintah dengan Apidog CLI.

Cara memilih

Alat yang tepat tergantung pada seberapa jauh Anda perlu melangkah melewati “kirim satu permintaan”.

Mulai dari atas untuk pekerjaan manual. Gunakan curl atau xh untuk memanggil endpoint. Beralih ke Hurl ketika Anda ingin pemeriksaan tersebut berjalan di kontrol versi. Gunakan k6 ketika pertanyaan beralih ke beban, dan Newman jika pengujian Anda sudah ada di Postman. Pilih Apidog CLI ketika Anda lebih suka membangun skenario kompleks di editor dan menjalankannya tanpa kepala di mana pun. Jika Anda mempertimbangkan ini terhadap alur kerja bebas GUI yang lengkap, panduan alat pengujian API tanpa kepala mencakup menjalankan pengujian tanpa antarmuka sama sekali.

Di mana alat ringan memberikan keuntungan

Alat CLI ringan unggul pada hari-hari yang sama ketika GUI memperlambat Anda: saat Anda tenggelam dalam terminal, saat pengujian perlu berjalan di CI tanpa campur tangan manusia, dan semakin sering ketika agen AI menjalankan pemeriksaan untuk Anda. curl dan xh menjaga alur manual tetap ketat. Hurl dan Step CI mengubah permintaan ad-hoc menjadi pengujian yang dapat diulang. k6 menjawab pertanyaan beban. Newman menjalankan apa yang sudah Anda bangun di Postman.

Apidog CLI menjembatani kesenjangan antara membangun pengujian dan menjalankannya di mana saja. Anda merancang skenario sekali di Apidog, lalu `apidog run` menjalankannya dari terminal, pipeline, atau agen, dan kode keluar menentukan apakah build tetap hijau. Unduh Apidog, bangun satu skenario, dan masukkan perintah `apidog run` ke dalam konfigurasi CI Anda untuk melihat seluruh alur tertutup.