Дизайн RESTful: Коллекции пейджинга

Я проектирую REST api, который требует подкачки (за x), выполняемый со стороны сервера.

Каким будет правильный путь для просмотра любой коллекции ресурсов:

Вариант 1:

GET /resource/page/<pagenr>
GET /resource/tags/<tag1>,<tag2>/page/<pagenr>
GET /resource/search/<query>/page/<pagenr>

Вариант 2:

GET /resource/?page=<pagenr>
GET /resource/tags/<tag1>,<tag2>?page=<pagenr>
GET /resource/search/<query>?page=<pagenr>

Если 1, что мне делать с GET/ресурсом? Перенаправление на /resource/page/ 0, ответ с некоторой ошибкой или ответом с тем же именем, что и /resource/page/ 0 без перенаправления?

Ответ 1

То, что выглядит URI, не является самой важной частью. То, о чем вы должны думать, - это то, как оно представлено пользователю. Например, страница должна иметь ссылку на "следующую" страницу и другую ссылку на "предыдущую" страницу (если она есть). Взгляните на RFC 5005 Пейджинг и архивирование каналов

Ответ 2

С моим ограниченным пониманием того, что такое REST, тогда может быть "самым" спокойным.

GET /resource/?page=<pageenr>&asof=<datetime>

Поскольку содержимое представления никогда не изменится неожиданно, и можно использовать кеширование.

Но чтобы ответить на ваш вопрос, я думаю, что страница параметров является предпочтительным.

Ответ 3

Я бы выбрал вариант (2). Почему?

Вы можете позже добавить параметр размера страницы в запрос, чтобы клиент мог указать размер страницы.
Если параметр страницы не указан, вы можете просто вернуть первую страницу (по умолчанию). Во многих случаях клиенту может понадобиться только первая страница, поэтому он упрощает протокол между клиентом и сервером.