పదహారు సంవత్సరాలుగా, సర్వర్ను సంక్లిష్టమైన ప్రశ్నలు అడగవలసి వచ్చిన డెవలపర్లు ఒక తాత్కాలిక పరిష్కారంతో (workaround) ఇబ్బంది పడుతున్నారు. సెర్చ్ పేలోడ్ (search payload) URL పరిమాణం కంటే పెద్దదిగా మారినప్పుడు, లేదా నెస్టెడ్ ఫిల్టర్లు మరియు సెన్సిటివ్ పారామీటర్లు క్వెరీ స్ట్రింగ్లో సరిపోనప్పుడు, POST మాత్రమే ఒకే ఒక ఆచరణాత్మక మార్గంగా ఉండేది. ఇది డేటాను (bytes) మోసుకెళ్తుంది, కానీ దాని ఉద్దేశ్యం గురించి తప్పుగా చెబుతుంది. POST అనేది స్టేట్ మార్పును (change of state) సూచిస్తుంది. కేవలం డేటాను చదవడానికి (read-only operation) మాత్రమే దీనిని ఉపయోగించడం వల్ల, మొత్తం నెట్వర్క్ పాత్—క్యాచెస్, ప్రాక్సీలు మరియు బ్రౌజర్లు—ఒక సాధారణ సమాచార అన్వేషణను (lookup) డేటాబేస్ను మార్చే అవకాశం ఉన్న రిక్వెస్ట్గా పరిగణించాల్సి వచ్చేది.
ఆ రాజీకి చివరకు ముగింపు పలికింది. జూన్ 2026లో, IETF RFC 10008ను ప్రచురించి, QUERY పద్ధతిని అధికారికంగా ప్రామాణీకరించింది. 2010లో PATCH పరిచయం చేయబడినప్పటి నుండి వచ్చిన మొదటి కొత్త HTTP పద్ధతి ఇదే. QUERY ప్రత్యేకంగా బాడీ (body) అవసరమయ్యే సురక్షితమైన, ఐడెంపోటెంట్ (idempotent) రిక్వెస్ట్ల కోసం రూపొందించబడింది. ఇది సర్వర్ స్టేట్ను మార్చదు. ఒకే రిక్వెస్ట్ను మళ్ళీ మళ్ళీ చేసినా ఒకే ఫలితం వస్తుంది. ఇది క్యాచబుల్ (cacheable), అంటే మధ్యవర్తులు (intermediaries) ప్రతిస్పందనను నిల్వ చేసి తిరిగి ఉపయోగించవచ్చు. మరియు GET లాగా కాకుండా, ఇది POST లాగే డేటా పేలోడ్ను అనుమతిస్తుంది.
GraphQL క్వెరీల మరియు సంక్లిష్టమైన REST సెర్చ్ ఎండ్పాయింట్లు దీని వల్ల అతిపెద్ద ప్రయోజనం పొందుతాయి. మీరు అరవై క్వెరీ పారామీటర్లను ఒక URLలో ఇరికించాల్సిన లేదా మధ్యవర్తులు క్యాష్ చేయడానికి నిరాకరించే విధంగా ఒక JSON ఫిల్టర్ డాక్యుమెంట్ను POST బాడీలో దాచాల్సిన అవసరం ఇకపై లేదు. ఇప్పుడు దీని అర్థం (semantics) స్పష్టంగా ఉంది.
కానీ RFC అనేది కేవలం ఒక పత్రం మాత్రమే. మీ అప్లికేషన్ మరియు మీ వినియోగదారుల మధ్య మందపాటి ఇన్ఫ్రాస్ట్రక్చర్ పొర ఉంటుంది, అందులో చాలా వరకు QUERY గురించి ఎప్పుడూ వినలేదు.
క్యాషింగ్ సమస్య ఇంకా పరిష్కరించబడలేదు
GET రిక్వెస్ట్తో, క్యాషింగ్ చాలా సులభం. క్యాష్ కీ (cache key) అనేది URI. హెడర్లు అనుమతిస్తే, ఒకే URLని ఉపయోగించే ఇద్దరు వినియోగదారులు ఒకే నిల్వ చేయబడిన ప్రతిస్పందనను పొందుతారు.
QUERY ఆ నమూనాను దెబ్బతీస్తుంది ఎందుకంటే రిక్వెస్ట్ పారామీటర్లు బాడీలో ఉంటాయి. రెండు రిక్వెస్ట్లు ఒకటే అని క్యాష్ గుర్తించాలంటే, క్యాష్ కీ URI మరియు బాడీ కంటెంట్ రెండింటినీ కలిగి ఉండాలి. ఈ అవసరం ఆపరేషనల్ ఇబ్బందులను (operational friction) కలిగిస్తుంది.
మొదటగా, ఎడ్జ్ సర్వర్లు మరియు CDNs ఒక హ్యాష్ను (hash) లెక్కించే ముందు మొత్తం రిక్వెస్ట్ బాడీని బఫర్ చేయాలి. దీనికి ఎడ్జ్ నోడ్లో మెమరీ మరియు సమయం అవసరమవుతుంది. రెండవది, తార్కికంగా ఒకేలా ఉండే రెండు క్వెరీలు ఒకే రకమైన బైట్స్ను ఉత్పత్తి చేయకపోవచ్చు. ఒక క్లయింట్ {"status":"active"} అని పంపవచ్చు, అదే సమయంలో మరొకరు వేర్వేరు వైట్స్పేస్ లేదా కీ ఆర్డరింగ్తో {"status": "active"} అని పంపవచ్చు. క్యాషింగ్ లేయర్ బాడీని పార్స్ (parse), నార్మలైజ్ (normalize) మరియు క్యానోనికలైజ్ (canonicalize) చేయనంత వరకు—అంటే JSON కీలను క్రమబద్ధీకరించడం, అనవసరమైన ఫార్మాటింగ్ను తొలగించడం మరియు ఎన్కోడింగ్ తేడాలను నిర్వహించడం—అదే ప్రశ్న ప్రతిసారీ క్యాష్ను మిస్ అవుతుంది.
అత్యంత ముఖ్యంగా, ప్రధానమైన CDNs ఇంకా QUERY కోసం రిక్వెస్ట్ బాడీ ఆధారంగా క్యాష్ను విభజించడం లేదు. ఉదాహరణకు, Cloudflare ప్రస్తుతం ఈ పద్ధతిలో బాడీని క్యాష్ కీలో భాగంగా పరిగణించదు. క్యాచబుల్ అంటే క్యాష్ చేయబడింది అని మీరు భావించి QUERYని ఉపయోగిస్తే, కొలిజన్ ఎర్రర్స్ (collision errors), యూనివర్సల్ క్యాష్ మిస్సెస్ లేదా సంబంధం లేని రిక్వెస్ట్ల మధ్య ప్రతిస్పందనలు లీక్ అయ్యే అవకాశాలు ఉన్నాయి. మీ ప్రొవైడర్ స్పష్టమైన మద్దతును ప్రకటించే వరకు, ప్రొడక్షన్లో QUERY అనేది అర్థవంతంగా క్యాచబుల్ కాదని భావించండి.
మీ టూల్స్ బహుశా దీనిని మొదటగా బ్లాక్ చేస్తాయి
ప్రతి HTTP రిక్వెస్ట్ అనేక మిడిల్బాక్స్ల (middleboxes) గుండా వెళ్తుంది, వాటిలో చాలా వరకు ఏ పద్ధతులు చట్టబద్ధమైనవో అనే విషయంలో కఠినమైన నియమాలను అమలు చేస్తాయి.
వెబ్ అప్లికేషన్ ఫైర్వాల్స్ (WAFs) మరియు API గేట్వేలు తరచుగా స్పష్టమైన అలోలిస్ట్లపై (allowlists) ఆధారపడతాయి. సాధారణ రూల్ సెట్ GET, POST, PUT, DELETE మరియు PATCHలను అనుమతిస్తుంది. QUERY మీ అప్లికేషన్ కోడ్కు చేరుకోకముందే ఆ అడ్డంకులను ఎదుర్కొంటుంది లేదా 405 Method Not Allowed అనే సమాధానంతో నిలిచిపోతుంది.
సెక్యూరిటీ రూల్ ఇంజన్లు మరొక అడ్డంకిని సృష్టిస్తాయి. కొన్ని ఇంట్రూజన్ డిటెక్షన్ సిస్టమ్స్ బాడీని కలిగి ఉన్న రిక్వెస్ట్ను