Parameter Query dalam URL: Kapan, Mengapa, dan Cara Menggunakannya dengan Benar

Sudah pernah terpaku melihat URL seperti ini saat debugging di browser?

?id=42&mode=edit

…dan terpikir:

“Kenapa parameter ini dibuka begitu saja di URL? Kenapa nggak kita sembunyikan aja di body atau tempat yang kurang mencolok?”

Tahan dulu pemikiran itu! Hari ini, kita akan membahas tentang query parameter yang sederhana tapi penting ini—kenapa mereka berada di URL, dan kenapa mereka seharusnya dengan bangga ada di sana.

Memesan mi ala developer

Contoh nyata di proyek:

const userId = getUserIdFromSession();
fetch(`/api/user?id=${userId}&mode=edit`)
  .then(res => res.json())
  .then(showEditForm);

API ini cuma satu fungsi: mengambil data user untuk diedit.

Mari kita bedah:

• fetch defaultnya GET jika method tak ditentukan.
• Tidak ada payload besar di request.
• Parameter = siapa + buat apa.

Ini sama seperti kamu masuk ke kedai mie dan bilang:

“Satu beef ramen, extra pedas, tanpa daun bawang!”

Bagian ?id=42&mode=edit itu persis sama: extra pedas, tanpa daun bawang. Jelas, to the point, dan nggak berbahaya.

GET Params bukan isi POST

Banyak pemula bertanya:

“Kenapa nggak taruh ?id=123 di body aja? Kayaknya lebih bersih.”

Boleh sih—asal kamu nggak masalah kalau GET request sama sekali mengabaikan body.
Itulah aturan HTTP. Bukan kita yang buat, oke?

Contohnya:

// ❌ Jangan lakukan ini — GET akan mengabaikan body
fetch('/api/user', {
  method: 'GET',
  body: JSON.stringify({ id: 123 }) // ≤ Sia-sia
});

Itu seperti kamu ke food truck dan mencoba pesan telur tambahan…

…cuma dengan pandangan mata.

Kokinya bagaimana mau tahu kamu ingin apa?

Query Params itu seperti suara jelas dan percaya diri kamu berkata:

“Tambahan guac! Tanpa bawang! Tortilla jagung! Gracias.”

Kasus Penggunaan 1: Menemukan Resource (semacam GPS untuk API)

fetch('/api/products?category=smartphones&sort=price_asc&page=2');

API ini nggak merubah apa-apa—hanya mengambil daftar data dengan filter. Itu baca, bukan tulis.

Menaruh filter dan urutan di URL seperti setting koordinat di GPS. Memberi tahu server tepat ingin kemana dan bagaimana.

✅ Tip REST: GET = menanyakan sesuatu tanpa mengubahnya

URL seperti ini mudah di-cache, dibagikan, atau dibookmark. Tempel di Slack, rekan kerja langsung ngerti ingin query apa.

Kasus Penggunaan 2: Ke-mem-cache-an (CDN cinta query params)

Dari cache browser sampai CDN dan proxy, semua butuh URL yang konsisten.

GET /api/posts?tag=nodejs&page=1
GET /api/posts?tag=nodejs&page=2

Setiap URL adalah seperti kunci cache unik. Bersih, terpisah, dan performa optimal.

Seperti memesan makan siang ke kantor—kamu tulis alamat lengkap tiap kali. Kurir nggak perlu nebak lantai kamu.

Kasus Penggunaan 3: Kemudahan Debugging

Bahkan meski kamu bukan penulis API-nya:

https://api.example.com/search?query=chatgpt&lang=en&page=3

Kalau liat itu, langsung paham.

Tapi ini?

POST /search
Body: { "query": "chatgpt", "lang": "en", "page": 3 }

Sekarang kamu harus buka DevTools → Tab Network → Preview → Expand JSON → sigh.

Query Params itu seperti Sticky Note di pintu:

“Pergi beli kopi, kembali jam 15.00.”

Sekali liat = langsung paham konteks.

Kapan Tidak Pakai URL Params?

Jangan kebablasan. Ada data yang sebaiknya tidak nongol di publik.

✅ Unggah kapan pakai vs hindari query params:

Capek bikin URL manual? Kenalan sama EchoAPI

Masih bikin URL manual:

`/api/user?id=${id}&mode=${mode}&sort=${sort}`

Itu kayak bikin resume di Notepad.

Kamu bikin aplikasi modern dengan React, Next.js, Tailwind,
tapi masih wrapping param manual? Udah ketinggalan zaman, bro.

Kenalin EchoAPI—asisten param, stylist antarmuka, dan coach konsistensi tim kamu.

1. Visual Param Editor — Bye-bye headache flag=1

Ingat bingung decode URL seperti:

• flag=1 — ini enabled atau disabled?
• type=2 — ini admin, power-user, atau… tupai?

EchoAPI kasih kamu:

✅ Klik-tambah key/value/penjelasan
✅ Tampilan tabular yang jelas
✅ Zero guesswork

Serasa kasih name tag dan title ke param kamu:
“Hi, aku sortMode, aku atur urutan.”

2. Smart Naming Assistant — Hilangkan kekacauan getListV2Final_New

Namain API? Itu sulit sekali.
Salah ketik? Malu banget.

Kamu dulu coba getListV2ByNew, terus lupa fungsinya apa.
Typo serchQuerry tengah malam, baru ketahuan pas production. Aduh.

Dengan bantuan EchoAPI’s Standard Parameter Naming:

• Saran nama yang konsisten dan bersih
• Auto-koreksi typo dan casing
• Contoh: usr_iid → userId, srch_querry → searchQuery

Serasa ada grammar nerd + PM ngawas autocomplete kamu.

Shame di code review? Bye-bye.

3. Param Dictionary — Stop perang uid vs user_id vs userId

Pasti pernah nemu:

Bubar, perang gitu udah usang.

EchoAPI punya Parameter Dictionary: sekali definisi userId: string, bisa dipakai di seluruh endpoint.

Kata Akhir: Param itu bukan sekadar data—melainkan dialog terstruktur

API bukan cuma kode—tapi percakapan antar sistem.

Query Param bukan hiasan opsional—mereka adalah kosa kata agar pertanyaan kita:

• Spesifik
• Bisa direproduksi
• Mudah di-debug

Dengan alat seperti EchoAPI, kamu bukan cuma bikin endpoint.
Kamu bangun bahasa bersama, pengalaman dev yang konsisten, dan UX developer yang bersih.

Pusing sama endpoint kacau dan URL spaghetti?
Coba EchoAPI — biarkan URL mu makin dewasa.

Buat param kamu terbaca.
Buat bisa dipakai ulang.
Buat bisa dibanggakan.