应该如何瞬态资源以RESTful API

Question

检索有一段时间我是（错误地）认为一个RESTful API只是暴露CRUD操作持续了Web应用程序的实体。当你在“现实世界”中编写代码时，你很快就会发现这还不够。例如，银行账户转账不一定是持续的实体。这可能是一个短暂的资源，你POST到/transfers/和有效载荷您指定的细节：

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

使用POST这里是有道理的，因为它改变了服务器上的状态（$从一个账户10点移动到另一个每次这发生了POST）。

应在不影响服务器的情况下会发生什么？简单的第一个答案是使用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中的动词。那么，很少有例子可以使用动词，例如，在涉及计算或转换以生成结果的情况下（有关详细信息，请参阅this参考）。

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