- एक नया HTTP method, QUERY, प्रस्तावित किया गया है
- यह एक request method है जिसमें request के समय content भेजा जा सकता है, और जो safe तथा idempotent है
- जब request में भेजा जाने वाला data इतना बड़ा हो कि उसे URI में encode न किया जा सके, तब इस तरीके का उपयोग किया जा सकता है
- जब query parameters कुछ KB से बड़े होते हैं, तो कई implementations उन पर सीमा लगाती हैं
- अक्सर request से पहले इस सीमा का पता नहीं होता, और encode करना पड़ता है, इसलिए यह अप्रभावी है
- इसलिए कई implementations query चलाने के लिए GET की जगह POST का उपयोग करती हैं
- लेकिन server के बारे में विशेष जानकारी न हो तो यह पता नहीं चलता कि वह safe और idempotent है या नहीं, इसलिए GET जैसी मूलभूत सीमाएँ बनी रहती हैं
- QUERY method, GET और POST के उपयोग के बीच की खाई को भरने वाला समाधान देता है
- POST की तरह, query operation के लिए input request URI के हिस्से के रूप में नहीं बल्कि request के content में भेजा जाता है
- लेकिन POST के विपरीत, यह method स्पष्ट रूप से safe और idempotent है, इसलिए caching और automatic retry जैसी सुविधाएँ संभव हैं
Request
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv
select surname, givenname, email limit 10
Response
HTTP/1.1 200 OK
Content-Type: text/csv
Content-Location: /contacts/responses/42
Location: /contacts/queries/17
surname, givenname, email
Smith, John, john.smith@example.org
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
7 टिप्पणियां
मुझे समझ नहीं आता कि इसे protocol में जोड़ने की ज़रूरत क्यों है।
क्या ऐसे scenario सच में इतने ज़्यादा हैं जहाँ query parameters कुछ KB से बड़े हो जाते हैं?
https://www.baeldung.com/cs/http-get-with-body
ऐसा लगता है कि HTTP स्पेक इतना अस्पष्ट रहा है कि पाठक अपनी-अपनी व्याख्या कर सकते हैं, और यह इतना असंगत तरीके से बदलता रहा है कि अब शायद एक बिल्कुल नया method बनाने की नौबत आ गई है।
रिक्वेस्ट बॉडी के साथ GET
कुछ client libraries में GET रिक्वेस्ट करते समय request body भेजने का तरीका ही नहीं होता, तो यह उसका एक विकल्प हो सकता है।
लाइब्रेरी implementation के नज़रिए से देखें तो क्या यह बल्कि और भी ज़्यादा अनावश्यक standard change proposal नहीं है?
standard spec के मुताबिक GET में request body नहीं हो सकती, लेकिन लाइब्रेरी मनमाने तरीके से request body भेज रही है...
अगर ऐसा ही है, तो क्या सिर्फ़ लाइब्रेरी लेयर पर custom method implement कर देना भी काफ़ी नहीं होगा?
इसकी आवश्यकता को पूरी तरह नकारना मुश्किल है, लेकिन HTTP 1.0 से 1.1 में जाते समय जो PUT, PATCH, DELETE आदि आए थे, उनकी तुलना में यह कम persuasive लगता है.
https://www.rfc-editor.org/rfc/rfc9110.html#name-method-definitions
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET
https://stackoverflow.com/questions/978061/http-get-with-request-body
https://elastic.co/guide/en/…
मानक spec में GET Method के लिए body वाले हिस्से को स्पष्ट रूप से निर्दिष्ट नहीं किया गया है, लेकिन यह कभी नहीं कहा गया कि इसे शामिल नहीं करना चाहिए।
कुछ server frameworks में GET Method पर body को प्रोसेस नहीं किया जाता, इसलिए MDN GET Method में body न डालने की सलाह देता है।
Elasticsearch GET Method में Body को support करता है
मुझे लगता है कि अगर किसी लाइब्रेरी implementation की वजह से spec बदलनी पड़े, तो उस पर और गहराई से विचार करने की ज़रूरत है।