HTTP SEARCH 方法是否标准化？

Question

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

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

为了完整起见，以下是我想到的优点和缺点：

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

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

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

从功能上来说，我想我的问题是：我可以依靠自称符合标准的软件来处理 SEARCH 方法吗？如果他们不处理，我可以诉诸他们声称符合标准来迫使他们处理吗？进一步归结起来，它是一个可靠的动词吗？

Answer 1

SEARCH 在RFC 5323中的 IETF 标准轨道上定义。也就是说，它目前仅适用于WebDAV，并且很少有服务器支持它。