सोलह वर्षों से, जिन डेवलपर्स को सर्वर से जटिल प्रश्न पूछने की आवश्यकता होती थी, वे एक वर्कअराउंड (workaround) के साथ अटके हुए थे। जब एक सर्च पेलोड (search payload) URL के लिए बहुत बड़ा हो जाता था, या जब नेस्टेड फ़िल्टर (nested filters) और संवेदनशील पैरामीटर (sensitive parameters) क्वेरी स्ट्रिंग (query string) के भीतर फिट होने से इनकार कर देते थे, तो एकमात्र व्यावहारिक विकल्प POST था। इसने बाइट्स (bytes) तो ले लिए, लेकिन इसके इरादे (intent) के बारे में झूठ बोला। POST स्टेट में बदलाव (change of state) का संकेत देता है। इसे केवल पढ़ने (read-only) के ऑपरेशन के लिए उपयोग करने से पूरे नेटवर्क पाथ—कैश (caches), प्रॉक्सी (proxies), और ब्राउज़र (browsers)—को एक साधारण लुकअप (lookup) के साथ ऐसा व्यवहार करने के लिए मजबूर होना पड़ता था जैसे कि वह डेटाबेस को बदल सकता है।

वह समझौता आखिरकार समाप्त हो गया है। जून 2026 में, IETF ने RFC 10008 प्रकाशित किया, जिससे QUERY मेथड को औपचारिक रूप से मानकीकृत (standardizing) किया गया। 2010 में PATCH के आने के बाद से यह पहला नया HTTP मेथड है। QUERY विशेष रूप से उन सुरक्षित, आइडम्पोटेंट (idempotent) अनुरोधों के लिए है जिन्हें बॉडी (body) की आवश्यकता होती है। यह सर्वर स्टेट को नहीं बदलता है। एक ही अनुरोध को दोहराने से समान परिणाम प्राप्त होता है। यह कैश करने योग्य (cacheable) है, जिसका अर्थ है कि इंटरमीडियरीज़ (intermediaries) रिस्पॉन्स को स्टोर और पुन: उपयोग कर सकते हैं। और GET के विपरीत, यह POST की तरह ही डेटा पेलोड की अनुमति देता है।

GraphQL क्वेरीज़ और जटिल REST सर्च एंडपॉइंट्स (endpoints) इसके सबसे स्पष्ट विजेता हैं। अब आपको साठ क्वेरी पैरामीटर्स को एक URL में ठूँसने या POST बॉडी के अंदर एक JSON फ़िल्टर डॉक्यूमेंट छिपाने की आवश्यकता नहीं है, जिसे इंटरमीडियरीज़ कैश करने से मना कर देंगे। अब सिमेंटिक्स (semantics) ईमानदार हैं।

लेकिन एक RFC केवल स्याही है। आपके एप्लिकेशन और आपके उपयोगकर्ताओं के बीच इंफ्रास्ट्रक्चर की एक मोटी परत है, और इसमें से अधिकांश ने QUERY के बारे में कभी नहीं सुना है।

कैशिंग की समस्या अभी हल नहीं हुई है

GET अनुरोध के साथ, कैशिंग सीधी और सरल है। कैश की (cache key) URI है। यदि हेडर अनुमति देते हैं, तो एक ही URL पर जाने वाले दो उपयोगकर्ताओं को एक ही स्टोर किया गया रिस्पॉन्स मिलता है।

QUERY उस मॉडल को तोड़ देता है क्योंकि अनुरोध पैरामीटर (request parameters) बॉडी में होते हैं। कैश द्वारा यह पहचानने के लिए कि दो अनुरोध समान हैं, कैश की (cache key) में URI और बॉडी कंटेंट दोनों को शामिल करना होगा। यह आवश्यकता वास्तविक परिचालन घर्षण (operational friction) पैदा करती है।

सबसे पहले, एज सर्वर (edge servers) और CDNs को हैश (hash) की गणना करने से पहले पूरी रिक्वेस्ट बॉडी को बफर (buffer) करना होगा। इसमें एज नोड (edge node) पर मेमोरी और समय लगता है। दूसरा, दो तार्किक रूप से समान (logically identical) क्वेरीज़ समान बाइट्स उत्पन्न नहीं कर सकती हैं। एक क्लाइंट {"status":"active"} भेज सकता है जबकि दूसरा अलग व्हाइटस्पेस या की ऑर्डरिंग (key ordering) के साथ {"status": "active"} भेज सकता है। जब तक कैशिंग लेयर बॉडी को पार्स (parse), नॉर्मलाइज़ (normalize) और कैनोनिकलाइज़ (canonicalize) नहीं करती—जैसे JSON कीज़ को सॉर्ट करना, महत्वहीन फॉर्मेटिंग को हटाना और एन्कोडिंग अंतरों को संभालना—तब तक एक ही प्रश्न हर बार कैश को मिस कर देगा।

सबसे महत्वपूर्ण बात यह है कि मुख्यधारा के CDNs अभी QUERY के लिए रिक्वेस्ट बॉडी के आधार पर कैश को विभाजित (partition) नहीं करते हैं। उदाहरण के लिए, Cloudflare अपने वर्तमान स्वरूप में इस मेथड के लिए बॉडी को कैश की (cache key) के हिस्से के रूप में नहीं मानता है। यदि आप यह मानकर QUERY तैनात करते हैं कि कैश करने योग्य (cacheable) का अर्थ कैश किया हुआ (cached) है, तो आप कोलिजन एरर (collision errors), यूनिवर्सल कैश मिस (universal cache misses), या ऐसे रिस्पॉन्स देख सकते हैं जो असंबंधित अनुरोधों के बीच लीक हो जाते हैं। जब तक आपका प्रदाता स्पष्ट समर्थन प्रकाशित नहीं करता, तब तक मान लें कि प्रोडक्शन में QUERY सार्थक रूप से कैश करने योग्य नहीं है।

आपके टूल्स शायद इसे सबसे पहले ब्लॉक करेंगे

प्रत्येक HTTP अनुरोध मिडलबॉक्स (middleboxes) के एक स्टैक से होकर गुजरता है, और उनमें से अधिकांश इस बारे में सख्त नियम लागू करते हैं कि कौन से मेथड वैध हैं।

Web Application Firewalls और API गेटवे अक्सर स्पष्ट अलालिस्ट (allowlists) पर निर्भर करते हैं। एक विशिष्ट नियमसेट GET, POST, PUT, DELETE, और PATCH की अनुमति देता है। इसके अलावा कुछ भी ड्रॉप कर दिया जाता है या 405 Method Not Allowed के साथ उत्तर दिया जाता है। QUERY आपके एप्लिकेशन कोड तक पहुँचने से पहले ही उन दीवारों से टकरा जाएगा।

सुरक्षा नियम इंजन (Security rule engines) एक और बाधा उत्पन्न करते हैं। कुछ घुसपैठ का पता लगाने वाली प्रणालियाँ (intrusion detection systems) मानती हैं कि बॉडी ले जाने वाला एक अनुरोध