नया HTTP SEARCH मेथड
(httptoolkit.tech)-
IETF में नए Draft के रूप में जोड़े गए SEARCH मेथड का परिचय
-
जटिल डेटा प्राप्त करने के लिए सिर्फ मौजूदा GET/POST से काम करना अप्रभावी है
SEARCH /customers HTTP/1.1
Host: example.com
Content-Type: application/sql
SELECT username, email
WHERE DATEDIFF(DAY, GETDATE(), signup_date) > 7
-
वास्तव में SQL स्टेटमेंट को मानक के रूप में इस्तेमाल नहीं किया जा रहा, बल्कि इसका मतलब यह है कि request body में खोज के लिए इस तरह का content रखा जा सकता है
-
इससे एक ही URL के लिए GET, POST, SEARCH तीनों संभव हो जाते हैं
-
Accept-Search header के ज़रिए, खोज में इस्तेमाल होने वाले formats निर्दिष्ट किए जा सकते हैं :
→ Accept-Search: application/sql, application/graphql
- यह WebDAV में मौजूद SEARCH मेथड मानक (rfc5323) पर आधारित है
9 टिप्पणियां
OData लगभग इसी तरह query करने का एक convention है। लेकिन application/sql और application/graphql को एक ही endpoint पर इस्तेमाल किया जा सकता है... यह थोड़ा कल्पना से परे लगता है
मुझे लगता है इसका उपयोग तब हो सकता है जब सीधे SQL चलाना समस्या पैदा करे, और Elasticsearch की तरह semantic रूप से तो यह GET हो, लेकिन HTTP Body के साथ query करना हो.
लेख की शुरुआत में "it was recently adopted as an IETF draft standard" कहा गया है, तो यहाँ recently से क्या 2015 ही मतलब है? मैंने जो draft देखा वह https://tools.ietf.org/html/draft-snell-search-method-00 है, इसलिए सोच रहा था कि क्या इसमें कोई और नया बदलाव हुआ है.
यह https://datatracker.ietf.org/doc/… है.
लगता है कि इसे हाल ही में 2021-03-31 को अपलोड किया गया था।
अगर body में जानकारी भेजनी हो तो PUT या POST इस्तेमाल करना पड़ेगा.
लेकिन इनमें cache इस्तेमाल नहीं किया जा सकता, इसलिए
SEARCH जैसी चीज़ भी इस्तेमाल की जा सकती है.
वैसे भी इसे सिर्फ accept किए जाने पर ही भेजना होगा.
ऐसा लगता है कि get, post की असुविधाओं को बेहतर करने की दिशा में सोचते हुए graphql याद आता है
जब क्वेरी को request body में भेजना शुरू करते हैं, तो ऐसा लगता है कि कभी न कभी (अगर साइट बिना ज़्यादा सोचे-समझे बनाई गई हो) SQL Injection जैसी समस्या आ सकती है..
इसे body वाले GET की तरह समझा जा सकता है। वैसे भी body का validation तो करना ही पड़ेगा...
सही कहा..