圈小蛙
在现代 Web 开发中，当客户端需要向服务器请求特定数据时，通常会使用 GET 方法并将查询参数拼接在 URL 的末尾。然而，当面临复杂的筛选条件、多层嵌套的过滤器或大型数据集查询时，URI 的长度很容易超出浏览器、代理服务器或 Web 服务器的硬性限制（通常为 2KB 到 8KB 不等）。为了规避这一限制，开发者往往不得不妥协，改用 POST 方法来传送复杂的查询请求。
但这种妥协引入了新的技术债：POST 方法在语义上是非安全且非幂等的。这意味着浏览器和 CDN 无法自动缓存 POST 请求的响应，一旦发生网络抖动也无法安全地自动重试，甚至在用户刷新页面时会弹出“表单重复提交”的警告。为了彻底解决这一两难困境，IETF HTTP 工作组于 2026 年 6 月加速推进了一项技术草案。根据带请求体的安全 HTTP 方法草案显示，官方拟正式引入名为“QUERY”的全新 HTTP 请求方法。
兼顾安全与效率：融合 GET 与 POST 的双重优势
QUERY 请求方法的核心设计哲学在于“取长补短”。它允许客户端将查询条件（例如复杂的 JSON 结构、SQL 样式的查询语句或 XML 数据）放置在 HTTP 请求体（Request Body）中，从而彻底摆脱了 URL 长度的物理限制。
与 POST 不同的是，QUERY 在语义上被严格定义为“安全（Safe）”且“幂等（Idempotent）”的方法。由于 QUERY 请求仅用于检索数据而不改变服务器上的任何状态，它具备了与 GET 方法相同的特性。这意味着中间代理服务器、CDN 以及浏览器可以安全地对 QUERY 请求的响应进行缓存。当网络发生中断时，客户端（如浏览器或移动端 SDK）也可以在不征求用户同意的情况下，自动且安全地发起重试，从而显著提升了网络层面的容错率和加载性能。
引入 Accept-Query：赋能服务器动态协商
除了定义 QUERY 请求本身，该草案还配套引入了全新的“Accept-Query”响应头部字段。这一机制为客户端与服务器之间的内容协商提供了标准化的途径。
通过 Accept-Query，服务器可以在响应中显式声明自身能够理解和解析的查询格式（例如 application/json 或 application/sql）。当客户端首次与服务器通信，或收到不支持的查询格式错误时，可以通过该响应头得知服务器的真实偏好，进而调整后续 QUERY 请求体的数据格式。这为异构系统之间的数据交互和 API 版本平滑迁移提供了极大的便利。
目前，该草案仍在 IETF 内部进行密集的讨论与修改，当前版本的有效期将截止至 2026 年 12 月。如果能够顺利通过并最终写入 RFC 正式标准，QUERY 将成为继 GET 和 POST 之后，Web 开发者在构建复杂查询接口时的标准首选。
本报道由 圈小蛙（qxwa.com） 科技资讯站特约撰稿。🐸️