नया HTTP QUERY मेथड

 (kreya.app)
13 पॉइंट द्वारा awbrg789 4 시간 전 | 6 टिप्पणियां | WhatsApp पर शेयर करें

RFC 10008 में नई तरह से परिभाषित HTTP QUERY मेथड का विवरण

मौजूदा RESTful API में जटिल सर्च को संभालते समय GET और POST दोनों की सीमाएँ थीं, और इन्हें हल करने के लिए लंबे समय की चर्चा के बाद QUERY मेथड को मानकीकृत किया गया।

GET की सीमाएँ

  • जटिल फ़िल्टर या relational query को URL parameter के रूप में भेजने पर URL बहुत लंबा हो सकता है, और ब्राउज़र या सर्वर की character limit से टकरा सकता है।
  • non-ASCII अक्षरों या special characters के लिए encoding की ज़रूरत होती है, जिससे request size बढ़ता है।
  • array या nested structure को व्यक्त करने का तरीका मानकीकृत नहीं है (roles[]=admin बनाम roles=admin)।
  • सर्वर/मिडलवेयर URL parameters को log में रिकॉर्ड कर सकते हैं, इसलिए sensitive data भेजने में समस्या हो सकती है।
  • GET में request body भेजना spec में स्पष्ट रूप से प्रतिबंधित नहीं है, लेकिन proxy/firewall/browser के अनुसार इसका व्यवहार अलग होता है, इसलिए व्यवहारिक रूप से इसका उपयोग मुश्किल है।

POST workaround की समस्याएँ

  • request body भेजी जा सकती है, लेकिन POST को non-idempotent के रूप में परिभाषित किया गया है, इसलिए failure की स्थिति में automatic retry सुरक्षित नहीं है।
  • proxy या middleware यह पहचान नहीं पाते कि यह read-only operation है, इसलिए automatic caching जैसी optimization संभव नहीं होती।
  • अर्थ की दृष्टि से resource creation/processing के लिए बने POST का सर्च के लिए उपयोग करना RESTful design principles के अनुरूप नहीं है।

QUERY मेथड

  • GET की तरह safe और idempotent होने के साथ request body शामिल कर सकने वाला नया HTTP मेथड
  • caching संभव है, लेकिन implementation में request body को cache key में शामिल करना पड़ता है, इसलिए GET की तुलना में caching implementation अधिक जटिल है।
  • संक्षेप में, इसका मुख्य उद्देश्य "read-only request में POST का विकल्प" देना है।

ध्यान देने योग्य बातें

  • क्लाइंट/proxy/server में QUERY सपोर्ट अभी सीमित है, और पूर्ण सपोर्ट आने में समय लग सकता है।
  • जहाँ साधारण GET query parameters पर्याप्त हों, वहाँ इसे बदलने की ज़रूरत नहीं है।
  • फ़िल्टर किए गए डेटा के URL sharing या bookmark की ज़रूरत हो तो GET अब भी उपयुक्त है।

संबंधित पढ़ाई

6 टिप्पणियां

 
jongyeol 2 시간 전

GET में request body भेजना स्पेक के हिसाब से साफ़ तौर पर प्रतिबंधित तो नहीं है, लेकिन proxy/firewall/browser के हिसाब से उसका हैंडलिंग तरीका अलग होता है, इसलिए व्यवहार में उसका इस्तेमाल लगभग असंभव है

उम्... क्या उन्होंने यह नहीं सोचा कि proxy/firewall/browser के हिसाब से आने वाले लगभग 10 साल तक QUERY method भी शायद अभी लागू न हो? या फिर उन्होंने बहुत लंबी अवधि को ध्यान में रखकर यह किया होगा?
 
tesha001 20 분 전

मुझे लगता है कि दूसरा वाला होगा।
 
click 3 시간 전

मुझे याद है कि एक कंपनी की service API में ऐसा issue था: वह POST receive करती थी, लेकिन अगर URL parameters बिल्कुल वैसे ही न दिए जाएँ तो काम नहीं करती थी
कोरिया में तो PUT या DELETE पर भी “ये क्या है?” जैसी प्रतिक्रिया काफी देखने को मिलती है; ऐसे में QUERY को adopt होने में कितना समय लगेगा, पता नहीं।
 
sea715 3 시간 전

??? : REST मत करो, बस सब कुछ POST से ही एक जैसा कर दो
 
savvykang 2 시간 전

???: POST security के लिए अच्छा है
 
ultimategamer 57 분 전

RFC दस्तावेज़ https://datatracker.ietf.org/doc/rfc10008/ है।
GET की एक कमी यह भी है कि URL लंबा हो जाता है, लेकिन मुझे लगता है कि इसका एक फायदा यह भी है कि जब आप ElasticSearch के किसी खास search filter के नतीजे शेयर करना चाहते हैं, तो URL को उसी रूप में शेयर किया जा सकता है।

कई जगहों पर GET requests का इस्तेमाल शायद इस अप्रकट मान्यता के साथ होता होगा कि उन्हें browser के address bar में लिखा जाता है, इसलिए इसे व्यापक रूप से अपनाने में तकनीकी support से भी ज़्यादा काफ़ी समय लग सकता है।