有一段时间我（错误地）认为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
答案 0 :(得分：2)
我同意你的方法，在搜索资源时使用GET似乎是合理的，并且如你提供的链接中所述，查询字符串的重点是做事情喜欢搜索。我同意当你想以幂等方式更新某些资源时PUT更合适（无论你多少次点击请求，结果都是一样的。）
所以一般来说，我会像你提议的那样做。现在，如果您受到GET请求的最大长度的限制，那么您可以使用POST或PUT，在JSON中传递您的参数，例如：
PUT /api/search
您可以将此视为发送新参数的“搜索资源”。我知道这似乎是一种解决方法，你可能会担心REST是关于避免URI中的动词。嗯，很少有情况下使用动词仍然可以接受和RESTful，例如如果涉及计算或转换以生成结果（有关此内容的更多信息，请检查this参考）。
PS。我认为这种解决方法仍然是RESTful，但即使不是，REST也不是一种痴迷和最终目标。务实并保持干净的API设计可能是一种更好的方法，即使在极少数情况下您不是RESTful。