RESTful Design: пейджинговые коллекции

Question

Я разрабатываю API REST, который требует принудительного подкачки (на х) со стороны сервера.

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

Вариант 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? Перенаправить в / resource / page / 0, ответить с какой-либо ошибкой или ответить точно так же, как / resource / page / 0 без перенаправления?

Answer 1

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

Answer 2

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

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

Answer 3

С моим ограниченным пониманием того, что такое REST, следующее может быть «самым» спокойным.

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

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

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