复杂的搜索本质上不是RESTful的吗？

我正在编写（或试图编写）一个RESTful Web服务。它的主要功能之一是允许客户端从服务器搜索文件。这似乎是一个教科书式的获取场景，但搜索太复杂/灵活，无法输入URL

相反，我通过XML对象接受搜索参数。显而易见的问题是。事实上，我使用的Web服务器只是忽略了它们，所以如果我想忽略的话，我不能忽略这种做法

，但这显然不是我真正想要的。它将完成工作（实际上我现在正在使用它），但它显然不是工作的正确请求方法。我决不是在创造新的资源；我实际上是从现有文件中复制字节，并将其反馈给客户端。没有比这更多的了

我面临的问题是，一个文件请求中有太多的字段无法放入URL（一些是可选的，一些是强制性的，一些是基于其他字段的条件强制性的，等等…），但我唯一的其他选择是故意滥用REST的4个关键字中的一个。这两个都不是很安静

是否存在这样一种情况：请求可能变得过于复杂，无法维持纯粹的REST方法，还是我没有正确地处理这个问题？我是否完全没有注意到这一点，而是在使用RPC而不是REST

注意：我知道在这个话题上有一些类似的问题，但似乎没有一个是官方的共识（主要回答是“我在使用POST，但它很黑”），而且很多都是几年前的问题。我希望REST社区已经就如何处理这些问题达成了更大的一致，或者至少同意这不是一件让人安心的事情

复杂的搜索本质上不是RESTful的吗

没有

传统上，用于复杂搜索的协议使用表单来收集用于搜索的可配置令牌。媒体类型的处理规则告诉客户机如何将令牌组合成可用于获得结果的新标识符

这似乎是一个教科书式的获取场景，但搜索太复杂/灵活，无法输入URL

因此，如果您有太复杂的东西无法表示为标识符，那么表单处理也无法为您解决问题

在HTTP中，适当的选择是使用POST

这显然不是这份工作的正确要求方法。我决不会创造新的资源

这显然是对工作的正确选择，因为

根据资源自身的特定语义处理请求中包含的表示

创建下属资源是POST的一个用途，但并没有那么严格。换句话说，使用POST并不是滥用，因为您对POST的使用符合HTTP的统一接口

它在某些方面是不足的——查询通常都是安全的和幂等的，POST不会公布这些约束中的任何一个，这意味着通用客户机不能利用它们。如果你能得到更好的东西，你会用它

你正在寻找的方法是；这可能是完美的，除非没有被接受为标准

假设您的路由框架具有灵活性，您可以将POST和SEARCH都公开为，这将允许了解SEARCH的客户端在可用时使用该方法

我面临的问题是，对文件的请求有太多的字段，无法将其放入URL（一些是可选的，一些是强制性的，一些是基于其他字段的有条件强制性的，等等…）

您知道，对于一系列表单来说，这些听起来都不是特别难处理的，因此您可能需要重新考虑将这些信息编码到URI中是否太复杂

也就是说，开发REST api的一个常见起点是从“我如何处理web页面”这个问题开始，然后从这里开始看看是否可以使web页面机器可读