导读:IETF在本月正式宣布新的规范草案:RFC 10008,支持幂等、安全与大型BODY,可以说是增强版本的GET方法。
RFC地址:https://www.rfc-editor.org/rfc/rfc10008.html
从历史上看,开发者仅有两种均不完美的选择。
使用 GET 请求安全、幂等且可缓存。但查询参数位于 URL 中,不同代理服务器的请求大小限制各不相同,而且请求 URI 比请求体更容易被记录。复杂的过滤对象会变成难以阅读的字符串。
POST 请求支持大型请求体。但是,由于缺乏对资源和服务器的具体信息,协议本身并没有表明该操作是安全且只读的。缓存也会相应地处理这种情况。
因此,QUERY BODY支撑来自POST,安全、幂等语义来自GET。
QUERY /users HTTP/1.1Host: example.orgContent-Type: application/json{"role": "admin","sort": "name","page": 1}
输入通过请求体传递,例如POST。与POST不同,QUERY方法是显式安全且幂等的,因此缓存和中间件可以将其视为GET,安全且幂等。
QUERY 要解决的很明确 ,GET 的 URL 长度有限、编码复杂查询参数不自然;POST 虽能带 Body,但不是幂等的,CDN 不可缓存,中间件不能自动重试。QUERY 就是要在协议层面把两件事同时完成。
此外QUERY请求可以自动重复或重启,而无需担心部分状态更改。
许多开发者多年来一直呼吁实现这一点。但问题在于,HTTP 生态系统几十年来对请求GET体的处理方式并不一致。有些代理会移除请求体,有些服务器会忽略它们,有些框架则会拒绝它们。将查询编码到请求 URI 中,会将查询输入的每种组合都视为一个独立的资源,从而造成语义上的混乱。
这里也存在隐私问题:当查询包含敏感信息时,RFC 指出 URI 日志记录的可能性使得QUERY优于GET。
如果重新定义GET会破坏现有的基础设施,而新方法更加安全。
Accept-Query的响应头
RFC 引入了一个头部,允许服务器声明它接受哪些查询格式:
Accept-Query: application/x-www-form-urlencoded, application/sql客户端可以先发送请求OPTIONS或HEAD寻求QUERY支持,然后再提交完整的请求。
回应QUERY可以指向永久性结果资源:
HTTP / 1.1 200 OKContent-Location:/contacts/stored-results/ 17Location:/contacts/stored-queries/ 42
根据 RFC 规范,这些方法各有不同的用途。
Content-Location
允许客户端发送后续请求
GET
以检索刚刚执行的查询的结果。
Location
允许客户端重复执行相同的查询,而无需重新发送请求体。
303 See Other
重定向则更进一步:服务器将客户端重定向到等效资源,而不返回任何结果。这对于服务器希望在客户端获取结果之前预先生成的高成本查询非常有用。
大多数 GraphQL API 都使用POSTURL 来进行只读操作,因为查询语句对于 URL 来说太长了。
QUERY这种方法移除了变通方案:在请求体中发送完整的 GraphQL 查询语句,并在协议层面保持语义安全。
早期草案曾使用“SEARCH”关键字,之后HTTP工作组最终确定使用“QUERY”。其他备选方案(“SEARCH”、“PROPFIND”、“REPORT”)均源自WebDAV项目。“QUERY”之所以被选中,是因为它对应于URI的查询组件,并且描述的是一种通用的只读操作,而非特定的搜索用例。
RFC 10008 由 J. Reschke(greenbytes)、JM Snell(Cloudflare)和 M. Bishop(Akamai)共同撰写,并于 2026 年 6 月作为拟议标准发布。
该规范已经最终定稿。Cloudflare 和 Akamai 共同撰写了该规范,这意味着 CDN 级别的支持可能先于框架集成。开发者还可密切关注 curl、浏览器fetch()和服务器框架的实现公告。
对于具有复杂筛选有效负载、报表生成器、分析仪表板和 AI 驱动的搜索端点的 API 而言,QUERY是自 HTTP 语义PATCH被广泛采用以来之最重要补充。
作者:场长
参考:
https://medium.com/@anmjawad007/http-finally-gets-a-method-its-needed-for-decades-meet-query-bb1b77def9a3
本篇文章为 @ 场长 创作并授权 21CTO 发布,未经许可,请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 微信公众号。
该文观点仅代表作者本人,21CTO 平台仅提供信息存储空间服务。
请扫描二维码,使用微信支付哦。