Kalau lu pernah bikin REST API yang fiturnya mulai kompleks, lu pasti pernah ketemu momen dilematis ini: butuh bikin endpoint buat pencarian data yang parameternya banyak banget (filter, sort, date range, pagination).

Nggak mungkin kan semua parameter ditaruh di URL string panjang pakai GET? Selain jelek, URL itu rentan ngelewatin batas maksimal panjang yang diizinkan server atau proxy. Terus ujung-ujungnya apa? Lu terpaksa pakai POST buat fetch data. Iya, POST—method yang secara teori tugasnya buat ngubah state atau bikin resource baru, malah lu pakai buat baca data doang cuma gara-gara dia bisa bawa request body yang lega.

Kabar baiknya, dosa arsitektur berjamaah yang udah kita lakukan selama belasan tahun ini akhirnya punya solusi resmi. IETF baru aja merilis RFC 10008 yang memperkenalkan HTTP method baru: QUERY.

Kenapa Kita Butuh Method QUERY?

Secara fundamental, perdebatan GET vs POST buat fetching data itu selalu mentok di keterbatasan spesifikasi HTTP lama.

  • GET itu aman (safe) dan idempotent. Dia cuma baca data dan gampang di-cache oleh CDN atau browser. Masalahnya, spesifikasi tradisional menganggap request body di GET itu nggak punya makna yang jelas. Alhasil, banyak server, load balancer, atau cache proxy bakal nolak (HTTP 400 Bad Request) kalau lu nekat kirim GET pakai body.
  • POST bisa bawa body lega, entah itu JSON raksasa, struktur GraphQL query, atau payload Elasticsearch. Tapi POST secara standar nggak safe dan nggak idempotent. Dia sama sekali nggak dirancang buat di-cache.

Jadi selama ini, developer selalu disuruh milih: mau API-nya patuh aturan REST (pakai GET tapi URL berantakan), atau pragmatis tapi agak "nyeleneh" (pakai POST buat pencarian).

Cara Kerja HTTP QUERY

Method QUERY hadir buat menggabungkan keunggulan keduanya. QUERY didesain sebagai method yang:

  1. Safe & Idempotent: Seperti GET, dia murni cuma membaca data tanpa mengubah state di server.
  2. Cacheable: Respons dari QUERY bisa di-cache dengan baik oleh infrastruktur jaringan, sangat membantu buat performa baca API yang tinggi.
  3. Boleh bawa Payload/Body: Nah ini yang paling penting. Lu bisa kirim JSON raksasa berisi kriteria pencarian kompleks di dalam body request tanpa dimarahin standar HTTP.

Secara sintaks, bentuknya sama persis kayak HTTP request biasa, cuma verb-nya diganti jadi QUERY:

QUERY /api/v1/users HTTP/1.1
Host: rafli.dev
Content-Type: application/json

{
  "role": "developer",
  "skills": ["typescript", "rust"],
  "joined_after": "2024-01-01",
  "limit": 50
}

Apa Artinya Buat Developer Sekarang?

Menurut gua, ini adalah berita besar buat ekosistem web, terutama buat lu yang sering pakai GraphQL atau bikin search engine API yang selama ini selalu "menyalahgunakan" method POST.

Tapi, jangan langsung besok pagi lu rombak semua API production lu dari POST ke QUERY. Standar RFC 10008 memang udah rilis, tapi adopsinya butuh waktu. Infrastruktur web itu lambat bergeraknya. Framework backend (seperti Express, Nuxt Nitro, Laravel), library HTTP client (Axios, Fetch API), sampai middle-man kayak Nginx atau Cloudflare butuh waktu buat nge-support QUERY secara native tanpa menolak request-nya secara default.

Takeaway Singkat

  • Buat endpoint read-only yang butuh request payload kompleks, sebentar lagi standar industrinya bakal pindah ke QUERY.
  • Untuk sekarang, tetap pakai POST buat GraphQL atau complex search API sambil mantau kapan framework dan infra favorit lu mulai nge-support QUERY.
  • Kalau lu lagi ngebangun proxy atau API gateway kustom, ini saatnya lu mastiin sistem lu nggak panik kalau ada request masuk dengan HTTP verb QUERY.

Referensi / Bacaan Lanjut

Tags:
#Software Development#Backend