新 HTTP 请求方法 QUERY 填补 GET 与 POST 空白,广泛推行尚需时日
新 HTTP 请求方法 QUERY 填补 GET 与 POST 空白推行尚需时日新方法 QUERYRFC 10008由互联网工程任务组IETF发布它填补了 GET 和 POST 之间的空白将 POST 的请求体与 GET 的安全性和幂等性相结合。来源Rock1997当 HTTP 请求过长或过于复杂无法使用 GET 方法在 URI 中编码时开发者长期以来一直采用 POST 方法作为变通方案。然而这可能会引发问题。GET 请求被定义为安全且幂等的但 POST 不一定具备这些特性。而 QUERY 融合了两者的优点兼具二者功能。IETF 标准文档指出安全方法被定义为 本质上 只读的方法即 客户端在对目标资源应用安全方法时不会请求也不期望源服务器发生任何状态变化。同样合理使用安全方法也不会对源服务器造成任何损害、财产损失或异常负担。而当一个请求具有幂等性时无论重试多少次使用该方法的多个相同请求对服务器产生的预期效果与单个请求的效果相同。POST 请求并不总是满足这些标准但 QUERY 请求可以。与 POST 一样QUERY 操作的输入是作为请求的内容传递的而不像 GET 那样作为请求 URI 的一部分。与 POST 不同的是QUERY 允许进行缓存和自动重试等操作这正是因为它具有安全性和幂等性。伪装的只读请求灰狗研究公司首席分析师 Sanchit Vir Gogia 表示RFC 10008 意义重大因为它为网络上常用的变通方案赋予了协议身份。二十年来开发者一直将只读请求伪装成 POST 命令QUERY 在请求体中携带请求信息同时声明可以安全地重试和缓存。其重要性在于机器可读的意图重试引擎、缓存和自主代理会根据方法的声明来执行操作而非依据文档的意图。在自动化环境下语义就变成了策略。Gogia 解释道当请求能够轻松地适应 URI 时GET 方法可以正常工作但一旦开发者需要深度过滤、长标识符集或整个查询文档时它就无法正常工作了。此外URI 还会通过历史记录、书签和访问日志暴露信息将每个输入组合编码到地址中会悄然使每个排列组合成为一个独特的资源。Gogia 还说POST 解决了大小问题但未能兑现承诺。它的通用语义允许创建、修改和产生副作用因此没有缓存、重试引擎或网关有权假设某个给定的 POST 请求是可重复或可复用的。虽然 QUERY 解决了长期以来使用 POST 进行搜索的问题但这种新方法也存在一些需要注意的地方。软件工程师 Rickvian Aldi 在一篇博客文章中指出谨慎来看它解决了语义问题但并非解决了所有部署工作。前端代码仍然需要稳定的查询键服务器仍然需要验证和缓存控制头基础设施仍然需要支持这种新方法。新标准的推行尚需时日推行新标准往往需要时间因为标准的采用通常较为缓慢。在 QUERY 被广泛使用之前其他标准如 HTML 表单标准需要进行更新。网络超文本应用技术工作组等组织已经在开展这项工作。开源开发者 Daniele Teti 在一篇博客文章中表示将 RFC 作为提议标准发布并不意味着整个生态系统第二天就会支持它。这只是 IETF 标准制定过程的第一步规范已经稳定并可以实施但浏览器、服务器、代理、CDN 和客户端库实际采用它还需要时间。目前主流浏览器都不支持 QUERY 方法不过在服务器端Node.js 和 Go 支持该方法。Gogia 指出RFC 10008 的作者来自 Cloudflare、Akamai 和 greenbytes 的工程师也意识到了这一点。Gogia 说标准本身就设计了回退机制。存在一个 位置桥接 机制当 QUERY 遇到不支持它的基础设施时就可以退回到 GET 方法。文档中也提到客户端可以在后续请求中切换到 GET 方法以简化处理。从这个角度看等效资源与其说是一种理论上的妥协不如说是一种应急方案而这一特性最有可能帮助该方法度过发展初期的难关。网络开发、开发方法、软件开发