REST API-дизайн для коллекции, который, естественно, разделен на подколлекции

Question

У меня есть коллекция запросов, отправляемых с моего клиентского приложения на сервер, который их обрабатывает. Я создаю новый запрос с этим запросом

POST api/v1/requests 

После запроса отправить его recieves статус PENDING и после того, как оценивали STAUS изменяется на RESOLVED. Таким образом, у меня есть коллекция requests, которая разделена на 2 подвыбора: requests.pending и requests.resolved. Мне нужен способ получить доступ к ним с обеих сторон, а также кэшировать эти страницы.

Будет ли остальной путь, чтобы сделать их как этот:

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 искусственные (или магазины) поверх нее. Тем не менее я думаю, что я не могу просто подойти к этому с параметрами запроса, как это в качестве параметров запроса не должны кэшировать witin протокола REST серверов кэша:

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

Answer 1

Есть целый LOT способов сделать ваши URLs здесь, и я уверен, что будет несколько (сильных) мнений.

Моя рекомендация будет следующим ...

POST ../api/v1/request 

v1 против 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 

Вот что я думаю ... Из того, что я могу сказать, вы на самом деле пытаетесь запросить у вас запросы.

Как правило, более конкретные/вложенные URL-адреса относятся к дочерним отношениям.

Например, получить все адреса для конкретного клиента:

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

Все вышеуказанные адреса могли бы быть кэшируемым и bookmarkable.