Metode HTTP QUERY yang baru

Penjelasan tentang metode HTTP QUERY yang baru didefinisikan melalui RFC 10008

Dalam API RESTful yang ada, baik GET maupun POST memiliki keterbatasan saat menangani pencarian yang kompleks. Untuk mengatasi hal ini, setelah diskusi panjang, metode QUERY akhirnya distandardisasi.

Keterbatasan GET

• Jika filter kompleks atau kueri relasional dikirim sebagai parameter URL, URL bisa menjadi terlalu panjang dan dapat terkena batas jumlah karakter di browser atau server
• Karakter non-ASCII atau karakter khusus memerlukan encoding sehingga ukuran permintaan bertambah
• Cara merepresentasikan array atau struktur bertingkat belum distandardisasi (contoh: roles[]=admin vs roles=admin)
• Karena server/middleware mencatat parameter URL ke log, ini bisa menjadi masalah saat mengirim data sensitif
• Mengirim badan permintaan pada GET memang tidak secara eksplisit dilarang dalam spesifikasi, tetapi karena proxy/firewall/browser menanganinya secara berbeda, praktiknya hampir tidak dapat digunakan

Masalah pengalihan ke POST

• Badan permintaan memang bisa dikirim, tetapi POST didefinisikan sebagai non-idempotent sehingga retry otomatis saat gagal tidak aman
• Proxy atau middleware tidak dapat mengenali bahwa ini adalah operasi hanya-baca, sehingga optimasi seperti caching otomatis tidak dimungkinkan
• Secara semantik, menggunakan POST yang diperuntukkan bagi pembuatan/pemrosesan resource untuk pencarian tidak sesuai dengan prinsip desain RESTful

Metode QUERY

• Metode HTTP baru yang, seperti GET, bersifat safe dan idempotent, tetapi juga dapat menyertakan badan permintaan
• Dapat di-cache, tetapi saat implementasi badan permintaan harus dimasukkan ke cache key, sehingga implementasi caching lebih kompleks dibanding GET
• Singkatnya, tujuan utamanya adalah "menggantikan POST untuk permintaan hanya-baca"

Hal yang perlu diperhatikan

• Dukungan QUERY di klien/proxy/server masih terbatas, dan mungkin perlu waktu hingga dukungannya benar-benar lengkap
• Jika parameter kueri GET sederhana sudah cukup, tidak perlu memaksakan perubahan
• Jika perlu berbagi URL atau bookmark untuk data yang telah difilter, GET tetap lebih cocok

[jongyeol]

Mengirim body permintaan pada GET memang tidak dilarang secara eksplisit oleh spesifikasi, tetapi karena cara penanganannya berbeda-beda pada tiap proxy/firewall/browser, praktiknya sebenarnya tidak bisa digunakan

Eh... apakah mereka tidak terpikir bahwa selama kira-kira 10 tahun ke depan metode QUERY mungkin juga masih belum akan diterapkan pada tiap proxy/firewall/browser? Atau mungkin ini dibuat dengan pandangan yang sangat jauh ke depan.

[tesha001]

Sepertinya yang terakhir.

[click]

Saya ingat pernah ada masalah pada API layanan sebuah perusahaan yang menerima POST tetapi tidak berfungsi jika parameter URL yang sama tidak ikut diberikan.
Di Korea pun masih cukup sering ada yang bereaksi dengan "ini apaan?" terhadap PUT atau DELETE, jadi saya tidak tahu akan butuh waktu berapa lama sampai QUERY juga benar-benar mapan.

[sea715]

??? : Jangan pakai REST, samakan saja semuanya dengan POST

[savvykang]

???: POST bagus untuk keamanan

[ultimategamer]

Dokumen RFC-nya ada di https://datatracker.ietf.org/doc/rfc10008/.
GET memang punya kekurangan karena URL menjadi panjang, tetapi tampaknya juga punya kelebihan, misalnya saat ingin membagikan hasil filter kueri tertentu di ElasticSearch karena alamat URL-nya bisa dibagikan apa adanya.

Permintaan GET kemungkinan juga banyak dipakai secara implisit dengan asumsi ditulis di bilah alamat browser, jadi sepertinya akan butuh waktu lama untuk benar-benar mapan, lebih dari sekadar dukungan teknis.