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

പതിനാറ് വർഷങ്ങളായി, ഒരു സെർവറോട് സങ്കീർണ്ണമായ ചോദ്യങ്ങൾ ചോദിക്കേണ്ടി വരുന്ന ഡെവലപ്പർമാർ ഒരു പരിഹാരമില്ലായ്മയിൽ (workaround) കുടുങ്ങിക്കിടക്കുകയായിരുന്നു. ഒരു സെർച്ച് പേലോഡ് ഒരു URL-ൽ ഉൾക്കൊള്ളാൻ കഴിയാത്തത്ര വലുതാകുമ്പോഴോ, അല്ലെങ്കിൽ നെസ്റ്റഡ് ഫിൽട്ടറുകളും സെൻസിറ്റീവ് പാരാമീറ്ററുകളും ഒരു ക്വറി സ്ട്രിംഗിനുള്ളിൽ ഉൾക്കൊള്ളാൻ കഴിയാതെ വരുമ്പോഴോ, POST മാത്രമായിരുന്നു ഏക പ്രായോഗിക മാർഗ്ഗം. അത് ഡാറ്റ എത്തിച്ചു, പക്ഷേ അതിന്റെ ഉദ്ദേശ്യത്തെക്കുറിച്ച് തെറ്റായ സന്ദേശമാണ് നൽകിയത്. POST ഒരു സ്റ്റേറ്റ് മാറ്റത്തെ (change of state) സൂചിപ്പിക്കുന്നു. ഒരു റീഡ്-ഒൺലി (read-only) ഓപ്പറേഷനായി ഇത് ഉപയോഗിക്കുന്നത് കിച്ചുകൾ, പ്രോക്സികൾ, ബ്രൗസറുകൾ തുടങ്ങി മുഴുവൻ നെറ്റ്‌വർക്ക് പാതയെയും ഒരു ഡാറ്റാബേസ് മാറ്റാൻ സാധ്യതയുള്ള ഒരു പ്രക്രിയയായി കാണാൻ നിർബന്ധിക്കുന്നു.

ആ വിട്ടുവീഴ്ചയ്ക്ക് ഒടുവിൽ അന്ത്യം കുറിച്ചു. 2026 ജൂണിൽ, IETF RFC 10008 പ്രസിദ്ധീകരിച്ചു, ഇത് QUERY മെത്തേഡിനെ ഔദ്യോഗികമായി മാനദണ്ഡവൽക്കരിച്ചു. 2010-ൽ PATCH അവതരിപ്പിച്ചതിന് ശേഷം വന്ന ആദ്യത്തെ പുതിയ HTTP മെത്തേഡ് ആണിത്. ബോഡി ആവശ്യമായി വരുന്ന സുരക്ഷിതവും (safe), ഐഡംപോറ്റന്റും (idempotent) ആയ റിക്വസ്റ്റുകൾക്കായി പ്രത്യേകം രൂപകൽപ്പന ചെയ്തതാണ് QUERY. ഇത് സെർവർ സ്റ്റേറ്റ് മാറ്റുന്നില്ല. ഒരേ റിക്വസ്റ്റ് ആവർത്തിക്കുന്നത് ഒരേ ഫലം തന്നെ നൽകുന്നു. ഇത് കാഷെ ചെയ്യാൻ സാധിക്കും (cacheable), അതായത് ഇടനിലക്കാർക്ക് (intermediaries) റെസ്പോൺസ് സംഭരിക്കാനും വീണ്ടും ഉപയോഗിക്കാനും കഴിയും. GET-ൽ നിന്ന് വ്യത്യസ്തമായി, POST പോലെ തന്നെ ഇതിലും ഒരു ഡാറ്റ പേലോഡ് അനുവദനീയമാണ്.

GraphQL ക്വറികളും സങ്കീർണ്ണമായ REST സെർച്ച് എൻഡ്പോയിന്റുകളുമാണ് ഇതിന്റെ ഏറ്റവും വലിയ ഗുണഭോക്താക്കൾ. ഇനി അറുപതോളം ക്വറി പാരാമീറ്ററുകൾ ഒരു URL-ൽ തിരുകിക്കയറ്റേണ്ടതില്ല, അല്ലെങ്കിൽ ഇടനിലക്കാർ കാഷെ ചെയ്യാൻ വിസമ്മതിക്കുന്ന ഒരു POST ബോഡിനുള്ളിൽ ഒരു JSON ഫിൽട്ടർ ഡോക്യുമെന്റ് ഒളിപ്പിച്ചു വെക്കേണ്ടി വരുന്നില്ല. ഇതിന്റെ സെമാന്റിക്സ് (semantics) ഇപ്പോൾ കൃത്യമാണ്.

എന്നാൽ ഒരു RFC എന്നത് വെറും കടലാസിലെ അക്ഷരങ്ങൾ മാത്രമാണ്. നിങ്ങളുടെ ആപ്ലിക്കേഷനും ഉപയോക്താക്കളും തമ്മിൽ വലിയൊരു ഇൻഫ്രാസ്ട്രക്ചർ പാളിയുണ്ട്, അതിൽ ഭൂരിഭാഗവും QUERY എന്നതിനെക്കുറിച്ച് കേട്ടിട്ടുപോലുമില്ല.

കാഷിംഗ് പ്രശ്നം ഇനിയും പരിഹരിക്കപ്പെട്ടിട്ടില്ല

ഒരു GET റിക്വസ്റ്റിൽ, കാഷിംഗ് വളരെ ലളിതമാണ്. കാഷെ കീ (cache key) എന്നത് URI ആണ്. ഹെഡറുകൾ അനുവദിക്കുന്നുണ്ടെങ്കിൽ, ഒരേ URL ഉപയോഗിക്കുന്ന രണ്ട് ഉപയോക്താക്കൾക്കും ഒരേ സ്റ്റോർ ചെയ്ത റെസ്പോൺസ് ലഭിക്കും.

റിക്വസ്റ്റ് പാരാമീറ്ററുകൾ ബോഡിയിലായതുകൊണ്ട് QUERY ഈ മാതൃകയെ തകർക്കുന്നു. രണ്ട് റിക്വസ്റ്റുകൾ ഒന്നുതന്നെയാണെന്ന് തിരിച്ചറിയാൻ, കാഷെ കീയിൽ URI-യും ബോഡി ഉള്ളടക്കവും ഉൾപ്പെടുത്തേണ്ടതുണ്ട്. ഈ ആവശ്യം പ്രവർത്തനപരമായ തടസ്സങ്ങൾ (operational friction) ഉണ്ടാക്കുന്നു.

ഒന്നാമതായി, ഒരു ഹാഷ് (hash) കണക്കാക്കുന്നതിന് മുമ്പ് എഡ്ജ് സെർവറുകളും (edge servers) CDNs-ഉം മുഴുവൻ റിക്വസ്റ്റ് ബോഡിയും ബഫർ ചെയ്യേണ്ടതുണ്ട്. ഇത് എഡ്ജ് നോഡുകളിൽ മെമ്മറിയും സമയവും എടുക്കുന്നു. രണ്ടാമതായി, ലോജിക്കലായി ഒരേപോലെയിരിക്കുന്ന രണ്ട് ക്വറികൾ ഒരേ ബൈറ്റുകൾ തന്നെ നൽകണമെന്നില്ല. ഒരു ക്ലയന്റ് {"status":"active"} എന്ന് അയക്കുമ്പോൾ മറ്റൊരാൾ വൈറ്റ്സ്പേസ് അല്ലെങ്കിൽ കീ ക്രമീകരണത്തിലെ വ്യത്യാസം കാരണം {"status": "active"} എന്ന് അയച്ചേക്കാം. കാഷിംഗ് ലെയർ ബോഡി പാഴ്സ് ചെയ്യുകയും (parse), നോർമലൈസ് ചെയ്യുകയും (normalize), കാനോണിക്കലൈസ് ചെയ്യുകയും (canonicalize) ചെയ്തില്ലെങ്കിൽ—അതായത് JSON കീകൾ ക്രമീകരിക്കുകയും, അനാവശ്യ ഫോർമാറ്റിംഗുകൾ ഒഴിവാക്കുകയും, എൻകോഡിംഗ് വ്യത്യാസങ്ങൾ കൈകാര്യം ചെയ്യുകയും ചെയ്തില്ലെങ്കിൽ—ഒരേ ചോദ്യം തന്നെ ഓരോ തവണയും കാഷെ മിസ്സ് (cache miss) ചെയ്യും.

ഏറ്റവും പ്രധാനമായി, പ്രമുഖ CDNs QUERY-ക്ക് വേണ്ടി റിക്വസ്റ്റ് ബോഡി അടിസ്ഥാനമാക്കി കാഷെ വിഭജിക്കുന്നില്ല. ഉദാഹരണത്തിന്, ക്ലൗഡ്ഫ്ലെയർ (Cloudflare) നിലവിലെ രൂപത്തിൽ ഈ മെത്തേഡിനായി ബോഡിയെ കാഷെ കീയുടെ ഭാഗമായി കണക്കാക്കുന്നില്ല. കാഷെ ചെയ്യാൻ സാധിക്കും എന്നതുകൊണ്ട് അത് കാഷെ ചെയ്യപ്പെട്ടതായി കരുതി നിങ്ങൾ QUERY ഉപയോഗിച്ചാൽ, കൊളിഷൻ എററുകൾ (collision errors), യൂണിവേഴ്സൽ കാഷെ മിസ്സുകൾ (universal cache misses), അല്ലെങ്കിൽ അപ്രസക്തമായ റിക്വസ്റ്റുകളിലേക്ക് വിവരങ്ങൾ ചോരുന്ന അവസ്ഥകൾ എന്നിവ നേരിടേണ്ടി വന്നേക്കാം. നിങ്ങളുടെ പ്രൊവൈഡർ ഇതിനായി പ്രത്യേക പിന്തുണ പ്രഖ്യാപിക്കുന്നത് വരെ, പ്രൊഡക്ഷനിൽ QUERY കാര്യക്ഷമമായി കാഷെ ചെയ്യാൻ സാധിക്കില്ല എന്ന് കരുതുക.

നിങ്ങളുടെ ടൂളുകൾ ഒരുപക്ഷേ ആദ്യം ഇത് തടഞ്ഞേക്കാം

ഓരോ HTTP റിക്വസ്റ്റും നിരവധി മിഡിൽബോക്സുകളിലൂടെ (middleboxes) കടന്നുപോകുന്നു, അവയിൽ ഭൂരിഭാഗവും ഏത് മെത്തേഡുകളാണ് അനുവദനീയമെന്ന കാര്യത്തിൽ കർശനമായ നിയമങ്ങൾ പാലിക്കുന്നു.

വെബ് ആപ്ലിക്കേഷൻ ഫയർവാളുകളും (WAF) API ഗേറ്റ്‌വേകളും പലപ്പോഴും കൃത്യമായ അലൗലിസ്റ്റുകളെ (allowlists) ആണ് ആശ്രയിക്കുന്നത്. സാധാരണയായി GET, POST, PUT, DELETE, PATCH എന്നിവയെയാണ് ഒരു റൂൾസെറ്റ് അനുവദിക്കുന്നത്. മറ്റെന്തെങ്കിലും വന്നാൽ അത് തള്ളിക്കളയുകയോ അല്ലെങ്കിൽ 405 Method Not Allowed എന്ന മറുപടി നൽകുകയോ ചെയ്യും. QUERY നിങ്ങളുടെ ആപ്ലിക്കേഷൻ കോഡിൽ എത്തുന്നതിന് മുമ്പ് തന്നെ ഈ തടസ്സങ്ങളിൽ തട്ടിനിൽക്കും.

സെക്യൂരിറ്റി റൂൾ എൻജിനുകൾ മറ്റൊരു തടസ്സമാണ്. ചില ഇൻട്രൂഷൻ ഡിറ്റക്ഷൻ സിസ്റ്റങ്ങൾ ബോഡി ഉൾക്കൊള്ളുന്ന ഒരു റിക്വസ്റ്റ്...