புதிய HTTP QUERY முறை: Body உடைய ஒரு GET கோரிக்கை

1996 முதல் இணையத்தின் முதுகெலும்பாக HTTP இருந்து வருகிறது. ஏறத்தாழ மூன்று தசாப்தங்களில், அடிப்படை முறைகளான — GET, POST, PUT, DELETE, PATCH — கிட்டத்தட்ட மாறவே இல்லை. உருவாக்குநர்கள் அவற்றின் மேல் REST API-களின் முழு சாம்ராஜ்யங்களையே கட்டியெழுப்பினர். பெரும்பாலான பயன்பாடுகளுக்கு, அவை நன்றாகவே செயல்படுகின்றன.

ஆனால் ஒரு இடைவெளி இருந்து வருகிறது. ஒவ்வொரு API உருவாக்குநரும் ஏதேனும் ஒரு கட்டத்தில் எதிர்கொள்ளும் ஒரு அமைப்பியல் சார்ந்த, எரிச்சலூட்டும், சில சமயங்களில் ஆபத்தான இடைவெளி: தரவைத் தேட வேண்டியிருக்கும் போது, அத்தேடலே சிக்கலானதாக இருந்தால் நீங்கள் என்ன செய்வீர்கள்?

ஜூலை 17, 2026 அன்று, அந்த இடைவெளிக்கு இறுதியாக ஒரு அதிகாரப்பூர்வ பதில் கிடைத்துள்ளது. ஜூன் 15, 2026 அன்று தரப்படுத்தப்பட்டு, RFC 9148-இல் முறைப்படி வரையறுக்கப்பட்ட QUERY HTTP முறையானது, மிகவும் நீண்ட காலத்திற்குப் பிறகு HTTP முறை குடும்பத்தில் சேர்க்கப்பட்ட முதல் புதிய உறுப்பினராகும். மேலும் இது GET மற்றும் POST ஆகியவற்றால் ஒருபோதும் தெளிவாகக் கையாள முடியாத ஒரு உண்மையான பிரச்சனையைத் தீர்க்கிறது.

பிரச்சனை: GET-ஆல் சிக்கலான தேடல்களைக் கையாள முடியாது

தரவைப் பெறுவதில் GET-தான் முதன்மைப் பணியாளராக உள்ளது. நீங்கள் ஒரு URL-ஐ அணுகுகிறீர்கள், சேவையகம் உங்களுக்குத் தரவை வழங்குகிறது. எளிமையானது, தெளிவானது, cache செய்யக்கூடியது. நேரடித் தேடல்களுக்கு — "எனக்கு பயனர் 42-ஐக் கொடு" அல்லது "வெளியிடப்பட்ட அனைத்துப் பதிவுகளையும் பட்டியலிடு" — GET மிகவும் சிறந்தது.

ஆனால் நவீன பயன்பாடுகள் எப்போதும் எளிமையான கேள்விகளைக் கேட்பதில்லை.

நீங்கள் ஒரு பகுப்பாய்வு (analytics) டேஷ்போர்டை உருவாக்குகிறீர்கள் என கற்பனை செய்து பாருங்கள். ஒரு பயனர் பன்னிரண்டு வெவ்வேறு அளவுகோல்களின்படி வடிகட்ட விரும்புகிறார்: தேதி வரம்புகள், உள்ளமைக்கப்பட்ட (nested) புவியியல் பகுதிகள், குறிப்பிட்ட தயாரிப்பு பிரிவுகள், பூலியன் தருக்கத்துடன் கூடிய பயனர் பிரிவுகள் மற்றும் ஒரு இலவச-உரைத் தேடல் வினவல் (free-text search query). அந்த வடிகட்டித் தொகுதி எளிதாக 1,000 பைட்களைத் தாண்டிவிடும்.

இங்குதான் GET முடங்குகிறது. GET கோரிக்கையில் உள்ள அனைத்தும் URL-இல் மட்டுமே இருக்கும். மேலும் URL-களுக்கு நடைமுறை நீள வரம்புகள் உள்ளன. உலாவிகள் அவற்றைக் கட்டுப்படுத்துகின்றன, பிராக்ஸிகள் அவற்றைச் சுருக்குகின்றன, சேவையகங்கள் நிராகரிக்கின்றன. சேவையகங்கள் குறைந்தது 8,000 பைட்களையாவது கையாள வேண்டும் என்று RFC 2616 பரிந்துரைக்கிறது, ஆனால் பல நிஜ உலகப் பயன்பாடுகள் அதற்கு முன்பாகவே திணறுகின்றன.

மிக மோசமானது என்னவென்றால், அந்த URL அளவுகோல்கள் எல்லா இடங்களிலும் பதிவிடப்படுகின்றன (logged). உலாவி வரலாறு முழு URL-ஐயும் சேமிக்கிறது. பிராக்ஸி சேவையகங்கள் அதை cache செய்கின்றன. சேவையக அணுகல் பதிவுகள் (access logs) அதைச் சேமித்து வைக்கின்றன. உங்கள் தேடலில் உணர்திறன் வாய்ந்த தரவு — ஒரு நோயாளியின் ID, சமூகப் பாதுகாப்பு எண் துண்டு, அல்லது ஒரு உள் கணக்கு குறிப்பு — இருந்தால், அந்தத் தகவல் இப்போது நீங்கள் கட்டுப்படுத்தாத பல அமைப்புகளில் சாதாரண உரையாக (plain text) அமர்ந்திருக்கிறது.

இது ஒரு தத்துவார்த்த கவலை அல்ல. இது ஒரு உண்மையான இணக்கத்தன்மை (compliance) தலைவலி.

பிரச்சனை: POST என்பது ஒரு பொய்

எனவே உருவாக்குநர்கள் எப்போதும் செய்வதையே செய்கிறார்கள் — வரம்பைச் சுற்றி ஒரு குறுக்குவழியைக் கண்டுபிடிக்கிறார்கள். "POST-ஐப் பயன்படுத்துங்கள்," என்று கோட் ரிவ்யூவில் யாரோ கூறுகிறார்கள். "நீங்கள் ஒரு POST கோரிக்கையில் JSON body-ஐ வைக்கலாம், மேலும் body URL-இல் போய் சேராது."

தொழில்நுட்ப ரீதியாக உண்மை. ஆனால் பொருள் ரீதியாக (semantically) தவறானது.

தரவை மாற்றுவதற்காகவே POST வடிவமைக்கப்பட்டுள்ளது. இது சேவையகத்திடம் சொல்கிறது: "நான் உங்களுக்கு ஒன்றை அனுப்புகிறேன் — ஒரு வளத்தை உருவாக்கவும், ஒரு செயல்முறையைத் தூண்டவும், அல்லது ஏதேனும் நிலையை (state) மாற்றவும்." HTTP விவரக்குறிப்புகள் சொல்வது அதைத்தான். வெப் அப்ளிகேஷன் ஃபயர்வால்கள் (WAF) எதிர்பார்ப்பதும் அதைத்தான். சேவையகக் கட்டமைப்புகள் (frameworks) அனுமானிப்பதும் அதைத்தான்.

தரவைத் தேட நீங்கள் POST-ஐப் பயன்படுத்தும்போது, தொழில்நுட்ப அடுக்கில் (stack) உள்ள ஒவ்வொரு அடுக்கிற்கும் நீங்கள் பொய் சொல்கிறீர்கள்.

இது வெறும் தத்துவார்த்த சுத்தம் மட்டுமே அல்ல. இதன் விளைவுகள் உண்மையானவை:

• Caching பாதிக்கப்படுகிறது. பெரும்பாலான HTTP cache-கள் — CDN-கள், ரிவர்ஸ் பிராக்ஸிகள், உலாவி cache-கள் — இயல்பாகவே POST பதில்களை cache செய்யாது, ஏனெனில் POST என்பது சேவையகத்தின் நிலை மாறியிருக்கலாம் என்பதால் ஒவ்வொரு முறையும் பதில் வேறுபடலாம் என்பதைக் குறிக்கிறது.
• எதேச்சையான பக்க விளைவுகள். சில சேவையகக் கட்டமைப்புகளும் மிடில்வேர்களும் POST-ஐ வேறு விதமாகக் கையாள்கின்றன. அவை தணிக்கைப் பதிவுகளில் (audit logs) எழுதலாம், வெப்ஹூக்குகளைத் தூண்டலாம், அல்லது வெவ்வேறு வீத-வரம்பு (rate-limiting) விதிகளைப் பயன்படுத்தலாம் — இவை அனைத்தும் உங்கள் "தேடல்" இறுதிப்புள்ளி (endpoint) ஒரு "உருவாக்கும்" இறுதிப்புள்ளி போலத் தெரிவதால்தான்.
• CSRF ஆபத்து அதிகரிக்கிறது. POST இறுதிப்புள்ளிகள் வேறுபட்ட குறுக்கு-மூல (cross-origin) பாதுகாப்புப் பொருள் கூறுகளைக் கொண்டுள்ளன. POST-ஐப் பயன்படுத்தும் ஒரு தேடல் இறுதிப்புள்ளிக்கு இப்போது CSRF பாதுகாப்பு தேவைப்படுகிறது, இது GET இறுதிப்புள்ளிக்குத் தேவைப்பட்டிருக்காது.
• மீண்டும் முயல்வது (Retries) ஆபத்தானதாக மாறுகிறது. ஒரு கோரிக்கை காலாவதியானால் (timeout), கிளையன்ட்கள் GET-ஐப் பாதுகாப்பாக மீண்டும் முயற்சிக்கலாம் (இது idempotent ஆகும்). POST-ஐ மீண்டும் முயற்சிப்பது போலிப் பதிவுகளை (duplicate records) உருவாக்கக்கூடும் — மேலும் உங்கள் "தேடல்" இறுதிப்புள்ளி எதையும் உருவாக்கக்கூடாது.

இந்தப்பொறுந்தாமை பல ஆண்டுகளாக பிழைகள், பாதுகாப்பு பலவீனங்கள் மற்றும் கட்டமைப்புச் சங்கடங்களுக்குக் காரணமாக இருந்து வருகிறது. GraphQL, அதன் அனைத்துப் பலன்களுடனும், இதை மேலும் பொதுவானதாக்கியது — பெரும்பாலான GraphQL அமலாக்கங்கள் வினவல்களை POST கோரிக்கைகளாகவே அனுப்புகின்றன, அதாவது GraphQL API-இல் உள்ள ஒவ்வொரு வாசிப்பு செயல்பாடும் (read operation) ஒரு எழுத்து செயல்பாட்டின் (write operation) பொருளியல் சுமையைச் சுமக்கிறது.

QUERY அறிமுகம்: பணிக்கு ஏற்ற சரியான கருவி

QUERY முறை என்பது பெயருக்கு ஏற்றவாறே உள்ளது: body-ஐ ஆதரிக்கும் ஒரு GET கோரிக்கை.

இதை வேறுபடுத்துவது எது என்பது இங்கே:

இது பாதுகாப்பானது மற்றும் வாசிப்புக்கு மட்டும் (read-only) உரியது. QUERY முறையானது பாதுகாப்பான, idempotent செயல்பாடாக வரையறுக்கப்பட்டுள்ளது. ஒரே QUERY கோரிக்கையைத் தொடர்ந்து பத்து முறை அனுப்பினாலும், சேவையகத்தில் பூஜ்ஜிய பக்க விளைவுகளுடன் அதே முடிவுதான் கிடைக்கும். எந்தத் தரவும் உருவாக்கப்படாது, நிலை மாறாது, தணிக்கைப் பாதைகள் (audit trails) எதேச்சையாகத் தூண்டப்படாது.

இது ஒரு கோரிக்கை body-ஐ ஆதரிக்கிறது. POST போலவே, உங்கள் API பயன்படுத்தும் கட்டமைப்புத் தரவை — JSON, XML அல்லது எதுவாக இருந்தாலும் — கோரிக்கை body-இல் சேர்க்கலாம். உங்கள் சிக்கலான தேடல் வடிகட்டிகள், உள்ளமைக்கப்பட்ட பொருள்கள் மற்றும் பல-கிலோபைட் தரவுச்சுமைகள் (payloads) முற்றிலும் URL-க்கு வெளியே அமைகின்றன.

இது தெளிவான நோக்கத்தைச் சமிக்ஞை செய்கிறது. ஒரு சேவையகம் QUERY கோரிக்கையைப் பெறும்போது, கிளையன்ட் என்ன விரும்புகிறது என்பதில் எந்தக் குழப்பமும் இல்லை. அது தரவைப் படிக்க விரும்புகிறது. அவ்வளவுதான். இந்த POST ஒரு தேடலா அல்லது உருவாக்கும் செயல்பாடா என்று சேவையகம் யூகிக்க வேண்டிய அவசியமில்லை.

இது இயல்பாகவே cache செய்யக்கூடியது. POST மாற்று வழிகளைப் போலல்லாமல், QUERY முறையானது சரியான caching பொருளியலுடன் HTTP நெறிமுறை அடுக்கில் செயல்படுகிறது. Cache-களும் CDN-களும் QUERY பதில்களை cache செய்ய முடியும், ஏனெனில் இந்த முறை சேவையக நிலையை மாற்றாது என்று வெளிப்படையாக அறிவிக்கிறது — இதை POST ஒருபோதும் உத்தரவாதம் செய்ய முடியாது.

இந்தக் கடைசிப் புள்ளியை வலியுறுத்துவது அவசியம். GraphQL சிக்கலான வடிகட்டுதலை அழகாகக் கையாள்கிறது, ஆனால் அது பயன்பாட்டு அடுக்கில் (application layer) செயல்படுகிறது. பெரும்பாலான GraphQL வினவல்கள் POST கோரிக்கைகளாகப் பயணிக்கின்றன, மேலும் சேவையகங்கள் பொதுவாக POST பதில்களை இயல்பாக cache செய்வதில்லை. QUERY முறையானது போக்குவரத்து அடுக்கில் (transport layer) செயல்படுகிறது, அதாவது சிறப்பு பயன்பாட்டு-மட்ட உள்ளமைவு எதுவுமின்றி HTTP உள்கட்டமைப்புகள் — பிராக்ஸிகள், CDN-கள், லோட் பேலன்சர்கள் — caching-இல் பங்கேற்க முடியும்.

ஒரு QUERY கோரிக்கை எப்படி இருக்கும்

நீங்கள் எப்போதாவது ஒரு HTTP கோரிக்கையை எழுதியிருந்தால், இது உங்களுக்குப் பரிச்சயமானதாக இருக்கும்:

QUERY /api/analytics/events HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json

{
  "dateRange": {
    "start": "2026-01-01",
    "end": "2026-06-30"
  },
  "filters": {
    "regions": ["us-west-2", "eu-central-1"],
    "eventTypes": ["purchase", "refund"],
    "minAmount": 50.00
  },
  "groupBy": ["region", "month"],
  "limit": 100
}

அவ்வளவுதான். URL சுத்தமாக இருக்கிறது. Body அனைத்துச் சிக்கல்களையும் தாங்கிச் செல்கிறது. மேலும் HTTP உள்கட்டமைப்பின் ஒவ்வொரு பகுதியும் இந்தக் கோரிக்கை ஒரு வாசிப்பு செயல்பாடு என்பதை அறிந்து கொள்கிறது.

பாதுகாப்புக் கோணம்: புதிய முறை, புதிய தாக்குதல் பரப்பு

இங்குதான் விஷயங்கள் சுவாரசியமாகவும் — சற்றே பயமுறுத்துவதாகவும் மாறுகின்றன.

QUERY முறையானது சிக்கலான வாசிப்புகளுக்கான GET மற்றும் POST-இன் அமைப்பியல் சிக்கல்களைத் தீர்க்கிறது. ஆனால் இணையத்தின் உள்கட்டமைப்பில் ஒரு புதிய HTTP முறையை அறிமுகப்படுத்துவது தாக்குபவர்களுக்கும் பாதுகாப்பு ஆராய்ச்சியாளர்களுக்கும் ஒரு குறிப்பிடத்தக்க புதிய விளையாட்டு மைதானத்தைத் திறந்துவிடுகிறது.

Caching சிக்கலானதாக மாறுகிறது

QUERY cache செய்யக்கூடியது, மேலும் இது ஒரு body-ஐக் கொண்டுள்ளது. இந்தச் சேர்க்கை பெரும்பாலான HTTP உள்கட்டமைப்புகளுக்குப் புதியது.

பாரம்பரிய caching முறையானது URL மற்றும் சில தலைப்புகளைத் (headers) தான் cache சாவியாகப் (cache key) பயன்படுத்துகிறது. QUERY பயன்பாட்டில், சேவையகங்களும் பிராக்ஸிகளும் கோரிக்கையின் body-ஐயும் cache சாவியில் சேர்க்க வேண்டும். ஒரு cache அமலாக்கம் இதைத் தவறாகச் செய்தால் — அதாவது URL-ஐ மட்டுமே சாவியாகக் கொண்டு body-ஐ புறக்கணித்தால் — வெவ்வேறு பயனர்களின் தேடல் முடிவுகள் ஒருவருக்கொருவர் கசியக்கூடும்.

மிக மோசமாக, கோரிக்கையின் body-இல் உள்ள உணர்திறன் வாய்ந்த தரவு cache பதிவுகள் அல்லது debug வெளியீடுகளில் முடிந்தால், நீங்கள் ஒரு பதிவுப் பிரச்சனைக்கு (அணுகல் பதிவுகளில் URL அளவுகோல்கள்) பதிலாக மற்றொரு பதிவுப் பிரச்சனையைப் (cache debug பதிவுகளில் கோரிக்கை body-கள்) பரிமாறிக்கொண்டீர்கள் என்று அர்த்தம்.

பாரம்பரிய பலவீனங்கள், புதிய வழிகள் (Vectors)

ஒவ்வொரு புதிய HTTP முறையும் இருக்கும் பலவீனப் பிரிவுகளுக்குப் புதிய வாய்ப்புகளை அறிமுகப்படுத்துகிறது:

• உள்ளீட்டு சரிபார்ப்புத் (Input validation) தோல்விகள். உங்கள் WAF, POST body-களைச் சரிபார்ப்பது போலவே QUERY கோரிக்கை body-களையும் சரிபார்க்கிறதா? இல்லையெனில், ஒரு தாக்குபவர் உங்கள் பாதுகாப்புகளைத் தாண்டி தீங்கிழைக்கும் தரவுச்சுமைகளை (malicious payloads) கடத்தக்கூடும்.
• வீத வரம்புப் (Rate limiting) இடைவெளிகள். உங்கள் வீத வரம்பி (rate limiter) GET மற்றும் POST கோரிக்கைகளைக் கணக்கிட்டு, QUERY பற்றி அறியாமல் இருந்தால், தாக்குபவர்களுக்கு இலவசக் கோரிக்கைகள் கிடைக்கும்.
• CSRF மற்றும் CORS குழப்பம். உலாவிகளும் கட்டமைப்புகளும் QUERY-இன் குறுக்கு-மூலப் (cross-origin) பொருளியலை சரியாகக் கையாள வேண்டும். ஆரம்பக்கட்ட ஏற்பு கட்டத்தில், தவறான அமைப்புகள் (misconfigurations) ஏற்படுவது நிச்சயம்.
• HTTP கோரிக்கை கடத்தல் (request smuggling). QUERY-ஐப் புரிந்துகொள்ளாத லோட் பேலன்சர்களும் ரிவர்ஸ் பிராக்ஸிகளும் கோரிக்கைகளைத் தவறாகப் பகுப்பாய்வு செய்து, ஒரு கோரிக்கை எங்கு முடிகிறது, அடுத்தது எங்கு தொடங்குகிறது என்பதில் ஃப்ரண்ட்-எண்ட் மற்றும் பேக்-எண்ட் இடையே வேறுபாட்டை உருவாக்கி, கடத்தலுக்கான (smuggling) வாய்ப்புகளை உருவாக்கலாம்.
• முறைப் (Method) குழப்பம். ஒரு WAF அல்லது மிடில்வேர் அறியப்படாத முறையைக் கண்டு, இயல்புநிலைக் கையாளியிடம் (default handler) சென்றால், அது முற்றிலும் தவறான பாதுகாப்புக் கொள்கையைப் பயன்படுத்தக்கூடும்.

இவை தத்துவார்த்த அபாயங்கள் அல்ல. HTTP/2 அறிமுகப்படுத்தப்பட்டபோதும், WebSockets வந்தபோதும், பிற முக்கிய நெறிமுறை மாற்றங்கள் தயாரிப்பு உள்கட்டமைப்பை அடைந்தபோதும் தோன்றிய அதே வகை பிழைகளே இவை. இந்த முறை நன்கு அறியப்பட்டது: கருவிகள் மேம்படும் வரை புதிய நெறிமுறை அம்சங்கள் தற்காலிக பாதுகாப்பு இடைவெளிகளை உருவாக்குகின்றன.

ஏற்பு நிலை எங்குள்ளது

2026 இன் நடுப்பகுதி நிலவரப்படி, ஏற்பு அதன் ஆரம்பக் கட்டத்தில் உள்ளது:

• உலாவிகள் ஆதரவைச் சேர்க்கத் தொடங்கியுள்ளன, ஆனால் அது இன்னும் உலகளாவியதாக மாறவில்லை.
• வெப் அப்ளிகேஷன் ஃபயர்வால்கள் (WAF) QUERY கோரிக்கைகளை அடையாளம் கண்டு சரியாக வடிகட்டுவதற்காகத் தங்கள் விதித் தொகுப்புகளைப் புதுப்பித்து வருகின்றன.
• CDN-கள் QUERY-க்கான body-அறிந்த caching ஆதரவை அறிமுகப்படுத்தி வருகின்றன, ஆனால் அமைப்புகள் வேறுபடுகின்றன.
• API கட்டமைப்புகள் — Express, FastAPI, Spring, ASP.NET — தங்கள் சமீபத்திய வெளியீடுகளில் QUERY கையாளிகளைச் சேர்க்கின்றன.
• HTTP கிளையன்ட் நூலகங்கள் QUERY கோரிக்கைகளை அனுப்புவதை ஆதரிக்கும் வகையில் புதுப்பிக்கப்பட்டு வருகின்றன.

முழுமையான, பரவலான ஏற்புக்குக் காலம் எடுக்கும். இது நெறிமுறை சார்ந்த மாற்றமாகும், அதாவது தொழில்நுட்ப அடுக்கின் ஒவ்வொரு நிலையும் — உலாவி முதல் CDN, ரிவர்ஸ் பிராக்ஸி, பயன்பாட்டுக் கட்டமைப்பு மற்றும் WAF வரை — புதிய முறையைப் புரிந்துகொள்ள வேண்டும்.

இப்போது நீங்கள் என்ன செய்ய வேண்டும்

நீங்கள் ஒரு பேக்-எண்ட் உருவாக்குநர் அல்லது API வடிவமைப்பாளர் என்றால்:

1. RFC-ஐப் படியுங்கள். RFC 9148 என்பது அதிகாரப்பூர்வ விவரக்குறிப்பாகும். நீங்கள் அமல்படுத்துவதற்கு முன் அதன் பொருளியலைப் புரிந்து கொள்ளுங்கள்.
2. உங்கள் உள்கட்டமைப்பைத் தணிக்கை செய்யுங்கள். உங்கள் ரிவர்ஸ் பிராக்ஸி, லோட் பேலன்சர் மற்றும் WAF ஆகியவை QUERY கோரிக்கைகளைச் சரியாக அனுமதிக்கின்றனவா என்பதைச் சரிபார்க்கவும். பல பழைய அமைப்புகள் அறியப்படாத HTTP முறைகளை இயல்பாகவே தடுக்கின்றன.
3. தயாரிப்புக்கு (production) அவசரப்பட வேண்டாம். உள் API-கள் அல்லது உருவாக்கச் சூழல்களிலிருந்து (dev environments) தொடங்குங்கள். பொது இணையத்திற்கு QUERY இறுதிப்புள்ளிகளை வெளிப்படுத்துவதற்கு முன் உங்கள் கருவிகள் முதிர்ச்சியடைய விடுங்கள்.
4. உங்கள் caching உத்தியைப் புதுப்பியுங்கள். நீங்கள் QUERY பதில்களை cache செய்ய திட்டமிட்டால், உங்கள் cache சாவிகளில் URL மட்டுமல்லாமல் கோரிக்கை body-இன் ஹேஷும் (hash) சேர்க்கப்பட்டுள்ளதை உறுதிப்படுத்திக் கொள்ளுங்கள்.
5. உங்கள் பாதுகாப்புக் கட்டுப்பாடுகளைச் சோதிக்கவும். வீத வரம்பு, உள்ளீட்டு சரிபார்ப்பு, CORS மற்றும் அங்கீகாரம் (authentication) ஆகியவை QUERY உடன் சரியாகச் செயல்படுகின்றனவா என்பதைச் சரிபார்க்கவும் — அவை செயல்படும் என்று அனுமானிக்க வேண்டாம்.

நீங்கள் ஒரு பாதுகாப்பு ஆராய்ச்சியாளராக இருந்தால், இது ஒரு மிகப்பெரிய வாய்ப்பாகும். ஒரு புதிய HTTP முறை தயாரிப்பு உள்கட்டமைப்பை அடைவது என்பது எல்லா இடங்களிலும் புதிய தாக்குதல் பரப்பு உருவாகிறது என்பதாகும். இப்போது QUERY பற்றிய ஆய்வைத் தொடங்குங்கள், ஏனெனில் ஆரம்பக்கட்ட ஏற்பின் போது தோன்றும் பிழைகள் பெரும்பாலும் அதிக தாக்கத்தை ஏற்படுத்துபவைகளாக இருக்கும்.

பெரிய படம் (பரந்த பார்வை)

QUERY முறை என்பது ஒரு புரட்சி அல்ல. அது ஒரு திருத்தம். 26 ஆண்டுகளாக, உருவாக்குநர்கள் எந்தவொரு முறைக்காகவும் வடிவமைக்கப்படாத ஒரு காரியத்திற்கு GET மற்றும் POST-ஐப் பயன்படுத்தி வந்தனர் — மேலும் பாதுகாப்பு பிழைகள், caching தோல்விகள் மற்றும் கட்டமைப்புச் சங்கடங்கள் வடிவத்தில் அதற்கான விலையைக் கொடுத்து வந்தனர்.

QUERY முறை GET-ஐ மாற்றுவதில்லை. அது POST-ஐயும் மாற்றுவதில்லை. பல ஆண்டுகளுக்கு முன்பே நிரப்பப்பட்டிருக்க வேண்டிய ஒரு இடைவெளியை இது நிரப்புகிறது: கோரிக்கை body-ஐ ஆதரிக்கும் பாதுகாப்பான, வாசிப்புக்கு மட்டுமேயான HTTP முறை.

நெறிமுறை அதிகாரப்பூர்வமானது. RFC வெளியிடப்பட்டுவிட்டது. சுற்றுச்சூழல் மாறிவருகிறது. நீங்கள் API-களை உருவாக்கினாலும், உள்கட்டமைப்பை வலுப்படுத்தினாலும், அல்லது பலவீனங்களைத் தேடினாலும் — QUERY முறை என்பது நீங்கள் புரிந்துகொள்ள வேண்டிய ஒன்றாகும்.

இணையத்திற்கு ஒரு புதிய வினைச்சொல் கிடைத்துள்ளது. அதை ஞானமாகப் பயன்படுத்துங்கள்.

நன்மைகள்

• URL நீள வரம்புகளைத் தீர்க்கிறது: சிக்கலான தேடல் தரவுச்சுமைகள் (payloads) URL-இலிருந்து கோரிக்கை body-க்கு மாறுகின்றன — இனி சுருக்கம் (truncation) இருக்காது
• பாதுகாப்பு மேம்பாடு: உணர்திறன் மிக்க தேடல் அளவுகோல்கள் இனி உலாவி வரலாறு, அணுகல் பதிவுகள் மற்றும் பிராக்ஸி cache-களில் கசியாது
• சரியான பொருளியல்: சேவையகங்கள், மிடில்வேர்கள் மற்றும் WAF-கள் யூகிக்காமல் வாசிப்புகளை எழுத்துக்களிலிருந்து வேறுபடுத்தி அறிய முடியும்
• இயல்பான cache செய்யும் திறன்: HTTP உள்கட்டமைப்பு QUERY பதில்களை cache செய்ய முடியும் — POST மாற்று வழிகளைப் போலல்லாமல்
• Idempotent மற்றும் பாதுகாப்பானது: மீண்டும் முயல்வது பாதிப்பற்றது, இது விநியோகிக்கப்பட்ட அமைப்புகளில் (distributed systems) பிழைக் கையாளதலை எளிதாக்குகிறது
• நெறிமுறை சார்ந்த தீர்வு: GraphQL போன்ற பயன்பாட்டு-மட்ட மாற்று வழிகள் தேவையின்றி அனைத்து REST API-களிலும் செயல்படுகிறது

குறைபாடுகள்

• புதிய தாக்குதல் பரப்பு: கடத்தல் (smuggling), முறை குழப்பம், CSRF மற்றும் CORS சிக்கல்களுக்கு புதிய வழிகளை அறிமுகப்படுத்துகிறது
• Caching சிக்கல்: Cache அமலாக்கங்கள் கோரிக்கை body-ஐ சாவிகளில் சேர்க்க வேண்டும் — தவறான அமைப்பு தரவைக் கசியவிடும்
• மெதுவான ஏற்பு: இறுதி-முதல்-இறுதி (end-to-end) வரை நம்பகத்தன்மையுடன் செயல்பட உலாவிகள், CDN-கள், WAF-கள் மற்றும் கட்டமைப்புகள் அனைத்தும் புதுப்பிக்கப்பட வேண்டும்
• கருவிகளின் இடைவெளிகள்: பிழைதிருத்தக் (Debugging) கருவிகள், கண்காணிப்பு டேஷ்போர்டுகள் மற்றும் பதிவு பகுப்பாய்விகள் (log parsers) இன்னும் QUERY-ஐக் கையாளாமல் இருக்கலாம்
• உள்கட்டமைப்புத் தடைகள்: பழைய reverse proxies மற்றும் load balancers, QUERY கோரிக்கைகளை அமைதியாக நிராகரிக்கலாம் அல்லது கைவிடலாம்
• போலியான பாதுகாப்பு உணர்வு: URL-களில் இருந்து அளருருக்களை (parameters) மாற்றுவது லாகிங் (logging) அபாயங்களை நீக்குவதில்லை — உடற்பகுதிகளும் (bodies) லாக் செய்யப்படலாம்

எச்சரிக்கை

இந்தக் கட்டுரை, ஜூன் 2026-இல் தரப்படுத்தப்பட்டு RFC 9148-இல் வரையறுக்கப்பட்டுள்ள QUERY HTTP முறையைப் பற்றி விவாதிக்கிறது. உலாவி (browser) ஆதரவு, ஃப்ரேம்வொர்க் (framework) ஆதரவு மற்றும் உள்கட்டமைப்பு பொருந்தக்கூடிய தன்மை (infrastructure compatibility) ஆகியவை வேகமாக வளர்ச்சியடைந்து வருகின்றன. CDN முதல் WAF மற்றும் அப்ளிகேஷன் ஃப்ரேம்வொர்க் வரை — உங்கள் ஸ்டேக்கின் (stack) ஒவ்வொரு அடுக்கும் இந்த புதிய முறையைச் சரியாகக் கையாள்கிறதா என்பதைச் சரிபார்க்காமல், ப்ரொடக்ஷனில் (production) QUERY எண்ட்பாயிண்ட்களை பயன்பாட்டிற்கு கொண்டு வர வேண்டாம். இங்கு விவரிக்கப்பட்டுள்ள பாதுகாப்புப் பண்புகள் சரியான செயலாக்கத்தைக் கருதுகின்றன; தவறாக உள்ளமைக்கப்பட்ட உள்கட்டமைப்பு, QUERY எதைத் தடுப்பதற்காக வடிவமைக்கப்பட்டதோ அதே பலவீனங்களை உருவாக்கக்கூடும். எப்போதும் முதலில் ஒரு கட்டுப்படுத்தப்பட்ட சூழலில் சோதிக்கவும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• HTTP QUERY முறை என்றால் என்ன, அது GET-லிருந்து எவ்வாறு வேறுபடுகிறது?
• தற்போது ப்ரொடக்ஷன் API-களில் QUERY-ஐப் பயன்படுத்த முடியுமா?
• POST மூலம் தேடல் பேலோடுகளை (search payloads) அனுப்புவதுடன் ஒப்பிடும்போது QUERY எவ்வாறு உள்ளது?
• CDN-கள் மற்றும் ப்ராக்ஸிகள் QUERY பதில்களைச் சரியாக கேச் (cache) செய்யுமா?
• QUERY முறை என்ன பாதுகாப்பு அபாயங்களை அறிமுகப்படுத்துகிறது?
• சிக்கலான தரவு சேகரிப்பிற்கு (data fetching) GraphQL-க்கு பதிலாக QUERY அமையுமா?
• எனது Express அல்லது FastAPI பயன்பாட்டில் QUERY ஆதரவை எவ்வாறு சேர்ப்பது?
• எனது WAF ஆனது QUERY முறையை அங்கீகரிக்கவில்லை என்றால் என்ன நடக்கும்?

குறிச்சொற்கள்

#http #query-method #rfc-9148 #api-design #web-security #rest-api #caching #http-methods