应该如何在 RESTful API 中检索瞬态资源

Question

有一段时间我（错误地）认为 RESTful API 只是将 CRUD 操作暴露给 Web 应用程序的持久实体。当您在“现实世界”中编写代码时，您很快就会发现这还不够。例如，银行账户转账不必是持久实体。它可能是一个临时资源，您可以在其中 POST 到 /transfers/ 并在有效负载中指定详细信息：

{"accountToCredit":1234, "accountToDebit":5678, "amount":10}

在这里使用POST 是有意义的，因为它会改变服务器上的状态（每次POST 发生时，$10 都会从一个帐户转移到另一个帐户）。

在不影响服务器的情况下应该怎么办？简单的第一个答案是使用GET。例如，您想要获取少于 100 美元的储蓄和支票账户列表。然后，您可以将GET 之类的东西称为/accounts/searchResults?minBalance=0&maxBalance=100。但是，如果您的搜索参数需要使用不适合 GET 请求的最大长度的复杂对象，会发生什么情况。

我的第一个想法是使用POST，但在考虑了更多之后，它可能应该是PUT，因为它不会改变服务器的状态，但根据我的（有限的）理解，我总是这样PUT 更新资源，POST 创建资源（如创建此搜索结果）。那么在这种情况下应该使用哪个呢？

我发现以下链接提供了一些信息，但我不清楚在不同情况下应该使用什么：

Transient REST Representations

How to design RESTful search/filtering?

RESTful URL design for search

Answer 1

我同意您的方法，在搜索资源时使用GET 对我来说似乎是合理的，正如您提供的链接之一所述，查询字符串的全部意义在于执行搜索等操作。我也同意PUT 更适合你想以幂等方式更新某些资源（无论你点击多少次请求，结果都是一样的）。

所以一般来说，我会按照你的建议去做。现在，如果您受到GET 请求的最大长度的限制，那么您可以使用POST 或PUT，在JSON 中传递您的参数，在如下URI 中：

PUT /api/search

您可以将其视为发送新参数的“搜索资源”。我知道这似乎是一种解决方法，您可能担心 REST 会避免 URI 中的动词。好吧，在少数情况下使用动词仍然是可以接受和 RESTful 的，例如如果需要计算或转换来生成结果（有关更多信息，请查看this 参考）。

PS。我认为这种解决方法仍然是 RESTful，但即使不是，REST 也不是一种痴迷和最终目标。务实并保持干净的 API 设计可能是更好的方法，即使在少数情况下您不是 RESTful。