For sixteen years, developers who needed to ask complex questions of a server have been stuck with a workaround. When a

பதினாறு ஆண்டுகளாக, ஒரு சேவையகத்திடம் (server) சிக்கலான கேள்விகளைக் கேட்க வேண்டிய டெவலப்பர்கள் ஒரு மாற்று வழியிலேயே (workaround) சிக்கித் தவித்தனர். ஒரு தேடல் பேலோட் (search payload) URL-க்கு மிகப்பரியதாக மாறும்போது, அல்லது நெஸ்டட் ஃபில்டர்கள் (nested filters) மற்றும் முக்கியமான அளவுருக்கள் (sensitive parameters) ஒரு குயரி ஸ்ட்ரிங்கிற்குள் (query string) பொருந்தாதபோது, POST மட்டுமே நடைமுறைச் சாத்தியமான ஒரே வழியாக இருந்தது. அது பைட்டுகளைக் (bytes) கடத்தியது, ஆனால் அதன் நோக்கத்தைப் பற்றி பொய் சொன்னது. POST என்பது ஒரு நிலையை மாற்றியமைப்பதைக் (change of state) குறிக்கிறது. ஒரு 'read-only' செயல்பாட்டிற்கு இதைப் பயன்படுத்துவது, கேச்சுகள் (caches), ப்ராக்சிகள் (proxies) மற்றும் பிரவுசர்கள் (browsers) உள்ளிட்ட முழு நெட்வொர்க் பாதையையும், ஒரு சாதாரணத் தேடலைத் தரவுத்தளத்தை (database) மாற்றியமைக்கக்கூடிய ஒன்று போலக் கருதச் செய்தது.

அந்த சமரசம் இறுதியாக முடிவுக்கு வந்தது. ஜூன் 2026-இல், IETF ஆனது RFC 10008-ஐ வெளியிட்டது, இது QUERY முறையை முறைப்படி தரப்படுத்துகிறது (standardizing). 2010-இல் PATCH அறிமுகப்படுத்தப்பட்டதிலிருந்து இதுவே முதல் புதிய HTTP முறையாகும். QUERY என்பது ஒரு பாடி (body) தேவைப்படும் பாதுகாப்பான மற்றும் ஐடெம்போடென்ட் (idempotent) கோரிக்கைகளுக்காகவே (requests) பிரத்யேகமாக உருவாக்கப்பட்டுள்ளது. இது சேவையக நிலையை (server state) மாற்றாது. ஒரே கோரிக்கையைத் திரும்பத் திரும்பச் செய்வதன் மூலம் ஒரே முடிவு கிடைக்கும். இது கேச் செய்யக்கூடியது (cacheable), அதாவது இடைத்தரகர்கள் (intermediaries) பதிலைத் சேமித்து மீண்டும் பயன்படுத்த முடியும். மேலும் GET முறையைப் போலல்லாமல், இது POST முறையைப் போலவே ஒரு தரவு பேலோடை (data payload) அனுமதிக்கிறது.

GraphQL குயரிகள் மற்றும் சிக்கலான REST தேடல் எண்ட்பாயிண்ட்கள் (endpoints) இதன் மிகப்பெரிய பயனாளிகள். நீங்கள் இனி அறுபது குயரி அளவுருக்களை (query parameters) ஒரு URL-க்குள் திணிக்கவோ அல்லது இடைத்தரகர்கள் கேச் செய்ய மறுக்கும் ஒரு POST பாடியின் உள்ளே JSON ஃபில்டர் ஆவணத்தை மறைத்து வைக்கவோ தேவையில்லை. இதன் பொருண்மையியல் (semantics) இப்போது நேர்மையானதாக உள்ளது.

ஆனால் ஒரு RFC என்பது வெறும் மை மட்டுமே. உங்கள் பயன்பாட்டிற்கும் (application) பயனர்களுக்கும் இடையில் ஒரு பெரிய உள்கட்டமைப்பு அடுக்கு (infrastructure layer) உள்ளது, அதில் பெரும்பாலானவை QUERY என்பதைப் பற்றி கேள்விப்பட்டதே இல்லை.

கேச்சிங் பிரச்சனை இன்னும் தீர்க்கப்படவில்லை

ஒரு GET கோரிக்கையில், கேச்சிங் (caching) மிகவும் எளிமையானது. கேச் கீ (cache key) என்பது URI ஆகும். ஹெடர்கள் (headers) அனுமதித்தால், ஒரே URL-ஐ அணுகும் இரண்டு பயனர்களும் சேமிக்கப்பட்ட அதே பதிலைப் பெறுவார்கள்.

QUERY அந்த மாதிரியை உடைக்கிறது, ஏனெனில் கோரிக்கை அளவுருக்கள் (request parameters) பாடியில் (body) உள்ளன. இரண்டு கோரிக்கைகள் ஒன்றுதான் என்பதை ஒரு கேச் அடையாளம் காண வேண்டுமானால், கேச் கீ என்பது URI மற்றும் பாடி உள்ளடக்கம் ஆகிய இரண்டையும் கொண்டிருக்க வேண்டும். இந்தத் தேவை உண்மையான செயல்பாட்டுத் தடைகளை (operational friction) ஏற்படுத்துகிறது.

முதலாவதாக, எட்ஜ் சர்வர்கள் (edge servers) மற்றும் CDNs ஒரு ஹாஷைக் (hash) கணக்கிடுவதற்கு முன் முழு கோரிக்கை பாடியையும் பஃபர் (buffer) செய்ய வேண்டும். இது எட்ஜ் நோடில் (edge node) நினைவகம் மற்றும் நேரத்தை எடுத்துக் கொள்கிறது. இரண்டாவதாக, தர்க்கரீதியாக (logically) ஒரே மாதிரியான இரண்டு குயரிகள் ஒரே மாதிரியான பைட்டுகளை உருவாக்காமல் போகலாம். ஒரு கிளையண்ட் {"status":"active"} என்று அனுப்பலாம், மற்றொரு கிளையண்ட் வெவ்வேறு இடைவெளிகள் (whitespace) அல்லது கீ வரிசைமுறைடன் (key ordering) {"status": "active"} என்று அனுப்பலாம். கேச்சிங் அடுக்கு பாடியைப் பகுப்பாய்வு செய்து (parse), இயல்பாக்கி (normalize), மற்றும் தரப்படுத்தாவிட்டால் (canonicalize) — அதாவது JSON கீகளை வரிசைப்படுத்துதல், தேவையற்ற வடிவமைப்புகளை நீக்குதல் மற்றும் என்கோடிங் வேறுபாடுகளைக் கையாளுதல் — அதே கேள்வி ஒவ்வொரு முறையும் கேச்-ஐத் தவறவிடும்.

மிக முக்கியமாக, பிரபலமான CDNs இன்னும் QUERY-க்காக கோரிக்கை பாடியின் அடிப்படையில் கேச்-ஐப் பிரிக்கவில்லை. உதாரணமாக, Cloudflare தற்போது இந்த முறையைப் பயன்படுத்தும்போது பாடியை கேச் கீயின் ஒரு பகுதியாகக் கருதவில்லை. 'cacheable' என்பது 'cached' என்று கருதி நீங்கள் QUERY-ஐப் பயன்படுத்தினால், மோதல் பிழைகள் (collision errors), பொதுவான கேச் மிஸ்கள் (cache misses), அல்லது தொடர்பில்லாத கோரிக்கைகளுக்கு இடையே பதில்கள் கசிவது போன்றவற்றை நீங்கள் காணலாம். உங்கள் சேவை வழங்குநர் (provider) இதற்கான நேரடி ஆதரவை வெளியிடும் வரை, தயாரிப்புச் சூழலில் (production) QUERY என்பது பயனுள்ள வகையில் கேச் செய்யக்கூடியது அல்ல என்று கருதுங்கள்.

உங்கள் கருவிகளே முதலில் அதைத் தடுக்கக்கூடும்

ஒவ்வொரு HTTP கோரிக்கையும் பல மிட்ல்பாக்ஸ்களின் (middleboxes) அடுக்குகளைக் கடந்து செல்கிறது, அவற்றில் பெரும்பாலானவை எந்த முறைகள் சட்டபூர்வமானவை என்பது குறித்த கடுமையான விதிகளைப் பின்பற்றுகின்றன.

Web Application Firewalls மற்றும் API கேட்வேகள் (gateways) பெரும்பாலும் தெளிவான அனுமதிக்கப்பட்ட பட்டியலை (allowlists) நம்பியிருக்கின்றன. ஒரு பொதுவான விதிகளின்படி GET, POST, PUT, DELETE மற்றும் PATCH ஆகியவை அனுமதிக்கப்படுகின்றன. மற்றவை அனைத்தும் நிராகரிக்கப்படும் அல்லது 405 Method Not Allowed என்ற பதிலுடன் அனுப்பப்படும். QUERY உங்கள் பயன்பாட்டு குறியீட்டை (application code) சென்றடைவதற்கு முன்பே அந்தத் தடைகளைச் சந்திக்கும்.

பாதுகாப்பு விதி இயந்திரங்கள் (Security rule engines) மற்றொரு தடையைச் சேர்க்கின்றன. சில ஊடுருவல் கண்டறிதல் அமைப்புகள் (intrusion detection systems) ஒரு பாடியைக் கொண்டு வரும் கோரிக்கையை