http - HTTP SEARCH 方法是否标准化？

Question

我正在考虑如何实现一个用于搜索的 REST API 端点。正如我所看到的，对于如何实现搜索选项，我有四个选项，每个选项都有优点和缺点：

1. 使用带有查询字符串参数的 GET 端点
2. 使用带有负载的 GET 端点（例如，JSON 负载）
3. 使用带有有效负载的 POST 端点
4. 使用带有有效负载的 SEARCH 端点

为了完整起见，以下是我正在考虑的利弊：

• 带有查询字符串参数的 GET 端点
  • Pro - 准确的动词，符合标准
  • 缺点 - 有限的选项结构（仅限键/值）和 URL 大小限制
• 带有负载的 GET 端点（例如，JSON 负载）
  • Pro - 准确的动词，没有大小限制
  • Con - HTTP 规范说 GET 请求没有有意义的有效负载，并且某些框架可能不支持它（相关问题）
• 带有有效负载的 POST 端点
  • Pro - 符合标准，无尺寸限制
  • Con - 搜索是幂等的，而 POST 不是。基本上，这是错误的动词。
• 带有有效负载的 SEARCH 端点
  • Pro - 准确的动词，没有大小限制
  • Con - 是一个晦涩的（非标准的？）HTTP动词

可以就其中哪一个是最好的进行冗长、细致入微和固执己见的讨论，但讨论不是这个问题的目的。相反，我问：SEARCH 动词是否只是晦涩难懂且很少使用但仍然是官方方法，还是不标准？

我找到了这个方法的草稿，但没有更多关于它的官方文档。该草案呼应了我在上面提出的四难困境中的一些观点。在我看来，该方法仍然只是一个草案，不能称为“标准”，尽管我不太熟悉如何阅读这些文件。

在功能上，我想我的问题是：我可以依靠自我吹捧的符合标准的软件来处理 SEARCH 方法吗？如果他们不处理，我可以诉诸他们的标准合规要求来强迫他们处理吗？进一步归结，它是一个可靠的动词吗？

标签： httpsearchspecifications

Answer 1

SEARCH 在RFC 5323的 IETF Standards Track 中定义。也就是说，它目前只适用于WebDAV，很少有服务器支持它。