作者：清洁剂没看见家门口_200 | 来源：互联网 | 2023-10-12 14:26
如果要进行复杂的数据检索，发送大量数据但不更改服务器状态怎么办？现在，您有两个主要选择：使用GET，然后将所需的所有参数压缩到URL或标头中使用POST，并将请求视为不安全且不
如果要进行复杂的数据检索，发送大量数据但不更改服务器状态怎么办？
现在，您有两个主要选择：
- 使用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
Accept-Search: application/sql, application/graphql
|
这允许服务器通告它接受SEARCH请求，并用信号通知它将接受的特定查询格式。这类似于现有的Accept-Patch标头。
京公网安备 11010802041100号