RFC 10008: नया HTTP Query Method

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

एक नया HTTP method QUERY मानकीकृत किया जा रहा है ताकि बड़े, जटिल parameters वाले read-only requests को request body में संभाला जा सके, जिससे URL लंबाई की पुरानी सीमाएँ और search या GraphQL queries जैसे safe, idempotent operations के लिए POST के awkward उपयोग की समस्या हल हो। समर्थक caching, automatic retries, और स्पष्ट semantics के लाभ बताते हैं, खासकर यदि browsers, CDNs, और HTML forms समर्थन जोड़ें। आलोचक पूछते हैं कि क्या नया verb जोड़ना ecosystem-wide churn के लायक है, और कहते हैं कि GET bodies को standardize करना या POST में headers जोड़ना वही समस्याएँ कम compatibility और implementation चुनौतियों के साथ हल कर सकता था।

QUERY का उद्देश्य और अर्थ

  • QUERY को “body के साथ GET” के रूप में पेश किया गया है: read-only, safe, और idempotent।
  • मुख्य लक्ष्य: जटिल/बड़े queries (जैसे GraphQL, rich filters, images) को URL लंबाई सीमाओं के बिना सपोर्ट करना।
  • इसका उपयोग केवल data retrieval के लिए है; semantics GET जैसी हैं, लेकिन request parameters body में रहते हैं।

Caching, Idempotency, और Safety

  • क्योंकि QUERY safe और idempotent है, intermediaries और clients इसे POST के विपरीत, अपने-आप cache और retry कर सकते हैं।
  • caching keys पर बहस:
    • चिंता: पूरे body को cache key बनाने से unbounded, user-controlled keys और complexity (ordering, normalization, hashing) पैदा होती है।
    • जवाब: यह optional है; caches body को hash कर सकते हैं, या बेहतर यह कि servers एक छोटा Location URL वापस करें जिसे फिर GET के जरिए cache किया जा सके।
  • logging और quotas जैसी side effects को HTTP semantic level पर “ignored” माना जाता है, ठीक GET की तरह।

GET-with-body बनाम नया Method

  • कुछ लोगों का तर्क है कि spec को बस GET body standardize करनी चाहिए।
  • अन्य लोग कहते हैं कि बहुत-से proxies/servers GET bodies को ignore, drop, या reject करते हैं, और इसे लंबे समय से discouraged किया गया है, इसलिए semantics को retroactively जोड़ना unsafe है।
  • नया method silent mangling से बचाता है: unsupported QUERY आम तौर पर साफ़ तरीके से fail होगा (जैसे 405), बजाय data discard करने के।

Intermediaries और Compatibility

  • चिंता: कई middleboxes ऐतिहासिक रूप से unknown methods या ऐसे किसी भी method-with-body को गलत तरीके से handle करते हैं जिसे वे समझते नहीं।
  • व्यापक gateway/CDN support के बिना, कुछ मामलों में POST plus custom headers ही व्यावहारिक विकल्प रहता है।
  • QUERY को CORS से भी निपटना होगा: अभी यह safelisted नहीं है, इसलिए browser preflight करते हैं, भले ही यह safe हो।

Use Cases और Developer Reactions

  • सुझाए गए उपयोग: बड़े GraphQL queries, complex search filters, dry-run बनाम commit patterns (QUERY फिर POST), database-like queries, event streams के साथ streaming AI queries।
  • कुछ लोग इसे “POST /search” hacks के लिए एक साफ़ semantic fix मानते हैं और HTTP के method model से बेहतर मेल मानते हैं।
  • Skeptics इसे overkill मानते हैं: अतिरिक्त complexity, नया plumbing, और फिर एक और nuance जो developers को सीखना होगा, जबकि समस्या GET/POST से पहले ही “काफ़ी अच्छी” तरह हल हो रही थी।

HTML Forms, Bookmarks, और UX

  • HTML forms में method="query" में रुचि है ताकि “resubmit POST data” warnings से बचा जा सके और safe operations के साथ बेहतर mapping मिले।
  • forms को और HTTP verbs (PUT/DELETE/etc.) इस्तेमाल करने देने की व्यापक इच्छा है, ताकि human interactions REST semantics से मेल खाएँ।
  • चिंता यह है कि यदि query parameters body में हों तो bookmarking मुश्किल हो सकता है; server-generated GET URLs जैसी mitigations पर चर्चा की गई है।

Naming और Conceptual Debates

  • कुछ लोगों को “QUERY” शब्द existing “query string” terminology के कारण भ्रमित करने वाला लगता है।
  • कुछ का तर्क है कि HTTP verbs को business semantics encode नहीं करनी चाहिए; वे इसे REST-चालित overdesign मानते हैं; जबकि अन्य जवाब देते हैं कि HTTP ने हमेशा methods से semantics जोड़ी हैं।