RFC 10008: नया HTTP Query Method

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

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 जोड़ी हैं।