Selama enam belas tahun, para pengembang yang perlu mengajukan pertanyaan kompleks ke server terjebak dengan solusi sementara. Ketika muatan pencarian menjadi terlalu besar untuk sebuah URL, atau ketika filter bersarang dan parameter sensitif tidak muat di dalam string kueri, satu-satunya opsi praktis adalah POST. Metode ini membawa byte, tetapi berbohong tentang tujuannya. POST menandakan perubahan status. Menggunakannya untuk operasi baca-saja memaksa seluruh jalur jaringan—cache, proxy, dan browser—untuk memperlakukan pencarian biasa seolah-olah dapat mengubah database.

Kompromi tersebut akhirnya berakhir. Pada Juni 2026, IETF menerbitkan RFC 10008, yang secara resmi menstandarisasi metode QUERY. Ini adalah metode HTTP baru pertama sejak PATCH diperkenalkan pada tahun 2010. QUERY ada khusus untuk permintaan yang aman dan idempoten yang kebetulan membutuhkan body. Ia tidak mengubah status server. Mengulangi permintaan yang sama akan menghasilkan hasil yang sama. Ia dapat dicache, yang berarti perantara dapat menyimpan dan menggunakan kembali responsnya. Dan tidak seperti GET, ia memungkinkan adanya muatan data seperti halnya POST.

Kueri GraphQL dan endpoint pencarian REST yang kompleks adalah pemenang yang paling jelas. Anda tidak perlu lagi menjejalkan enam puluh parameter kueri ke dalam URL atau menyembunyikan dokumen filter JSON di dalam body POST yang akan ditolak untuk dicache oleh perantara. Semantiknya kini menjadi jujur.

Namun, sebuah RFC hanyalah tinta di atas kertas. Di antara aplikasi Anda dan pengguna Anda terdapat lapisan infrastruktur yang tebal, dan sebagian besar darinya belum pernah mendengar tentang QUERY.

Masalah caching belum terpecahkan

Dengan permintaan GET, caching sangatlah sederhana. Kunci cache adalah URI. Dua pengguna yang mengakses URL yang sama akan mendapatkan respons tersimpan yang sama, asalkan header mengizinkannya.

QUERY merusak model tersebut karena parameter permintaan berada di dalam body. Agar cache dapat mengenali bahwa dua permintaan identik, kunci cache harus menyertakan URI dan konten body. Persyaratan tersebut menimbulkan hambatan operasional yang nyata.

Pertama, edge server dan CDN harus melakukan buffering pada seluruh body permintaan sebelum mereka dapat menghitung hash. Hal itu membutuhkan memori dan waktu pada node edge. Kedua, dua kueri yang secara logis identik mungkin tidak menghasilkan byte yang sama. Satu klien mungkin mengirim {"status":"active"} sementara klien lain mengirim {"status": "active"} dengan spasi kosong atau pengurutan kunci yang berbeda. Kecuali lapisan caching mengurai, menormalisasi, dan melakukan kanonisasi pada body—mengurutkan kunci JSON, menghapus pemformatan yang tidak signifikan, dan menangani perbedaan pengodean—pertanyaan yang sama akan selalu gagal mendapatkan cache.

Yang paling kritis, CDN arus utama belum mempartisi cache berdasarkan body permintaan untuk QUERY. Cloudflare, misalnya, tidak memperlakukan body sebagai bagian dari kunci cache untuk metode ini dalam bentuknya saat ini. Jika Anda menerapkan QUERY dengan asumsi bahwa "dapat dicache" berarti "sudah dicache", Anda mungkin akan melihat kesalahan kolisi, kegagalan cache universal, atau respons yang bocor ke permintaan lain yang tidak terkait. Sampai penyedia Anda menerbitkan dukungan eksplisit, asumsikan bahwa QUERY tidak dapat dicache secara berarti di lingkungan produksi.

Alat Anda mungkin akan memblokirnya terlebih dahulu

Setiap permintaan HTTP melewati tumpukan middlebox, dan sebagian besar darinya menerapkan aturan ketat tentang metode mana yang legal.

Web Application Firewall dan API gateway sering kali mengandalkan allowlist eksplisit. Aturan tipikal mengizinkan GET, POST, PUT, DELETE, dan PATCH. Apa pun selain itu akan dibuang atau dijawab dengan 405 Method Not Allowed. QUERY akan menabrak dinding-dinding tersebut sebelum sempat mencapai kode aplikasi Anda.

Mesin aturan keamanan menambah hambatan lain. Beberapa sistem deteksi intrusi berasumsi bahwa permintaan yang membawa body