3

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

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

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

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

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

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

瞬态 REST 表示

如何设计 RESTful 搜索/过滤？

用于搜索的 RESTful URL 设计

4

1 回答 1

2

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

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

PUT /api/search

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

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

于 2013-05-13T21:55:02.437 回答