Question

我有一组请求从我的客户端应用程序发送到处理它们的服务器。我使用此请求创建了新请求

POST api/v1/requests

发送请求后，它将收到状态PENDING，并在评估后将状态更改为RESOLVED。因此，我的集合requests分为2个子集合：requests.pending和requests.resolved。 我需要一种方法来获取对它们的可访问权限，并且可以缓存这些页面。

以这种方式制作它们的REST方法：

GET api/v1/requests/page/:page            - returns pages of all requests collection
GET api/v1/requests/pending/page/:page    - returns pages of pending requests collection
GET api/v1/requests/resolved/page/:page   - returns pages of resolved requests collection

我对这种方法感到有点不舒服，因为主要的资源是requests集合，我在其上创建了2个人工集合（或商店）。尽管如此，我认为我不能用这样的查询参数来解决这个问题，因为缓存服务器不应该在REST协议中缓存查询参数：

GET api/v1/requests/?page=:page            - returns pages of all requests

Answer 1

在这里有一些很多的方式来管理您的网址，我确信会有几个（强烈）意见。

我的建议如下......

POST ../api/v1/request

v1 vs 1是我个人的偏好，我认为v1更具描述性，而不仅仅是1。

对于资源名称，有很多关于复数与单数的讨论。我的偏好是单数。

// redirects to a paginated url
GET ../api/v1/request -> ../api/v1/request?page=1&rpp=10

// your default page that return all types of requests ordered
// however you want, most likely reverse date created.
GET ../api/v1/request?page=1&rpp=10

// returns pending requests.
GET ../api/v1/request?page=1&rpp=10&status=pending

// returns resolved requests.
GET ../api/v1/request?page=1&rpp=10&status=resolved

以下是我的想法......据我所知，您实际上是在尝试查询您的请求。

通常，更具体/嵌套的网址用于子关系。

例如，获取特定客户的所有地址：

GET ../api/v1/customer/1/address

以上所有网址都可以缓存并可收藏。

用于集合的REST API设计，自然分为子集合

1 个答案: