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

तो तडजोडचा काळ अखेर संपला आहे. जून २०२६ मध्ये, IETF ने RFC 10008 प्रकाशित केले, ज्याद्वारे QUERY मेथडला अधिकृतपणे प्रमाणित करण्यात आले. २०१० मध्ये PATCH सादर केल्यापासून ही पहिली नवीन HTTP मेथड आहे. QUERY ही विशेषतः अशा सुरक्षित आणि idempotent विनंत्यांसाठी (requests) आहे ज्यांना बॉडीची (body) आवश्यकता असते. हे सर्व्हरची स्टेट बदलत नाही. तीच विनंती पुन्हा केल्यास तेच निकाल मिळतात. हे कॅशे करण्यायोग्य (cacheable) आहे, याचा अर्थ मध्यवर्ती घटक (intermediaries) प्रतिसाद साठवू शकतात आणि पुन्हा वापरू शकतात. आणि GET च्या उलट, हे POST प्रमाणेच डेटा पेलोडची परवानगी देते.

GraphQL क्वेरीज आणि जटिल REST सर्च एंडपॉइंट्स (endpoints) हे याचे सर्वात मोठे लाभार्थी आहेत. तुम्हाला आता साठ क्वेरी पॅरामीटर्स एका URL मध्ये कोंबण्याची किंवा एखादा JSON फिल्टर डॉक्युमेंट POST बॉडीमध्ये लपवण्याची गरज नाही, जो मध्यवर्ती घटक कॅशे करण्यास नकार देऊ शकतात. आता सिमेंटिक्स (semantics) पारदर्शक आहेत.

पण RFC म्हणजे केवळ कागदावरची शाई आहे. तुमच्या ॲप्लिकेशन आणि वापरकर्त्यांच्या मध्ये इन्फ्रास्ट्रक्चरचा एक मोठा थर असतो, आणि त्यातील बहुतांश घटकांना QUERY बद्दल काहीही माहिती नाही.

कॅशिंगची समस्या अजून सुटलेली नाही

GET विनंतीमध्ये, कॅशिंग करणे सोपे असते. कॅशे की (cache key) ही URI असते. जर हेडर्स परवानगी देत असतील, तर एकाच URL वर येणारे दोन वापरकर्ते तेच साठवलेले प्रतिसाद मिळवतात.

QUERY हे मॉडेल मोडीत काढते कारण विनंतीचे पॅरामीटर्स बॉडीमध्ये असतात. दोन विनंत्या सारख्याच आहेत हे कॅशेने ओळखण्यासाठी, कॅशे कीमध्ये URI आणि बॉडी कंटेंट (body content) या दोन्हीचा समावेश असणे आवश्यक आहे. ही आवश्यकता प्रत्यक्ष कार्यान्वित करताना अडचणी निर्माण करते.

पहिले म्हणजे, एज सर्व्हर्स आणि CDNs ला हॅश (hash) मोजण्यापूर्वी संपूर्ण रिक्वेस्ट बॉडी बफर करावी लागते. यामुळे एज नोडवर मेमरी आणि वेळ खर्च होतो. दुसरे म्हणजे, तार्किकदृष्ट्या (logically) समान असलेल्या दोन क्वेरीजचे बाइट्स सारखे नसू शकतात. एक क्लायंट {"status":"active"} पाठवू शकतो, तर दुसरा वेगळ्या व्हाईटस्पेस (whitespace) किंवा की ऑर्डरिंगसह (key ordering) {"status": "active"} पाठवू शकतो. जोपर्यंत कॅशिंग लेअर बॉडीचे पार्सिंग (parsing), नॉर्मलायझेशन (normalization) आणि कॅनोनिकलायझेशन (canonicalization) करत नाही—जसे की JSON कीज सॉर्ट करणे, अनावश्यक फॉरमॅटिंग काढून टाकणे आणि एन्कोडिंगमधील फरक हाताळणे—तोपर्यंत तीच क्वेरी प्रत्येक वेळी कॅशे मिस (cache miss) करेल.

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

तुमचे टूल्स कदाचित आधीच याला ब्लॉक करतील

प्रत्येक HTTP विनंती मध्यवर्ती साधनांच्या (middleboxes) थरातून जाते आणि त्यातील बहुतेक साधने कोणत्या मेथड्स कायदेशीर आहेत याबद्दल कडक नियम लागू करतात.

Web Application Firewalls आणि API गेटवे अनेकदा स्पष्ट अलाऊलिस्टवर (allowlists) अवलंबून असतात. एक सामान्य नियमसंच GET, POST, PUT, DELETE आणि PATCH ला परवानगी देतो. इतर काहीही असल्यास ते ड्रॉप केले जाते किंवा '405 Method Not Allowed' असा प्रतिसाद दिला जातो. QUERY तुमच्या ॲप्लिकेशन कोडपर्यंत पोहोचण्यापूर्वीच या भिंतींना धडकले जाईल.

सिक्युरिटी रूल इंजिन्स आणखी एक अडथळा निर्माण करतात. काही इंट्रुजन डिटेक्शन सिस्टम्स (intrusion detection systems) असे मानतात की बॉडी असलेली विनंती