QUERY: கடந்த 16 ஆண்டுகளாக நாம் போலித்தனமாகப் பயன்படுத்தி வந்த HTTP முறை
பேக்எண்ட் (Backend) டெவலப்பர்கள் தேடல் முனைகளில் (search endpoints) ஒரு தொடர்ச்சியான சிக்கலை எதிர்கொள்கின்றனர்.
தேடல் என்பது ஒரு வாசிப்பு நடவடிக்கை (read operation) என்பதால் நீங்கள் GET முறையைப் பயன்படுத்த விரும்புகிறீர்கள். ஆனால் உங்கள் தேடல் வடிகட்டிகள் (search filters) மிகவும் பெரிதாகிவிடுகின்றன. உங்கள் URL இரண்டாயிரம் எழுத்துக்களைத் தொடுகிறது. ப்ராக்சிகள் (Proxies) உங்கள் கோரிக்கையைத் துண்டித்துவிடுகின்றன. இதனால் உங்கள் தேடல் தோல்வியடைகிறது.
இந்த வரம்பைச் சரிசெய்ய நீங்கள் POST முறைக்கு மாறுகிறீர்கள். இது வேலை செய்கிறது, ஆனால் இது ஒரு பொய். நீங்கள் தரவை மாற்றுகிறீர்கள் என்று POST ஒவ்வொரு ப்ராக்ஸி மற்றும் கேச் (cache) அமைப்பிற்கும் தெரிவிக்கிறது. இது அனைத்து கேச்சிங் (caching) செயல்பாடுகளையும் நிறுத்திவிடுகிறது. இதனால் GET முறையின் வேகத்தை நீங்கள் இழக்கிறீர்கள்.
பதினாறு ஆண்டுகளாக, எங்களிடம் இடைநிலைத் தீர்வு ஏதும் இல்லை.
ஜூன் 2026-இல், IETF தனது RFC 10008-ஐ வெளியிட்டது. இது QUERY முறையை அறிமுகப்படுத்துகிறது. 2010-ஆம் ஆண்டிற்குப் பிறகு இதுதான் முதல் புதிய HTTP முறையாகும்.
QUERY முறை GET மற்றும் POST ஆகியவற்றின் சிறந்த அம்சங்களை ஒருங்கிணைக்கிறது:
• இது சிக்கலான வடிகட்டிகளுக்காக ஒரு கோரிக்கை உடலை (request body) எடுத்துச் செல்கிறது. • இது பாதுகாப்பானது (safe), அதாவது சர்வர் தனது நிலையை (state) மாற்றாது. • இது ஐடெம்போடென்ட் (idempotent), அதாவது ஒரே முடிவைப் பெற நீங்கள் இதைத் தொடர்ந்து இரண்டு முறை இயக்கலாம். • இது கேச் செய்யக்கூடியது (cacheable), இது CDNs பதில்களைச் சேமிக்க அனுமதிக்கிறது.
ஒரு QUERY கோரிக்கை இவ்வாறு இருக்கும்:
QUERY /products HTTP/1.1 Host: api.shop.example Content-Type: application/json
{ "filter": { "category": "boots", "inStock": true }, "sort": "-price", "limit": 20 }
புதிய RFC, Accept-Query ஹெடரையும் (header) சேர்க்கிறது. இது ஒரு API தான் ஆதரிக்கும் வினவல் வடிவங்களை (query formats) உங்களுக்குத் தெரிவிக்க உதவுகிறது.
டெவலப்பர்களுக்கான ஒரு எச்சரிக்கை:
ஒரு QUERY கோரிக்கையை கேச் செய்வது GET கோரிக்கையிலிருந்து மாறுபட்டது. GET கேச் URL-ஐத் திறவுகோலாக (key) பயன்படுத்துகிறது. QUERY கேச் கோரிக்கை உடலைத் திறவுகோலின் ஒரு பகுதியாகப் பயன்படுத்த வேண்டும். உங்கள் உள்கட்டமைப்பு (infrastructure) இதைச் சரியாகப் புரிந்துகொள்ளவில்லை என்றால், ஒரு பயனர் மற்றொரு பயனரின் தனிப்பட்ட தேடல் முடிவுகளைப் பார்க்க நேரிடும்.
இதைத் தயாரிப்புச் சூழலில் (production) பயன்படுத்த இப்போதே அவசரப்பட வேண்டாம். இந்தத் தொழில்நுட்பச் சூழல் (ecosystem) இதனுடன் இணைந்து செயல்பட இன்னும் கால அவகாசம் தேவைப்படுகிறது.
• பிரவுசர்கள் இன்னும் fetch() இல் QUERY முறையை ஆதரிப்பதில்லை. • HTML படிவங்கள் (forms) GET மற்றும் POST முறைகளை மட்டுமே ஆதரிக்கின்றன. • பல API கேட்வேகள் (gateways) மற்றும் WAF-கள் தெரியாத முறைகளை நிராகரிக்கும்.
உங்கள் API-ஐ QUERY முறையைக் கருத்தில் கொண்டு வடிவமைக்கவும், ஆனால் தற்போதைக்கு உங்கள் POST முனைகளையே (endpoints) தொடரவும்.
QUERY ஒரு நீண்ட சமரசத்திற்கு முற்றுப்புள்ளி வைக்கிறது. இது நெட்வொர்க்கிற்குப் பொய் சொல்லாமல் சிக்கலான கேள்விகளைக் கேட்க அனுமதிக்கிறது.
இந்தத் தொழில்நுட்பச் சூழல் பரவுவதற்காகக் காத்திருக்கிறீர்களா அல்லது இப்போது QUERY முறையைச் சோதித்துப் பார்க்கிறீர்களா?
மூலம்: https://dev.to/arya_koste_5845807df94776/query-the-http-method-weve-been-faking-for-16-years-f9i
