नए HTTP QUERY मेथड की व्याख्या

मूल लेख ↗ Hacker News चर्चा ↗

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 फिर भी आसान नहीं होगी।