เป็นเวลาสิบหกปีที่นักพัฒนาที่ต้องการส่งคำถามที่ซับซ้อนไปยังเซิร์ฟเวอร์ต้องใช้วิธีแก้ปัญหาแบบชั่วคราว เมื่อเพย์โหลดการค้นหามีขนาดใหญ่เกินกว่าที่ URL จะรับได้ หรือเมื่อฟิลเตอร์แบบซ้อนกันและพารามิเตอร์ที่ละเอียดอ่อนไม่สามารถบรรจุลงใน query string ได้ ทางเลือกเดียวที่ใช้งานได้จริงคือ POST แม้ว่ามันจะสามารถส่งข้อมูล (bytes) ได้ แต่มันกลับบิดเบือนเจตนา เพราะ POST ส่งสัญญาณถึงการเปลี่ยนแปลงสถานะ การใช้ POST สำหรับการทำงานแบบอ่านอย่างเดียว (read-only) บังคับให้เส้นทางเครือข่ายทั้งหมด—ทั้งแคช, พร็อกซี และเบราว์เซอร์—ต้องปฏิบัติกับการค้นหาที่ไม่มีพิษมีภัยราวกับว่ามันอาจจะไปเปลี่ยนแปลงฐานข้อมูล

ข้อจำกัดนั้นได้สิ้นสุดลงแล้ว ในเดือนมิถุนายน 2026 IETF ได้เผยแพร่ RFC 10008 ซึ่งกำหนดมาตรฐานของเมธอด QUERY อย่างเป็นทางการ นี่คือเมธอด HTTP ใหม่เมธอดแรกนับตั้งแต่มีการนำ PATCH มาใช้ในปี 2010 โดย QUERY ถูกสร้างขึ้นมาเพื่อการร้องขอที่ปลอดภัยและมีคุณสมบัติ idempotent ที่จำเป็นต้องมี body โดยเฉพาะ มันไม่เปลี่ยนแปลงสถานะของเซิร์ฟเวอร์ การส่งคำขอเดิมซ้ำๆ จะให้ผลลัพธ์แบบเดิมเสมอ นอกจากนี้ยังสามารถทำแคชได้ (cacheable) ซึ่งหมายความว่าตัวกลางต่างๆ สามารถจัดเก็บและนำการตอบกลับมาใช้ใหม่ได้ และต่างจาก GET ตรงที่มันอนุญาตให้มี data payload ได้เหมือนกับ POST

การคิวรี GraphQL และ REST search endpoints ที่ซับซ้อนคือกลุ่มที่ได้รับประโยชน์สูงสุด คุณไม่จำเป็นต้องยัดพารามิเตอร์การคิวรีถึงหกสิบตัวลงใน URL หรือซ่อนเอกสาร JSON filter ไว้ใน body ของ POST ที่ตัวกลางต่างๆ จะปฏิเสธการทำแคชอีกต่อไป ตอนนี้ความหมายเชิง semantics นั้นตรงไปตรงมาและซื่อสัตย์แล้ว

แต่ RFC เป็นเพียงตัวอักษรเท่านั้น ระหว่างแอปพลิเคชันของคุณและผู้ใช้งานจะมีชั้นของโครงสร้างพื้นฐานที่หนาแน่นวางกั้นอยู่ และส่วนใหญ่ไม่เคยได้ยินชื่อ QUERY มาก่อนเลย

ปัญหาเรื่องการทำแคชยังไม่ได้รับการแก้ไข

สำหรับการร้องขอแบบ GET การทำแคชนั้นตรงไปตรงมา โดยใช้ URI เป็นคีย์ของแคช (cache key) ผู้ใช้สองคนที่เรียก URL เดียวกันจะได้รับข้อมูลที่จัดเก็บไว้เหมือนกัน หาก header อนุญาต

QUERY ทำลายโมเดลนั้นเพราะพารามิเตอร์ของการร้องขออยู่ใน body เพื่อให้แคชรับรู้ว่าการร้องขอสองรายการนั้นเหมือนกัน คีย์ของแคชจะต้องรวมทั้ง URI และเนื้อหาใน body เข้าด้วยกัน ข้อกำหนดนี้ทำให้เกิดความยุ่งยากในการดำเนินงาน (operational friction) อย่างแท้จริง

ประการแรก Edge servers และ CDNs ต้องรอรับ (buffer) เนื้อหา body ทั้งหมดของการร้องขอก่อนที่จะสามารถคำนวณค่าแฮช (hash) ได้ ซึ่งต้องใช้ทั้งหน่วยความจำและเวลาที่ edge node ประการที่สอง การคิวรีที่เหมือนกันในเชิงตรรกะอาจไม่ได้สร้าง bytes ที่เหมือนกัน ลูกค้าคนหนึ่งอาจส่ง {"status":"active"} ในขณะที่อีกคนส่ง {"status": "active"} ซึ่งมีช่องว่าง (whitespace) หรือการเรียงลำดับคีย์ที่ต่างกัน หากเลเยอร์การทำแคชไม่ทำการ parse, normalize และ canonicalize เนื้อหาใน body—เช่น การเรียงลำดับคีย์ JSON, การตัดรูปแบบที่ไม่สำคัญออก และการจัดการความแตกต่างของการเข้ารหัส (encoding)—การถามคำถามเดิมก็จะพลาดแคชไปทุกครั้ง

ที่สำคัญที่สุดคือ CDNs กระแสหลักยังไม่ทำการแบ่งส่วนแคช (partition cache) ตาม request body สำหรับ QUERY ตัวอย่างเช่น Cloudflare ยังไม่ปฏิบัติกับ body เป็นส่วนหนึ่งของ cache key สำหรับเมธอดนี้ในรูปแบบปัจจุบัน หากคุณใช้งาน QUERY โดยทึกทักเอาเองว่า cacheable หมายถึงมีการทำแคชไว้แล้ว คุณอาจพบข้อผิดพลาดจากการชนกันของข้อมูล (collision errors), การพลาดแคชทั้งหมด (universal cache misses) หรือการตอบกลับที่รั่วไหลข้ามไปยังคำขอที่ไม่เกี่ยวข้องกัน จนกว่าผู้ให้บริการของคุณจะประกาศการรองรับอย่างชัดเจน ให้สันนิษฐานไว้ก่อนว่า QUERY ยังไม่สามารถทำแคชได้อย่างมีประสิทธิภาพในสภาพแวดล้อมการทำงานจริง (production)

เครื่องมือของคุณอาจจะเป็นสิ่งแรกที่บล็อกมัน

ทุกการร้องขอ HTTP จะต้องผ่านชั้นของ middleboxes และส่วนใหญ่จะบังคับใช้กฎที่เข้มงวดว่าเมธอดใดบ้างที่อนุญาตให้ใช้ได้

Web Application Firewalls และ API gateways มักจะพึ่งพา allowlists ที่ระบุไว้อย่างชัดเจน ชุดกฎทั่วไปจะอนุญาตให้ใช้ GET, POST, PUT, DELETE และ PATCH เท่านั้น อะไรก็ตามที่นอกเหนือจากนี้จะถูกตัดทิ้งหรือตอบกลับด้วย 405 Method Not Allowed ซึ่ง QUERY จะชนกำแพงเหล่านี้ก่อนที่จะไปถึงโค้ดแอปพลิเคชันของคุณเสียอีก

เครื่องมือตรวจสอบกฎความปลอดภัย (Security rule engines) ยังเป็นอีกหนึ่งอุปสรรค ระบบตรวจจับการบุกรุก (intrusion detection systems) บางระบบสันนิษฐานว่าการร้องขอที่มี body