ষোলো বছর ধরে, যেসব ডেভেলপারদের একটি সার্ভারকে জটিল প্রশ্ন করতে হতো, তারা একটি বিকল্প উপায়ের (workaround) ওপর নির্ভর করতে বাধ্য ছিলেন। যখন একটি সার্চ পেলোড (payload) ইউআরএল (URL)-এর জন্য অনেক বড় হয়ে যেত, অথবা যখন নেস্টেড ফিল্টার এবং সংবেদনশীল প্যারামিটারগুলো একটি কুয়েরি স্ট্রিং-এর মধ্যে জায়গা নিতে পারত না, তখন একমাত্র ব্যবহারিক বিকল্প ছিল POST। এটি বাইটগুলো বহন করত, কিন্তু এর উদ্দেশ্য সম্পর্কে মিথ্যা বলত। POST স্টেট পরিবর্তনের সংকেত দেয়। একটি রিড-অনলি (read-only) অপারেশনের জন্য এটি ব্যবহার করলে পুরো নেটওয়ার্ক পাথ—ক্যাশ (caches), প্রক্সি (proxies) এবং ব্রাউজারগুলোকে—একটি সাধারণ অনুসন্ধানের ক্ষেত্রেও এমনভাবে আচরণ করতে বাধ্য করা হতো যেন এটি ডেটাবেস পরিবর্তন করে ফেলতে পারে।

সেই আপস অবশেষে শেষ হয়েছে। ২০২৬ সালের জুন মাসে, IETF RFC 10008 প্রকাশ করেছে, যা আনুষ্ঠানিকভাবে QUERY মেথডকে মানদণ্ড হিসেবে নির্ধারণ করেছে। ২০১০ সালে PATCH প্রবর্তনের পর এটিই প্রথম নতুন HTTP মেথড। QUERY বিশেষভাবে তৈরি করা হয়েছে নিরাপদ এবং আইডেমপোটেন্ট (idempotent) রিকোয়েস্টের জন্য যেগুলোর বডি (body) প্রয়োজন হয়। এটি সার্ভারের স্টেট পরিবর্তন করে না। একই রিকোয়েস্ট বারবার করলে একই ফলাফল পাওয়া যায়। এটি ক্যাশেবল (cacheable), যার অর্থ হলো ইন্টারমিডিয়ারিগুলো (intermediaries) রেসপন্সটি সংরক্ষণ এবং পুনরায় ব্যবহার করতে পারে। এবং GET-এর মতো নয়, এটি POST-এর মতোই একটি ডেটা পেলোড ব্যবহারের অনুমতি দেয়।

GraphQL কুয়েরি এবং জটিল REST সার্চ এন্ডপয়েন্টগুলো এর সবচেয়ে বড় সুবিধাভোগী। আপনাকে আর একটি ইউআরএল-এ ষাটটি কুয়েরি প্যারামিটার ঠাসাঠাসি করে রাখতে হবে না অথবা একটি POST বডির ভেতরে JSON ফিল্টার ডকুমেন্ট লুকিয়ে রাখতে হবে যা ইন্টারমিডিয়ারিগুলো ক্যাশে করতে অস্বীকার করবে। এর সিম্যান্টিকস (semantics) এখন স্বচ্ছ।

কিন্তু একটি RFC কেবল কালির দাগ মাত্র। আপনার অ্যাপ্লিকেশন এবং ব্যবহারকারীদের মাঝে অবকাঠামোর (infrastructure) একটি বিশাল স্তর রয়েছে, যার বেশিরভাগই QUERY সম্পর্কে কখনো শোনেনি।

ক্যাশিং সমস্যাটি এখনও সমাধান হয়নি

একটি GET রিকোয়েস্টের ক্ষেত্রে ক্যাশিং বেশ সহজ। ক্যাশ কী (cache key) হলো URI। হেডার অনুমতি দিলে, একই ইউআরএল ব্যবহারকারী দুজন একই সংরক্ষিত রেসপন্স পাবেন।

QUERY সেই মডেলটি ভেঙে দেয় কারণ রিকোয়েস্ট প্যারামিটারগুলো বডিতে থাকে। একটি ক্যাশ যাতে বুঝতে পারে যে দুটি রিকোয়েস্ট অভিন্ন, সেজন্য ক্যাশ কী-তে URI এবং বডি কন্টেন্ট—উভয়কেই অন্তর্ভুক্ত করতে হবে। এই প্রয়োজনীয়তা বাস্তব কার্যক্ষমতায় জটিলতা (operational friction) তৈরি করে।

প্রথমত, এজ সার্ভার (edge servers) এবং CDN-গুলোকে একটি হ্যাশ (hash) গণনা করার আগে পুরো রিকোয়েস্ট বডি বাফার করতে হয়। এতে এজ নোডে মেমরি এবং সময় উভয়ই ব্যয় হয়। দ্বিতীয়ত, লজিক্যালি অভিন্ন দুটি কুয়েরি একই বাইট তৈরি নাও করতে পারে। একজন ক্লায়েন্ট হয়তো {"status":"active"} পাঠাবে, আবার অন্যজন হয়তো ভিন্ন হোয়াইটস্পেস বা কী-এর ক্রমসহ {"status": "active"} পাঠাবে। যদি ক্যাশিং লেয়ার বডিটি পার্স (parse), নরমালাইজ (normalize) এবং ক্যানোনিকালাইজ (canonicalize) না করে—অর্থাৎ JSON কীগুলো সাজানো, অপ্রয়োজনীয় ফরম্যাটিং বাদ দেওয়া এবং এনকোডিংয়ের পার্থক্য সামলানো—তবে একই প্রশ্ন বারবার ক্যাশ মিস করবে।

সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো, মূলধারার CDN-গুলো QUERY-এর জন্য রিকোয়েস্ট বডি অনুযায়ী ক্যাশ পার্টিশন করে না। উদাহরণস্বরূপ, Cloudflare বর্তমানে এই মেথডের ক্ষেত্রে বডিকে ক্যাশ কী-এর অংশ হিসেবে গণ্য করে না। আপনি যদি ধরে নেন যে 'ক্যাশেবল' মানেই 'ক্যাশ করা হয়েছে', তবে আপনি কলিশন এরর (collision errors), সার্বজনীন ক্যাশ মিস (universal cache misses), অথবা unrelated রিকোয়েস্টের মধ্যে রেসপন্স লিক হওয়ার মতো সমস্যা দেখতে পারেন। যতক্ষণ না আপনার প্রোভাইডার এর জন্য স্পষ্ট সমর্থন প্রকাশ করছে, ততক্ষণ ধরে নিন যে প্রোডাকশনে QUERY কার্যকরভাবে ক্যাশেবল নয়।

আপনার টুলসগুলো সম্ভবত এটি প্রথমে ব্লক করবে

প্রতিটি HTTP রিকোয়েস্ট কতগুলো মিডলবক্সের (middleboxes) মধ্য দিয়ে যায় এবং তাদের বেশিরভাগই কোন মেথডগুলো বৈধ তা নিয়ে কঠোর নিয়ম মেনে চলে।

ওয়েব অ্যাপ্লিকেশন ফায়ারওয়াল (WAF) এবং API গেটওয়েগুলো প্রায়ই নির্দিষ্ট 'অ্যালাউলিস্ট' (allowlists)-এর ওপর নির্ভর করে। একটি সাধারণ রুলসেট GET, POST, PUT, DELETE এবং PATCH অনুমতি দেয়। অন্য যেকোনো কিছু ড্রপ করা হয় অথবা '405 Method Not Allowed' এর মাধ্যমে উত্তর দেওয়া হয়। QUERY আপনার অ্যাপ্লিকেশন কোডে পৌঁছানোর আগেই এই বাধাগুলোর সম্মুখীন হবে।

সিকিউরিটি রুল ইঞ্জিনগুলো আরও একটি বাধা যোগ করে। কিছু ইন্ট্রুশন ডিটেকশন সিস্টেম ধরে নেয় যে একটি রিকোয়েস্ট যা বডি বহন করছে