Alat Pengujian API Berbasis Terminal Terbaik Tahun 2026

Pengujian API tidak lagi terbatas pada GUI. Tes kini dijalankan di kontainer CI tanpa tampilan, server staging yang hanya dapat diakses melalui SSH, dan agen AI yang hanya menggunakan shell. Dalam semua kondisi tersebut, terminal menentukan apakah tes lulus atau gagal tanpa intervensi manusia.

Alat yang benar-benar berbasis terminal harus mendukung seluruh loop dari shell: instal dengan package manager, jalankan satu perintah, lalu gunakan kode keluar sebagai sinyal sukses atau gagal di CI. Artikel ini membandingkan alat berdasarkan assertion bawaan, alur multi-langkah, laporan siap-CI, dan status pemeliharaan. Klien manual seperti curl tetap penting, tetapi posisinya berbeda: mereka membantu mengirim dan memeriksa request, bukan menggagalkan pipeline secara otomatis. Untuk cakupan yang juga membahas GUI dan alat berbasis host, lihat alat pengujian API gratis terbaik.

Coba Apidog hari ini

Apa yang membedakan alat pengujian dari klien

Klien terminal mengirim request dan menampilkan respons. Alat pengujian terminal mengevaluasi respons, lalu mengembalikan kode keluar yang dapat dijadikan gerbang oleh pipeline Anda.

Gunakan kriteria berikut saat memilih alat:

• Assertion bawaan: cek status, header, dan body dilakukan oleh alat, bukan dirangkai dengan jq dan shell script.
• Kode keluar yang bermakna: 0 untuk lulus dan non-nol untuk gagal.
• Keterulangan: tes disimpan sebagai file atau proyek yang dapat diberi versi dan dijalankan ulang.
• Laporan: hasil tersedia untuk manusia di terminal dan untuk CI dalam format seperti JSON, JUnit, atau HTML.

Berikut sepuluh alat yang dapat digunakan untuk pengujian API dari terminal pada 2026.

1. Apidog CLI: buat secara visual, jalankan tanpa kepala di mana saja

Apidog adalah platform API all-in-one untuk desain, pengujian, mocking, dan dokumentasi. apidog-cli adalah CLI untuk menjalankan skenario yang dibuat di editor visual.

Buat skenario dengan request berantai, ekstraksi variabel, dan assertion di Apidog. Setelah itu, jalankan skenario yang sama dari laptop, CI, atau agen AI menggunakan apidog run.

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

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

Jangan menebak ID skenario atau environment. Buka skenario di Apidog, masuk ke tab CI/CD, lalu salin perintah yang dihasilkan.

Gunakan reporter sesuai kebutuhan pipeline:

# Output terminal
apidog run -t <scenario_id> -e <env_id> -r cli

# Simpan laporan untuk artefak CI
apidog run -t <scenario_id> -e <env_id> -r junit
apidog run -t <scenario_id> -e <env_id> -r json
apidog run -t <scenario_id> -e <env_id> -r html

Laporan ditulis ke apidog-reports/. Apidog CLI juga mendukung eksekusi berbasis data dari file CSV atau JSON. Output JSON terstruktur menyediakan agentHints.nextSteps, sehingga agen pengodean AI dapat menjalankan suite dan menentukan langkah berikutnya tanpa membaca UI.

Terbaik untuk: tim yang ingin membuat skenario multi-langkah di editor visual dan menjalankannya secara identik di laptop, CI, dan agen.

Batasan: bukan open source dan bukan alat pengirim HTTP ad-hoc. Skenario disimpan dalam proyek Apidog, sehingga ini adalah opsi platform terintegrasi.

Lihat panduan lengkap Apidog CLI untuk daftar perintah lengkap.

2. Hurl: tes teks biasa dalam satu biner Rust

Hurl menjalankan request HTTP yang ditulis dalam format teks biasa dan memvalidasi responsnya. Hurl dibuat dengan Rust di atas libcurl dan didistribusikan sebagai satu biner, sehingga tidak memerlukan runtime tambahan.

Buat file .hurl yang berisi request dan assertion:

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

cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }

HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF

hurl --test login.hurl

Perintah hurl --test mengembalikan exit code non-nol jika assertion gagal, sehingga dapat langsung digunakan sebagai langkah CI.

Terbaik untuk: smoke test dan pemeriksaan kontrak yang disimpan sebagai teks mudah dibaca di repository.

Batasan: berfokus pada HTTP. Hurl bukan alat gRPC atau load testing, dan alur dengan logika kompleks dapat menghasilkan banyak file .hurl.

3. Newman: menjalankan koleksi Postman tanpa kepala

Newman adalah runner baris perintah open-source untuk koleksi Postman dengan lisensi Apache-2.0. Jika tim Anda sudah memiliki request dan tes di Postman, gunakan Newman untuk menjalankan koleksi yang sama dari terminal.

Ekspor koleksi dan environment ke JSON, lalu jalankan:

npm install -g newman

newman run collection.json -e staging.json

Tambahkan reporter bila pipeline Anda membutuhkan hasil terstruktur:

newman run collection.json \
  -e staging.json \
  -r cli,junit,json

Newman keluar dengan kode non-nol saat tes gagal, sehingga CI dapat menghentikan build secara otomatis.

Terbaik untuk: tim yang sudah berinvestasi di Postman dan ingin menjalankan koleksi yang ada di pipeline.

Batasan: hanya menjalankan koleksi format Postman. Pembuatan koleksi dan tes masih dilakukan di GUI Postman.

4. Postman CLI: alternatif pihak pertama untuk Newman

Postman CLI adalah runner closed-source dari Postman. Tidak seperti Newman yang menggunakan file ekspor, Postman CLI dapat masuk ke akun Postman dan menjalankan koleksi berdasarkan ID langsung dari workspace.

postman login --with-api-key <YOUR_API_KEY>

postman collection run <collection_id> -e <environment_id>

Pilih pendekatan ini jika Anda ingin hasil eksekusi tetap terhubung ke cloud Postman tanpa mengelola file JSON ekspor.

Terbaik untuk: tim Postman yang membutuhkan eksekusi terhubung ke workspace dan cloud Postman.

Batasan: closed-source, bergantung pada akun Postman, dan keberadaan dua runner resmi dapat membingungkan proses adopsi.

Baca perbandingan Postman CLI vs Newman sebelum memilih runner.

5. Bruno CLI: koleksi git-native dengan bru

Bruno menyimpan koleksi sebagai file .bru teks biasa dalam folder biasa. Dengan pendekatan ini, request dapat ditinjau melalui pull request dan disimpan bersama kode aplikasi.

Instal CLI lalu jalankan koleksi dari direktori aktif:

npm install -g @usebruno/cli

# Jalankan semua request pada koleksi saat ini
bru run --env staging

Bruno CLI dapat menghasilkan laporan JSON, JUnit, dan HTML untuk CI.

Terbaik untuk: tim yang ingin koleksi API bersifat git-native, dapat dijalankan offline, dan dapat ditinjau seperti kode.

Batasan: format teks biasa lebih nyaman bagi pengembang dibanding tim campuran non-teknis, dan ekosistemnya lebih muda dibanding Postman.

Lihat perbandingan Bruno CLI vs Apidog CLI.

6. Schemathesis: biarkan skema menulis tes

Schemathesis membaca skema OpenAPI atau GraphQL lalu menghasilkan banyak kasus uji menggunakan property-based testing berbasis Hypothesis Python.

Alih-alih menulis setiap variasi input secara manual, Anda dapat menjalankan skema untuk mencari error 500, pelanggaran respons, dan ketidaksesuaian terhadap kontrak API.

pip install schemathesis

schemathesis run https://api.example.com/openapi.json

Masukkan perintah ini ke pipeline sebelum rilis, terutama jika spesifikasi OpenAPI Anda sudah akurat.

Terbaik untuk: menemukan edge case yang tidak terpikirkan saat menulis tes manual.

Batasan: membutuhkan skema yang benar-benar dapat diandalkan. API besar dapat menghasilkan banyak temuan yang perlu difilter menggunakan hook dan opsi konfigurasi.

7. Step CI: satu file YAML untuk alur multi-langkah

Step CI mendeskripsikan workflow API dalam satu file YAML. File tersebut dapat berisi langkah, nilai yang diekstrak, assertion, serta validasi terhadap skema OpenAPI.

Step CI mendukung REST, GraphQL, gRPC, tRPC, dan SOAP dalam satu workflow.

npm install -g stepci

stepci run workflow.yml

Gunakan untuk alur deklaratif seperti login, ekstrak token, lalu panggil endpoint yang membutuhkan token tersebut.

Terbaik untuk: workflow multi-langkah tanpa harus menulis scripting khusus.

Batasan: membutuhkan runtime Node.js. Periksa aktivitas repository terbaru sebelum menjadikannya fondasi pipeline jangka panjang.

8. curl: fondasi yang biasanya sudah terinstal

curl tersedia secara bawaan di macOS, sebagian besar distribusi Linux, dan Windows modern. Ini adalah klien HTTP referensi untuk request manual, scripting, dan lingkungan terkunci yang tidak mengizinkan instalasi alat baru.

Contoh berikut hanya mencetak status HTTP dari request POST:

curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -d '{"sku":"A-102","qty":2}'

Untuk menjadikannya test gate, Anda harus mengelola validasi dan exit code sendiri:

status=$(curl -s -o /dev/null -w "%{http_code}" \
  https://api.example.com/health)

test "$status" = "200"

Terbaik untuk: request satu kali, debugging, scripting ringan, dan environment yang terkunci.

Batasan: assertion sepenuhnya DIY. Anda perlu memakai jq, membandingkan nilai sendiri, dan mengelola kegagalan shell secara manual.

Lihat alternatif curl untuk pengujian REST API saat curl tidak lagi cukup.

9. HTTPie dan xh: request manual yang mudah dibaca

HTTPie membuat request terminal lebih mudah dibaca. Perintahnya menggunakan http, field JSON dapat ditulis sebagai key=value, dan respons ditampilkan dengan format yang lebih nyaman.

xh mengimplementasikan sintaks serupa dalam Rust sebagai satu biner statis. xh memiliki startup lebih cepat dan flag --curl untuk menampilkan perintah curl yang setara.

http POST api.example.com/users name=acme plan=pro   # HTTPie
xh   POST api.example.com/users name=acme plan=pro   # xh

Gunakan keduanya untuk eksplorasi manual sebelum mengubah request menjadi tes yang dapat dijalankan di CI.

Terbaik untuk: mencoba endpoint dan memeriksa respons secara manual.

Batasan: keduanya adalah klien, bukan test runner. HTTPie membawa runtime Python, sedangkan xh menukar sebagian fitur dengan kecepatan. Keduanya tidak menyediakan assertion respons bawaan.

10. k6: ketika yang diuji adalah beban

k6 menjawab pertanyaan berbeda dari test runner fungsional: bukan hanya “apakah respons benar?”, tetapi “apakah API tetap bertahan saat menerima traffic?”.

k6 adalah biner Go dari Grafana dengan skrip JavaScript. Threshold dapat digunakan sebagai gerbang lulus/gagal: jika ambang batas terlampaui, k6 keluar dengan kode non-nol.

brew install k6

k6 run load.js

Contoh minimal load.js:

import http from "k6/http";
import { check } from "k6";

export const options = {
  vus: 10,
  duration: "30s",
  thresholds: {
    http_req_failed: ["rate<0.01"],
    http_req_duration: ["p(95)<500"],
  },
};

export default function () {
  const response = http.get("https://api.example.com/health");

  check(response, {
    "status adalah 200": (r) => r.status === 200,
  });
}

Terbaik untuk: pemeriksaan performa yang disimpan di repository yang sama dengan tes fungsional dan dijalankan dari laptop maupun CI.

Batasan: ini adalah alat load testing berlisensi AGPL-3.0, bukan klien tes fungsional. Skenario yang berarti membutuhkan pemahaman API JavaScript k6.

Lebih suka sesuatu yang interaktif?

Jika Anda ingin antarmuka seperti Postman tanpa keluar dari shell, gunakan kategori berbeda: klien TUI seperti atac dan posting. Alat tersebut menyediakan editor request lengkap di terminal untuk eksplorasi API, tetapi bukan pilihan utama untuk mengunci pipeline.

Lihat ringkasan klien REST API terminal dan TUI terbaik untuk pembahasan lebih dalam.

Tabel perbandingan

Alat	Tugas	Assertion bawaan	Instalasi	Sumber terbuka
Apidog CLI	Jalankan skenario yang dibuat visual di CI	Ya	npm i -g apidog-cli	Tidak (tingkat gratis)
Hurl	Tes HTTP teks biasa	Ya	brew install hurl	Apache-2.0
Newman	Koleksi Postman tanpa kepala	Ya	npm i -g newman	Apache-2.0
Postman CLI	Eksekusi Postman terhubung cloud	Ya	Pemasang Postman	Tidak
Bruno CLI	Koleksi .bru git-native	Ya	npm i -g @usebruno/cli	MIT
Schemathesis	Fuzzing dari skema	Dihasilkan	pip install schemathesis	MIT
Step CI	Alur YAML multi-langkah	Ya	npm i -g stepci	MPL-2.0
curl	Request mentah dan scripting	DIY	Sudah terinstal	Ya
HTTPie / xh	Request manual yang mudah dibaca	Tidak	brew install httpie / xh	Ya
k6	Load test dengan threshold lulus/gagal	Threshold	brew install k6	AGPL-3.0

Cara memilih

Mulailah dari jenis pekerjaan, bukan nama alatnya:

1. Sudah punya koleksi Postman
   
   Jalankan dengan Newman atau Postman CLI.

2. Ingin tes sebagai file yang dapat ditinjau di Git
   
   Gunakan Hurl atau Bruno CLI.

3. Memiliki spesifikasi OpenAPI yang akurat
   
   Tambahkan Schemathesis untuk mencari edge case secara otomatis.

4. Membutuhkan workflow deklaratif multi-langkkah
   
   Gunakan Step CI.

5. Membutuhkan request manual cepat
   
   Simpan curl, HTTPie, atau xh untuk debugging dan eksplorasi.

6. Menguji kapasitas, bukan hanya kebenaran
   
   Tambahkan k6 bersama runner fungsional.

7. Ingin membuat skenario secara visual tetapi menjalankannya dari shell
   
   Gunakan Apidog CLI.

Apidog CLI menjadi opsi terintegrasi jika proyek Anda juga membutuhkan desain API, data mock, dan dokumentasi dalam platform yang sama. Lihat Apidog CLI: klien API yang hidup di terminal Anda untuk detail implementasinya.

Untuk konteks yang lebih luas, panduan strategi pengujian API memetakan posisi setiap lapisan pengujian.

FAQ

Bisakah saya menguji API sepenuhnya dari terminal?

Ya. Buat tes sebagai file dengan Hurl, Bruno, atau Step CI; atau buat di editor visual dengan Apidog dan Postman. Setelah itu, jalankan tanpa kepala menggunakan CLI yang sesuai. Runner dalam daftar ini mengembalikan kode keluar yang dapat dipakai CI.

Apa perbedaan antara klien API terminal dan alat pengujian?

Klien seperti curl, HTTPie, dan xh mengirimkan request lalu menampilkan respons. Alat pengujian seperti Apidog CLI, Hurl, dan Newman memvalidasi respons dan keluar dengan kode non-nol saat assertion gagal. Klien digunakan untuk eksplorasi; alat pengujian digunakan untuk mengunci kualitas.

Mana yang dapat berjalan di pipeline CI?

Semua runner berikut dapat digunakan di CI:

apidog run
hurl --test
newman run
postman collection run
bru run
schemathesis run
stepci run
k6 run

Semua mengembalikan kode non-nol saat gagal. Untuk contoh implementasi, lihat cara menjalankan tes Apidog CLI di GitHub Actions.

Apakah ada yang mendukung load testing?

k6 adalah spesialis load testing dalam daftar ini. Gunakan threshold sebagai gerbang lulus/gagal. Alat lain berfokus pada kebenaran respons, bukan kapasitas, sehingga banyak tim memasangkan satu runner fungsional dengan k6.

Apakah saya memerlukan spesifikasi OpenAPI?

Hanya Schemathesis yang memerlukan skema karena alat tersebut menghasilkan tes dari spesifikasi. Pada alat lain, OpenAPI membantu tetapi tidak wajib. Apidog dapat mengimpor OpenAPI 3.x, Swagger 2.0, dan koleksi Postman, sedangkan Step CI dapat memvalidasi respons terhadap skema.

Pola utama dari semua alat ini sederhana: pembuatan tes membutuhkan kenyamanan, sedangkan eksekusi membutuhkan shell dan exit code yang konsisten. Tentukan tempat Anda ingin menulis tes, lalu pastikan runner dapat mengembalikan status yang dipahami pipeline Anda.

Jika Anda ingin desain, pengujian, mocking, dokumentasi, dan eksekusi CLI dalam satu platform, unduh Apidog, buat satu skenario di editor, lalu tambahkan apidog run ke pipeline CI Anda.