定义新的HTTP方法:HTTP SEARCH


如果要进行复杂的数据检索,发送大量数据但不更改服务器状态怎么办?
现在,您有两个主要选择:

  • 使用GET,然后将所需的所有参数压缩到URL或标头中
  • 使用POST,并将请求视为不安全且不可缓存

这些都不是一个好的选择。
HTTP SEARCH是一种提议的新HTTP方法,旨在解决此问题。
SEARCH请求是可以包含正文的安全(不更改目标资源)请求,我们可以清晰地发送复杂的数据查询,而无需将其编码为URL或使用POST请求。
请注意,这仍然只是标准草案。详细信息可能会更改,甚至名称仍未100%固定(该草案被正式命名为“带有主体的安全方法”,而不是引用SEARCH,以便于更改)。
顺带一提,但是到2021年3月,它已经成为IETF HTTP正式采用的规范草案,因此,如果一切顺利的话,它将朝着最终标准化的方向走。
使用SEARCH的原始HTTP / 1.1请求可能看起来像这样:
SEARCH /customers HTTP/1.1
Host: example.com
Content-Type: application/sql

SELECT username, email
WHERE DATEDIFF(DAY, GETDATE(), signup_date) > 7

目前,规范尚未将此查询的结果定义为可缓存。原因尚不完全清楚,但是我怀疑这是因为当今的缓存技术从来没有考虑到主体,而开始这样做将是一个重大的变化,需要进行仔细的思考和咨询。
好处:

  • 请求主体清晰易读且易于管理-无需特殊编码或长度限制
  • 语义很明确:它只是查询数据
  • 您现在可以在同一URL上自由使用GET,SEARCH和POST的独立语义

您可以使用它来支持任何喜欢的语言(从GraphQL到SQL到OData)的复杂查询。当然,服务器需要了解您所使用的查询语言,并且您应该在请求的Content-Type标头中清楚地指出格式,以使其成为可能。
这对于GraphQL尤其有趣。GraphQL当前完全属于上述陷阱,支持GET请求或POST请求,但在两种情况下都存在一些尴尬的警告。转向SEARCH以处理只读GraphQL请求将显着改善UX,并且可以使GraphQL更好地与内置HTTP功能集成,例如将来进行缓存。
 
除了SEARCH之外,该规范还定义了Accept-Search标头。可以将其用于类似这样的响应中:
HTTP/1.1 200 OK
<other headers>
Accept-Search: application/sql, application/graphql

<normal response>

这允许服务器通告它接受SEARCH请求,并用信号通知它将接受的特定查询格式。这类似于现有的Accept-Patch标头。