కొత్త HTTP QUERY మెథడ్: Body కలిగిన ఒక GET రిక్వెస్ట్

1996 నుండి వెబ్‌కు HTTP వెన్నెముకగా ఉంది. దాదాపు మూడు దశాబ్దాలలో, కోర్ మెథడ్స్ — GET, POST, PUT, DELETE, PATCH — దాదాపు ఏమీ మారలేదు. డెవలపర్లు వీటిపై REST APIs యొక్క భారీ సామ్రాజ్యాలనే నిర్మించారు. మరియు చాలా ఉపయోగకర సందర్భాలలో, ఇవి బాగానే పనిచేస్తాయి.

కానీ ఒక లోటు ఉంది. ప్రతీ API డెవలపర్ ఏదో ఒక సందర్భంలో ఎదుర్కొన్న నిర్మాణాత్మక, విసుగు కలిగించే, కొన్నిసార్లు ప్రమాదకరమైన లోటు: మీరు డేటా కోసం శోధించాల్సిన అవసరం వచ్చినప్పుడు, మరియు ఆ శోధనే చాలా సంక్లిష్టంగా ఉన్నప్పుడు మీరు ఏమి చేస్తారు?

జూలై 17, 2026న, ఆ లోటుకు చివరికి అధికారిక సమాధానం లభించింది. జూన్ 15, 2026న ప్రామాణీకరించబడిన మరియు RFC 9148 లో అధికారికంగా నిర్వచించబడిన QUERY HTTP మెథడ్ — చాలా కాలం తర్వాత HTTP మెథడ్ కుటుంబానికి జోడించబడిన మొదటి కొత్త మెథడ్. మరియు GET అలాగే POST ఎప్పుడూ స్పష్టంగా పరిష్కరించలేని ఒక నిజమైన సమస్యను ఇది పరిష్కరిస్తుంది.

సమస్య: GET సంక్లిష్టమైన శోధనలను నిర్వహించలేదు

డేటా తెచ్చుకోవడానికి GET ప్రధాన సాధనం. మీరు ఒక URL ని హిట్ చేస్తారు, సర్వర్ మీకు డేటాను ఇస్తుంది. సులభమైనది, స్పష్టమైనది, క్యాష్ చేయదగినది. సరళమైన లుకప్‌ల కోసం — "give me user 42" లేదా "list all published posts" — GET సరిగ్గా సరిపోతుంది.

కానీ ఆధునిక అప్లికేషన్లు ఎల్లప్పుడూ సరళమైన ప్రశ్నలను అడగవు.

మీరు ఒక అనలిటిక్స్ డాష్‌బోర్డ్‌ను నిర్మిస్తున్నారని ఊహించుకోండి. ఒక యూజర్ పన్నెండు విభిన్న పారామితుల ద్వారా ఫిల్టర్ చేయాలనుకుంటున్నారు: తేదీ పరిధులు, నెస్టెడ్ భౌగోళిక ప్రాంతాలు, నిర్దిష్ట ప్రొడక్ట్ వర్గాలు, బూలియన్ లాజిక్‌తో కూడిన యూజర్ విభాగాలు మరియు ఒక ఫ్రీ-టెక్స్ట్ సెర్చ్ క్వెరీ. ఆ ఫిల్టర్ సెట్ సులభంగా 1,000 bytes కంటే ఎక్కువ కావచ్చు.

ఇక్కడే GET విఫలమవుతుంది. GET రిక్వెస్ట్‌లోని ప్రతిదీ URL లో ఉంటుంది. మరియు URLs కి ఆచరణాత్మక నిడివి పరిమితులు ఉంటాయి. బ్రౌజర్‌లు వాటిని పరిమితం చేస్తాయి, ప్రొక్సీలు వాటిని కుదిస్తాయి, సర్వర్లు వాటిని తిరస్కరిస్తాయి. RFC 2616 సర్వర్లు కనీసం 8,000 bytes ను నిర్వహించాలని సిఫార్సు చేస్తుంది, కానీ నిజ-ప్రపంచ విస్తరణలలో చాలావరకు దానికంటే ముందే విఫలమవుతాయి.

మరింత దారుణంగా, ఆ URL పారామితులు ప్రతిచోటా లాగ్ అవుతాయి. బ్రౌజర్ హిస్టరీ పూర్తి URL ను క్యాప్చర్ చేస్తుంది. ప్రొక్సీ సర్వర్లు దాన్ని క్యాష్ చేస్తాయి. సర్వర్ ఆక్సెస్ లాగ్‌లు దాన్ని స్టోర్ చేస్తాయి. మీ శోధనలో సున్నితమైన డేటా — పేషెంట్ ID, Social Security నంబర్ భాగం, ఒక ఇంటర్నల్ అకౌంట్ రిఫరెన్స్ — ఉంటే, ఆ సమాచారం ఇప్పుడు మీరు నియంత్రించని బహుళ సిస్టమ్‌లలో ప్లెయిన్ టెక్స్ట్‌గా ఉంటుంది.

అది కేవలం సైద్ధాంతిక ఆందోళన కాదు. అది ఒక నిజమైన కంప్లైయన్స్ తలనొప్పి.

సమస్య: POST అనేది అబద్ధం

కాబట్టి డెవలపర్లు ఎల్లప్పుడూ చేసేదే చేస్తారు — వారు ఆ పరిమితిని ఎలాగోలా దాటవేస్తారు. "POST ఉపయోగించండి," అని ఎవరో కోడ్ రివ్యూలో చెప్తారు. "మీరు POST రిక్వెస్ట్‌లో JSON body ని ఉంచవచ్చు, మరియు ఆ body URL లో ముగియదు."

సాంకేతికంగా నిజమే. కానీ సెమాంటిక్‌గా (semantically) తప్పు.

POST అనేది డేటాను సవరించడానికి రూపొందించబడింది. ఇది సర్వర్‌కి చెప్తుంది: "నేను మీకు ఏదో పంపుతున్నాను — ఒక రిసోర్స్‌ను సృష్టించండి, ఒక ప్రాసెస్‌ను ప్రారంభించండి, ఏదైనా స్టేట్‌ను మార్చండి." HTTP స్పెసిఫికేషన్‌లు చెప్పేది అదే. వెబ్ అప్లికేషన్ ఫైర్‌వాళ్లు ఆశించేది అదే. సర్వర్ ఫ్రేమ్‌వర్క్‌లు ఊహించేది అదే.

డేటా కోసం శోధించడానికి మీరు POST ని ఉపయోగించినప్పుడు, మీరు స్టాక్‌లోని ప్రతి పొరకూ అబద్ధం చెప్తున్నారు.

ఇది కేవలం తత్వశాస్త్రపరమైన పవిత్రత మాత్రమే కాదు. దీనికి నిజమైన పరిణామాలు ఉన్నాయి:

• క్యాషింగ్ దెబ్బతింటుంది. చాలా HTTP క్యాష్‌లు — CDNs, రివర్స్ ప్రొక్సీలు, బ్రౌజర్ క్యాష్‌లు — డిఫాల్ట్‌గా POST రెస్పాన్స్‌లను క్యాష్ చేయవు, ఎందుకంటే POST అనేది ప్రతీసారి రెస్పాన్స్ భిన్నంగా ఉండవచ్చని సూచిస్తుంది (సర్వర్ స్టేట్ మారింది కాబట్టి).
• యాదృచ్ఛిక సైడ్ ఎఫెక్ట్స్. కొన్ని సర్వర్ ఫ్రేమ్‌వర్క్‌లు మరియు మిడిల్‌వేర్ POST ని విభిన్నంగా పరిగణిస్తాయి. అవి ఆడిట్ లాగ్‌లకు వ్రాయవచ్చు, వెబ్‌హుక్‌లను ట్రిగ్గర్ చేయవచ్చు లేదా విభిన్న రేట్-లిమిటింగ్ నియమాలను వర్తింపజేయవచ్చు — వీటన్నింటికీ కారణం మీ "search" ఎండ్ పాయింట్ "create" ఎండ్ పాయింట్‌లా కనిపిస్తుంది.
• CSRF ప్రమాదం పెరుగుతుంది. POST ఎండ్‌పాయింట్‌లు విభిన్న cross-origin సెక్యూరిటీ సెమాంటిక్స్‌ను కలిగి ఉంటాయి. POST ని ఉపయోగించే శోధన ఎండ్‌పాయింట్‌కు ఇప్పుడు GET ఎండ్‌పాయింట్‌కు అవసరం లేని CSRF రక్షణ అవసరం అవుతుంది.
• మళ్లీ ప్రయత్నించడం (Retries) ప్రమాదకరంగా మారుతుంది. ఒక రిక్వెస్ట్ టైమ్‌అవుట్ అయితే, క్లయింట్లు GET ను సురక్షితంగా మళ్లీ ప్రయత్నించవచ్చు (ఇది idempotent). POST ను మళ్లీ ప్రయత్నించడం వలన నకిలీ రికార్డులు సృష్టించబడవచ్చు — మరియు మీ "search" ఎండ్‌పాయింట్ అసలు ఏదీ సృష్టించకూడదు.

ఈ వ్యత్యాసం చాలా సంవత్సరాలుగా బగ్‌లు, సెక్యూరిటీ లోపాలు మరియు నిర్మాణ ఇబ్బందులకు మూలంగా ఉంది. GraphQL, దాని అన్ని బలాలు ఉన్నప్పటికీ, దీనిని మరింత సాధారణం చేసింది — చాలా GraphQL ఇంప్లిమెంటేషన్‌లు క్వెరీలను POST రిక్వెస్ట్‌లుగా పంపుతాయి, అంటే GraphQL API లోని ప్రతీ రీడ్ ఆపరేషన్ ఒక రైట్ ఆపరేషన్ యొక్క సెమాంటిక్ భారాన్ని మోస్తుంది.

QUERY ప్రవేశం: పనికి సరైన సాధనం

QUERY మెథడ్ పేరుకు తగ్గట్టే ఉంటుంది: ఒక body ని సపోర్ట్ చేసే ఒక GET రిక్వెస్ట్.

దీనిని విభిన్నంగా చేసే అంశాలు ఇక్కడ ఉన్నాయి:

ఇది సురక్షితమైనది మరియు రీడ్-ఓన్లీ (read-only). QUERY మెథడ్ ఒక సురక్షితమైన, idempotent ఆపరేషన్‌గా నిర్వచించబడింది. ఒకే QUERY రిక్వెస్ట్‌ను వరుసగా పదిసార్లు పంపినా, సర్వర్‌పై ఎలాంటి సైడ్ ఎఫెక్ట్స్ లేకుండా అదే ఫలితాన్ని ఇస్తుంది. ఏ డేటా సృష్టించబడదు, ఏ స్టేట్ మారదు, పొరపాటున ఏ ఆడిట్ ట్రయల్స్ ట్రిగ్గర్ అవ్వవు.

ఇది ఒక request body కి సపోర్ట్ చేస్తుంది. POST లాగే, మీరు నిర్మిత డేటాను (structured data) — JSON, XML, మీ API ఏది ఉపయోగిస్తే అది — request body లో చేర్చవచ్చు. మీ సంక్లిష్ట శోధన ఫిల్టర్లు, నెస్టెడ్ ఆబ్జెక్ట్‌లు మరియు మల్టీ-కిలోబైట్ పేలోడ్‌లు URL కి సంపూర్ణంగా దూరంగా ఉంటాయి.

ఇది స్పష్టమైన ఉద్దేశ్యాన్ని తెలియజేస్తుంది. ఒక సర్వర్ QUERY రిక్వెస్ట్‌ను స్వీకరించినప్పుడు, క్లయింట్ ఏమి కోరుకుంటుందో అనే దానిపై ఎటువంటి సందేహం ఉండదు. ఇది డేటాను చదవాలనుకుంటోంది. అంతే. ఈ POST శోధనా లేదా సృష్టి ఆపరేషనా అని సర్వర్ ఊహించాల్సిన అవసరం లేదు.

ఇది సహజంగానే క్యాష్ చేయదగినది (natively cacheable). POST ప్రత్యామ్నాయ పరిష్కారాల వలె కాకుండా, QUERY అనేది సరైన క్యాషింగ్ సెమాంటిక్స్‌తో HTTP ప్రొటోకాల్ లేయర్‌లో పనిచేస్తుంది. సర్వర్ స్టేట్‌ను మార్చదని మెథడ్ స్పష్టంగా ప్రకటిస్తుంది కాబట్టి క్యాష్‌లు మరియు CDNs QUERY రెస్పాన్స్‌లను క్యాష్ చేయగలవు — ఇది POST ఎప్పటికీ హామీ ఇవ్వలేని విషయం.

ఈ చివరి పాయింట్‌ను నొక్కి చెప్పడం అవసరం. GraphQL సంక్లిష్టమైన ఫిల్టరింగ్‌ను అద్భుతంగా నిర్వహిస్తుంది, కానీ ఇది అప్లికేషన్ లేయర్‌లో పనిచేస్తుంది. చాలా GraphQL క్వెరీలు POST రిక్వెస్ట్‌లుగా ప్రయాణిస్తాయి, మరియు సర్వర్‌లు సాధారణంగా POST రెస్పాన్స్‌లను సహజంగా క్యాష్ చేయవు. QUERY మెథడ్ ట్రాన్స్‌పోర్ట్ లేయర్‌లో పనిచేస్తుంది, అంటే ప్రత్యేక అప్లికేషన్-స్థాయి కాన్ఫిగరేషన్ లేకుండానే HTTP ఇన్‌ఫ్రాస్ట్రక్చర్ — ప్రొక్సీలు, CDNs, లోడ్ బ్యాలెన్సర్‌లు — క్యాషింగ్‌లో పాల్గొనవచ్చు.

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 మెథడ్‌ను పరిచయం చేయడం దాడి చేసేవారికి (attackers) మరియు సెక్యూరిటీ పరిశోధకులకు గణనీయమైన కొత్త అవకాశాన్ని తెరుస్తుంది.

క్యాషింగ్ సంక్లిష్టంగా మారుతుంది

QUERY క్యాష్ చేయదగినది, మరియు దీనికి ఒక body ఉంది. ఆ కలయిక చాలా వరకు HTTP ఇన్‌ఫ్రాస్ట్రక్చర్‌కు కొత్తది.

సాంప్రదాయ క్యాషింగ్ URL మరియు కొన్ని హెడర్‌లను క్యాష్ కీగా ఉపయోగిస్తుంది. QUERY తో, సర్వర్‌లు మరియు ప్రొక్సీలు క్యాష్ కీలో request body ని కూడా తప్పనిసరిగా చేర్చాలి. ఒకవేళ క్యాష్ ఇంప్లిమెంటేషన్ దీనిలో పొరపాటు చేస్తే — ఉదాహరణకు ఇది కేవలం URL పైనే కీ చేసి body ని విస్మరిస్తే — వేర్వేరు యూజర్ల శోధన ఫలితాలు ఒకరికొకరు లీక్ కావచ్చు.

మరింత దారుణంగా, request body నుండి సున్నితమైన డేటా క్యాష్ లాగ్‌లలో లేదా డిబగ్ అవుట్‌పుట్‌లలో చేరితే, మీరు ఒక లాగింగ్ సమస్యను (ఆక్సెస్ లాగ్‌లలోని URL పారామితులు) మరొక సమస్యతో (క్యాష్ డిబగ్ లాగ్‌లలోని request bodies) మార్పిడి చేసుకున్నట్టే.

క్లాసిక్ లోపాలు, కొత్త వెక్టర్లు

ప్రతీ కొత్త HTTP మెథడ్ ఉన్న లోపాల వర్గాలకు కొత్త అవకాశాలను పరిచయం చేస్తుంది:

• ఇన్‌పుట్ వాలిడేషన్ వైఫల్యాలు. మీ WAF POST bodies ని వాలిడేట్ చేసే విధంగానే QUERY request bodies ని వాలిడేట్ చేస్తుందా? లేకపోతే, దాడి చేసేవారు మీ డిఫెన్స్‌లను దాటి హానికరమైన పేలోడ్‌లను స్మగుల్ చేయవచ్చు.
• రేట్ లిమిటింగ్ ఖాళీలు. మీ రేట్ లిమిటర్ GET మరియు POST రిక్వెస్ట్‌లను లెక్కిస్తూ, QUERY గురించి తెలియకపోతే, దాడి చేసేవారికి ఉచిత రిక్వెస్ట్‌లు లభిస్తాయి.
• CSRF మరియు CORS గందరగోళం. బ్రౌజర్‌లు మరియు ఫ్రేమ్‌వర్క్‌లు QUERY యొక్క cross-origin సెమాంటిక్స్‌ను సరిగ్గా నిర్వహించాల్సి ఉంటుంది. ప్రారంభ దత్తత దశలో, తప్పుడు కాన్ఫిగరేషన్‌లు దాదాపు ఖాయం.
• HTTP request smuggling. QUERY ని అర్థం చేసుకోని లోడ్ బ్యాలెన్సర్‌లు మరియు రివర్స్ ప్రొక్సీలు రిక్వెస్ట్‌లను తప్పుగా పార్స్ చేయవచ్చు, ఒక రిక్వెస్ట్ ఎక్కడ ముగుస్తుందో మరియు తదుపరిది ఎక్కడ ప్రారంభమవుతుందో అనే దానిపై ఫ్రంట్-ఎండ్ మరియు బ్యాక్-ఎండ్ విభేదించే స్మగ్లింగ్ అవకాశాలను సృష్టిస్తాయి.
• మెథడ్ గందరగోళం. ఒకవేళ WAF లేదా మిడిల్‌వేర్ ఒక తెలియని మెథడ్‌ను చూసి, డిఫాల్ట్ హ్యాండ్లర్‌కు పడిపోతే, అది సంపూర్ణంగా తప్పుడు సెక్యూరిటీ పాలసీని వర్తింపజేయవచ్చు.

ఇవి కేవలం ఊహాజనిత ప్రమాదాలు కావు. HTTP/2 ను పరిచయం చేసినప్పుడు, WebSockets వచ్చినప్పుడు మరియు ప్రతి ఇతర ముఖ్యమైన ప్రొటోకాల్ మార్పు ప్రొడక్షన్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను తాకినప్పుడు కనిపించిన అవే తరహా బగ్‌లు ఇవి. సరళి బాగా స్థిరపడినది: టూలింగ్ అందుకునే వరకు కొత్త ప్రొటోకాల్ ఫీచర్‌లు తాత్కాలిక సెక్యూరిటీ లోపాలను సృష్టిస్తాయి.

దత్తత (Adoption) ఎక్కడ ఉంది

2026 మధ్య నాటికి, దత్తత ప్రారంభ దశలలో ఉంది:

• బ్రౌజర్‌లు సపోర్ట్‌ను జోడించడం ప్రారంభిస్తున్నాయి, కానీ ఇది ఇంకా సార్వత్రికం కాదు.
• Web Application Firewalls QUERY రిక్వెస్ట్‌లను గుర్తించి సరిగ్గా ఫిల్టర్ చేయడానికి తమ రూల్ సెట్‌లను అప్‌డేట్ చేస్తున్నాయి.
• CDNs QUERY కోసం body-aware క్యాషింగ్ సపోర్ట్‌ను విడుదల చేస్తున్నాయి, కానీ కాన్ఫిగరేషన్‌లు భిన్నంగా ఉంటాయి.
• API ఫ్రేమ్‌వర్క్‌లు — Express, FastAPI, Spring, ASP.NET — తమ తాజా రిలీజ్‌లలో QUERY హ్యాండ్లర్‌లను జోడిస్తున్నాయి.
• HTTP క్లయింట్ లైబ్రరీలు QUERY రిక్వెస్ట్‌లను పంపడానికి సపోర్ట్ చేసేలా అప్‌డేట్ చేయబడుతున్నాయి.

పూర్తి, విస్తృతమైన దత్తతకు సమయం పడుతుంది. ఇది ఒక ప్రొటోకాల్-స్థాయి మార్పు, అంటే స్టాక్‌లోని ప్రతీ పొర — బ్రౌజర్ నుండి CDN వరకు, రివర్స్ ప్రొక్సీ నుండి అప్లికేషన్ ఫ్రేమ్‌వర్క్ వరకు, WAF వరకు — కొత్త మెథడ్‌ను అర్థం చేసుకోవలసి ఉంటుంది.

మీరు ఇప్పుడు ఏమి చేయాలి

మీరు ఒక బ్యాక్‌ఎండ్ డెవలపర్ లేదా API డిజైనర్ అయితే:

1. RFC ని చదవండి. RFC 9148 అనేది ప్రామాణిక స్పెసిఫికేషన్. మీరు ఇంప్లిమెంట్ చేయడానికి ముందు సెమాంటిక్స్‌ను అర్థం చేసుకోండి.
2. మీ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను ఆడిట్ చేయండి. మీ రివర్స్ ప్రొక్సీ, లోడ్ బ్యాలెన్సర్ మరియు WAF QUERY రిక్వెస్ట్‌లను సరిగ్గా అనుమతిస్తాయో లేదో తనిఖీ చేయండి. చాలా పాత కాన్ఫిగరేషన్‌లు డిఫాల్ట్‌గా తెలియని HTTP మెథడ్‌లను బ్లాక్ చేస్తాయి.
3. ప్రొడక్షన్‌కు తొందరపడకండి. అంతర్గత APIs లేదా dev ఎన్విరాన్‌మెంట్లతో ప్రారంభించండి. QUERY ఎండ్‌పాయింట్‌లను పబ్లిక్ ఇంటర్నెట్‌కు బహిర్గతం చేసే ముందు మీ టూలింగ్ పరిపక్వం చెందనివ్వండి.
4. మీ క్యాషింగ్ వ్యూహాన్ని అప్‌డేట్ చేయండి. మీరు QUERY రెస్పాన్స్‌లను క్యాష్ చేయాలని ప్లాన్ చేస్తే, మీ క్యాష్ కీలలో కేవలం URL మాత్రమే కాకుండా request body హ్యాష్‌ను కూడా చేర్చేలా చూసుకోండి.
5. మీ సెక్యూరిటీ కంట్రోల్స్‌ను పరీక్షించండి. రేట్ లిమిటింగ్, ఇన్‌పుట్ వాలిడేషన్, CORS మరియు ఆథెంటికేషన్ అన్నీ QUERY తో సరిగ్గా పనిచేస్తున్నాయని నిర్ధారించుకోండి — అవి పనిచేస్తాయని భావించవద్దు.

మీరు ఒక సెక్యూరిటీ పరిశోధకుడు అయితే, ఇది ఒక గొప్ప అవకాశం. ఒక కొత్త HTTP మెథడ్ ప్రొడక్షన్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను తాకడం అంటే ప్రతిచోటా కొత్త అటాక్ సర్ఫేస్ ఏర్పడుతుంది. ఇప్పుడే QUERY ని అధ్యయనం చేయడం ప్రారంభించండి, ఎందుకంటే ప్రారంభ దత్తత సమయంలో కనిపించే బగ్‌లు తరచుగా అత్యంత ప్రభావవంతమైనవిగా ఉంటాయి.

విశాలమైన కోణం (The Bigger Picture)

QUERY మెథడ్ ఒక విప్లవం కాదు. ఇది ఒక దిద్దుబాటు. 26 సంవత్సరాలుగా, డెవలపర్లు GET మరియు POST లను ఏ మెథడ్ చేయడానికి రూపొందించబడలేదో దాని కోసం ఉపయోగిస్తున్నారు — మరియు సెక్యూరిటీ బగ్‌లు, క్యాషింగ్ వైఫల్యాలు మరియు నిర్మాణ ఇబ్బందుల రూపంలో మూల్యం చెల్లిస్తున్నారు.

QUERY GET ని భర్తీ చేయదు. ఇది POST ని భర్తీ చేయదు. ఇది ఏళ్ల క్రితమే భర్తీ చేయబడి ఉండాల్సిన లోటును పూరిస్తుంది: request body కి సపోర్ట్ చేసే ఒక సురక్షితమైన, రీడ్-ఓన్లీ HTTP మెథడ్.

ప్రొటోకాల్ అధికారికమైనది. RFC ప్రచురించబడింది. ఇకోసిస్టమ్ అలవాటు పడుతోంది. మీరు APIs నిర్మిస్తున్నా, ఇన్‌ఫ్రాస్ట్రక్చర్‌ను బలపరుస్తున్నా, లేదా లోపాల కోసం వెతుకుతున్నా — QUERY మెథడ్ అనేది మీరు అర్థం చేసుకోవాల్సిన విషయం.

వెబ్‌కు ఇప్పుడే ఒక కొత్త క్రియ (verb) లభించింది. దీనిని తెలివిగా ఉపయోగించండి.

ప్రయోజనాలు

• URL నిడివి పరిమితులను పరిష్కరిస్తుంది: సంక్లిష్టమైన శోధన పేలోడ్‌లు URL నుండి request body కి మారుతాయి — ఇక కుదింపు ఉండదు
• సెక్యూరిటీ మెరుగుదల: సున్నితమైన శోధన పారామితులు ఇకపై బ్రౌజర్ హిస్టరీ, ఆక్సెస్ లాగ్‌లు మరియు ప్రొక్సీ క్యాష్‌లలో లీక్ అవ్వవు
• సరైన సెమాంటిక్స్: సర్వర్‌లు, మిడిల్‌వేర్ మరియు WAFలు ఊహించాల్సిన అవసరం లేకుండానే రైట్‌ల నుండి రీడ్‌లను వేరు చేయగలవు
• సహజమైన క్యాష్ పరిధి: HTTP ఇన్‌ఫ్రాస్ట్రక్చర్ QUERY రెస్పాన్స్‌లను క్యాష్ చేయగలదు — POST ప్రత్యామ్నాయ పరిష్కారాల వలె కాకుండా
• Idempotent మరియు సురక్షితమైనది: మళ్లీ ప్రయత్నించడాలు హానిచేయనివి, ఇది డిస్ట్రిబ్యూటెడ్ సిస్టమ్స్‌లో ఎర్రర్ హ్యాండ్లింగ్‌ను సరళీకృతం చేస్తుంది
• ప్రొటోకాల్-స్థాయి పరిష్కారం: GraphQL వంటి అప్లికేషన్-స్థాయి ప్రత్యామ్నాయ పరిష్కారాలు అవసరం లేకుండా అన్ని REST APIs అంతటా పనిచేస్తుంది

లోపాలు

• కొత్త అటాక్ సర్ఫేస్: స్మగ్లింగ్, మెథడ్ గందరగోళం, CSRF మరియు CORS సమస్యల కోసం కొత్త వెక్టర్లను పరిచయం చేస్తుంది
• క్యాషింగ్ సంక్లిష్టత: క్యాష్ ఇంప్లిమెంటేషన్‌లు కీలలో request body ని తప్పనిసరిగా చేర్చాలి — తప్పుడు కాన్ఫిగరేషన్ డేటాను లీక్ చేస్తుంది
• నెమ్మదిగా దత్తత: ఇది ఎండ్-టు-ఎండ్ నమ్మదగినదిగా పనిచేయడానికి ముందే బ్రౌజర్‌లు, CDNs, WAFలు మరియు ఫ్రేమ్‌వర్క్‌లు అన్నింటికీ అప్‌డేట్‌లు అవసరం
• టూలింగ్ ఖాళీలు: డిబగ్గింగ్ టూల్స్, మోనిటరింగ్ డాష్‌బోర్డ్‌లు మరియు లాగ్ పార్సర్‌లు ఇంకా QUERY ని నిర్వహించలేకపోవచ్చు
• ఇన్‌ఫ్రాస్ట్రక్చర్ అడ్డంకులు: పాత రివర్స్ ప్రాక్సీలు మరియు లోడ్ బ్యాలెన్సర్‌లు QUERY అభ్యర్థనలను నిశ్శబ్దంగా తీసివేయవచ్చు లేదా తిరస్కరించవచ్చు
• తప్పు భద్రతా భావన: పారామితులను URLల నుండి బయటకు మార్చడం లాగింగ్ ప్రమాదాలను తొలగించదు — బాడీలు ఇప్పటికీ లాగ్ చేయబడవచ్చు

జాగ్రత్త

ఈ వ్యాసం జూన్ 2026లో ప్రామాణీకరించబడిన RFC 9148లో నిర్వచించిన QUERY HTTP పద్ధతి గురించి చర్చిస్తుంది. బ్రౌజర్ మద్దతు, ఫ్రేమ్‌వర్క్ మద్దతు మరియు ఇన్‌ఫ్రాస్ట్రక్చర్ అనుకూలత వేగంగా అభివృద్ధి చెందుతున్నాయి. మీ స్టాక్ యొక్క ప్రతి పొర — CDN నుండి WAF వరకు అప్లికేషన్ ఫ్రేమ్‌వర్క్ వరకు — కొత్త పద్ధతిని సరిగ్గా హ్యాండిల్ చేస్తుందో లేదో సరిచూసుకోకుండా ప్రొడక్షన్‌లో QUERY ఎండ్‌పాయింట్‌లను డిప్లాయ్ చేయవద్దు. ఇక్కడ వివరించిన భద్రతా లక్షణాలు సరైన అమలుపై ఆధారపడి ఉంటాయి; తప్పుగా కాన్ఫిగర్ చేసిన ఇన్‌ఫ్రాస్ట్రక్చర్, QUERY నివారించడానికి రూపొందించబడిన దుర్బలత్వాలనే ప్రవేశపెట్టవచ్చు. ఎల్లప్పుడూ మొదట నియంత్రిత వాతావరణంలో పరీక్షించండి.

తరచుగా అడిగే ప్రశ్నలు

• HTTP QUERY పద్ధతి అంటే ఏమిటి మరియు ఇది GET నుండి ఎలా భిన్నంగా ఉంటుంది?
• నేను ఇప్పుడు ప్రొడక్షన్ APIలలో QUERYని ఉపయోగించవచ్చా?
• POST ద్వారా సెర్చ్ పేలోడ్‌లను పంపడంతో QUERY ఎలా సరిపోల్చబడుతుంది?
• CDNలు మరియు ప్రాక్సీలు QUERY స్పందనలను సరిగ్గా క్యాషే చేస్తాయా?
• QUERY పద్ధతి ఏ భద్రతా ప్రమాదాలను ప్రవేశపెడుతుంది?
• సంక్లిష్ట డేటా ఫెచింగ్ కోసం QUERY GraphQLని భర్తీ చేస్తుందా?
• నా Express లేదా FastAPI అప్లికేషన్‌కు QUERY మద్దతును నేను ఎలా జోడించాలి?
• నా WAF, QUERY పద్ధతిని గుర్తించకపోతే ఏమి జరుగుతుంది?

ట్యాగ్‌లు

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