Дизайн 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). Почему?

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