नए HTTP QUERY मेथड की व्याख्या
एक नया standardised HTTP method, QUERY, read requests के लिए complex request bodies भेजने का safe, idempotent, cacheable तरीका देने का लक्ष्य रखता है—कुछ ऐसा जिसके लिए डेवलपर्स लंबे समय से GET with bodies या queries के लिए POST का दुरुपयोग करते रहे हैं। टिप्पणीकार इस पर बहस करते हैं कि नया verb जोड़ना बेहतर है या GET पर bodies को औपचारिक रूप से अनुमति देना, और मौजूदा proxies, CDNs, WAFs, तथा browsers की समस्याओं को रेखांकित करते हैं जो GET bodies को strip या गलत संभालते हैं, साथ ही request payload के आधार पर caching की चुनौतियों को भी। कई लोगों को search, GraphQL, और बड़े या संवेदनशील filters के लिए स्पष्ट उपयोग-मामले दिखते हैं, लेकिन मौजूदा HTTP infrastructure में adoption धीमी और असमान रहने की उम्मीद है।
QUERY किस समस्या को हल करने के लिए है
- इसे “बॉडी वाला GET” को औपचारिक रूप देने के रूप में देखा जाता है: सुरक्षित, idempotent, cacheable, लेकिन request body ले सकता है।
- इसका उद्देश्य GET-with-body या queries के लिए POST जैसे जुगाड़ों को बदलना है (जैसे search, GraphQL queries)।
- समर्थकों के अनुसार यह intermediaries के लिए semantics स्पष्ट करता है: “इसे cache किया जा सकता है, यह read-only है, और इसमें body है।”
GET को ही क्यों नहीं ठीक करें?
- एक पक्ष: बस GET-with-body को standardize कर दें; QUERY अनावश्यक “XKCD standards” की फालतू बढ़ोतरी है।
- जवाब में: कई मौजूदा proxies, WAFs, CDNs, और frameworks GET bodies को strip या reject कर देते हैं, या उन्हें अर्थहीन मानते हैं।
- GET semantics बदलने से legacy systems में undefined behavior पैदा होगा; एक नया method 405 के साथ साफ़ तौर पर fail हो सकता है और POST पर fallback की अनुमति दे सकता है।
- कुछ लोग कहते हैं कि दोनों रास्तों में infrastructure अपडेट तो करना ही पड़ेगा; उनके लिए QUERY तकनीकी ज़रूरत से ज़्यादा marketing है।
Compatibility, Middleboxes, और Browsers
- चिंता है कि खराब तरीके से maintained “black box” middlewares नए verbs को गलत संभाल सकते हैं या crash कर सकते हैं।
- दूसरे कहते हैं कि legacy gear के बावजूद standards को evolve करना होगा; broken infra को ठीक किया जाना चाहिए।
- कई लोगों का कहना है कि browsers जल्द QUERY implement नहीं करेंगे (या कम से कम इसकी गारंटी नहीं है); इससे web-facing adoption सीमित रहती है।
- Accept-Query header और OPTIONS/405 को support negotiate करने के mechanisms के रूप में उद्धृत किया गया है।
प्रस्तावित उपयोग के मामले
- Elastic/OpenSearch जैसे search APIs अभी GET-with-body या POST का दुरुपयोग करते हैं; QUERY उनके लिए natural fit होगा।
- GraphQL: read-only queries के लिए QUERY, mutations के लिए POST।
- web apps में complex filtering/search: लंबे query strings की बजाय JSON bodies।
- reverse image search और अन्य file- या binary-based queries।
Caching, Semantics, और REST
- QUERY को cacheable और idempotent परिभाषित किया गया है; इससे POST के विपरीत CDN/proxy caching संभव होती है।
- संदेह करने वाले practical cache keys की ओर इशारा करते हैं: bodies का कोई standard canonical form नहीं है (JSON ordering, whitespace), जिससे shared caches जटिल हो जाती हैं।
- कुछ लोग कहते हैं कि QUERY REST/CRUD की स्पष्टता बढ़ाता है, क्योंकि यह simple GET-by-URL को अधिक complex queries से अलग करता है; दूसरे कहते हैं कि आप queries को resources के रूप में model कर सकते हैं (create के लिए POST, फिर GET)।
Security, WAFs, और व्यावहारिक दर्द-बिंदु
- कई लोग ऐसे वास्तविक-world systems का उल्लेख करते हैं जो GET bodies को reject या strip कर देते हैं (WAFs, CloudFront, strict API gateways)।
- QUERY को इन undefined behaviors और उन security rules से बचने का तरीका माना जाता है जो GET-with-body को संदिग्ध मानती हैं।
- अन्य लोग चेतावनी देते हैं कि शुरुआत में ऐसे systems QUERY को भी support नहीं करेंगे, इसलिए migration फिर भी आसान नहीं होगी।