Trong suốt mười sáu năm qua, các nhà phát triển khi cần đặt những câu hỏi phức tạp cho máy chủ đã phải chấp nhận một giải pháp tạm thời. Khi một payload tìm kiếm trở nên quá lớn so với một URL, hoặc khi các bộ lọc lồng nhau và các tham số nhạy cảm không thể nằm gọn trong một query string, lựa chọn thực tế duy nhất là POST. Nó mang theo các byte dữ liệu, nhưng nó lại "nói dối" về mục đích thực sự. POST báo hiệu một sự thay đổi trạng thái. Việc sử dụng nó cho một thao tác chỉ đọc (read-only) đã buộc toàn bộ lộ trình mạng—từ bộ nhớ đệm (cache), proxy đến trình duyệt—phải xử lý một truy vấn tra cứu vô hại như thể nó có thể làm thay đổi cơ sở dữ liệu.

Sự thỏa hiệp đó cuối cùng đã chấm dứt. Vào tháng 6 năm 2026, IETF đã công bố RFC 10008, chính thức tiêu chuẩn hóa phương thức QUERY. Đây là phương thức HTTP mới đầu tiên kể từ khi PATCH được giới thiệu vào năm 2010. QUERY tồn tại dành riêng cho các yêu cầu an toàn và có tính idempotent (không thay đổi trạng thái khi lặp lại) mà tình cờ cần đến một thân yêu cầu (body). Nó không làm thay đổi trạng thái máy chủ. Việc lặp lại cùng một yêu cầu sẽ cho ra cùng một kết quả. Nó có thể lưu bộ nhớ đệm (cacheable), nghĩa là các thiết bị trung gian có thể lưu trữ và tái sử dụng phản hồi. Và không giống như GET, nó cho phép một payload dữ liệu giống như POST.

Các truy vấn GraphQL và các endpoint tìm kiếm REST phức tạp là những đối tượng hưởng lợi rõ rệt nhất. Bạn không còn phải nhồi nhét sáu mươi tham số truy vấn vào một URL hoặc ẩn một tài liệu bộ lọc JSON bên trong thân POST mà các thiết bị trung gian sẽ từ chối lưu cache. Về mặt ngữ nghĩa, giờ đây mọi thứ đã trở nên minh bạch.

Nhưng một bản RFC cũng chỉ là những dòng chữ trên giấy. Nằm giữa ứng dụng của bạn và người dùng là một lớp hạ tầng dày đặc, và hầu hết trong số đó chưa bao giờ nghe nói đến QUERY.

Vấn đề lưu bộ nhớ đệm vẫn chưa được giải quyết

Với một yêu cầu GET, việc lưu cache rất đơn giản. Khóa cache (cache key) chính là URI. Hai người dùng truy cập cùng một URL sẽ nhận được cùng một phản hồi đã được lưu trữ, với điều kiện các header cho phép.

QUERY phá vỡ mô hình đó vì các tham số yêu cầu nằm trong thân (body). Để một bộ nhớ đệm nhận ra rằng hai yêu cầu là giống hệt nhau, khóa cache phải bao gồm cả URI và nội dung thân yêu cầu. Yêu cầu đó tạo ra sự ma sát thực sự trong vận hành.

Thứ nhất, các máy chủ biên (edge servers) và CDN phải đệm (buffer) toàn bộ thân yêu cầu trước khi chúng có thể tính toán một mã hash. Điều đó tiêu tốn bộ nhớ và thời gian tại các nút biên (edge node). Thứ hai, hai truy vấn giống nhau về mặt logic có thể không tạo ra các byte giống hệt nhau. Một client có thể gửi {"status":"active"} trong khi một client khác gửi {"status": "active"} với khoảng trắng hoặc thứ tự khóa khác nhau. Trừ khi lớp cache thực hiện phân tích (parse), chuẩn hóa (normalize) và chuẩn hóa chính tắc (canonicalize) thân yêu cầu—sắp xếp các khóa JSON, loại bỏ các định dạng không quan trọng và xử lý sự khác biệt về mã hóa—nếu không, cùng một câu hỏi sẽ luôn bị trượt cache.

Quan trọng nhất là các CDN phổ biến vẫn chưa phân vùng cache theo thân yêu cầu đối với QUERY. Ví dụ, Cloudflare hiện tại không coi thân yêu cầu là một phần của khóa cache cho phương thức này trong dạng hiện tại của nó. Nếu bạn triển khai QUERY với giả định rằng "có thể cache" đồng nghĩa với "đã được cache", bạn có thể gặp lỗi xung đột, lỗi trượt cache toàn phần (universal cache misses), hoặc các phản hồi bị rò rỉ giữa các yêu cầu không liên quan. Cho đến khi nhà cung cấp của bạn công bố hỗ trợ rõ ràng, hãy giả định rằng QUERY không thể lưu cache một cách hiệu quả trong môi trường production.

Các công cụ của bạn có lẽ sẽ chặn nó trước tiên

Mọi yêu cầu HTTP đều đi qua một chồng các thiết bị trung gian (middleboxes), và hầu hết chúng đều thực thi các quy tắc nghiêm ngặt về việc phương thức nào là hợp lệ.

Các tường lửa ứng dụng web (WAF) và API gateway thường dựa vào các danh sách cho phép (allowlists) rõ ràng. Một bộ quy tắc điển hình cho phép GET, POST, PUT, DELETE và PATCH. Bất cứ thứ gì khác đều bị loại bỏ hoặc được trả về lỗi 405 Method Not Allowed. QUERY sẽ vấp phải những rào cản đó trước khi nó kịp chạm tới mã ứng dụng của bạn.

Các công cụ thực thi quy tắc bảo mật tạo thêm một trở ngại khác. Một số hệ thống phát hiện xâm nhập giả định rằng một yêu cầu mang theo một thân