Разбиение на страницы в веб-приложении REST

Предполагая, что maxdays в основном возвращает позицию вашего выбора selectInput, вы можете сделать следующее:

library(shiny)

my_choices <- c(111, 222, 333)

ui <- fluidPage(
  selectInput('p_id', 'ID:', my_choices),
  uiOutput('uiID')
)

server <- function(input, output, session) {
  maxdays <- reactive(which(my_choices %in% input$p_id))

  output$uiID <- renderUI({
    selectInput('days', 'Days:', choices = seq(1,maxdays()))
  })
}

shinyApp(ui, server)
325
задан Community 23 May 2017 в 02:34
поделиться

9 ответов

Я думаю, что проблема с версией 3 является скорее проблемой "точки зрения" - видите ли вы страницу как ресурс или продукты на странице.

Если вы видите страницу в качестве ресурса это идеальное решение, так как запрос для страницы 2 всегда будет давать страницу 2.

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

Например, клиент сохраняет ссылку на страницу со списком продуктов X, и в следующий раз, когда ссылка будет открыта, рассматриваемый продукт может больше не отображаться на странице X.

65
ответ дан 23 November 2019 в 00:53
поделиться

Я согласен с Fionn, но я сделаю еще один шаг и скажу, что для меня страница не ресурс, это свойство запроса. Это заставляет меня выбирать только строку запроса варианта 1. Это просто чувствует себя хорошо. Мне очень нравится, как Twitter API структурирован спокойно. Не слишком просто, не слишком сложно, хорошо документировано. Что бы там ни было, это мой дизайн «идти к», когда я стою на пороге, делая что-то одно против другого.

104
ответ дан 23 November 2019 в 00:53
поделиться

В настоящее время я использую схему, подобную этой, в моих приложениях ASP.NET MVC:

, например, http: // application / products / by-date / page / 2

В частности, это: http: // application / products / Date / Ascending / 3

Однако я не очень доволен включением в маршрут подкачки и сортировки информации таким образом.

Список товаров (в данном случае товаров) является изменчивым. т. е. в следующий раз, когда кто-то вернется к URL-адресу, который включает параметры подкачки и сортировки, полученные результаты могут измениться. Таким образом, идея http: // application / products / Date / Ascending / 3 как уникального URL-адреса, указывающего на определенный, неизменный набор продуктов, теряется.

4
ответ дан 23 November 2019 в 00:53
поделиться

Я склонен согласиться с slf, что «страница» на самом деле не ресурс. С другой стороны, вариант 3 чище, его легче читать, и он может быть легче угадан пользователем и даже напечатан при необходимости. Я разрываюсь между вариантами 1 и 3, но не вижу причин, чтобы не использовать вариант 3.

Кроме того, хотя они выглядят хорошо, один недостаток использования скрытых параметров, как кто-то упоминал, а не строк запроса или URL Сегменты - это то, что пользователь не может делать закладки или напрямую ссылаться на определенную страницу. Это может или не может быть проблемой в зависимости от приложения, но просто кое-что, о чем нужно знать.

1
ответ дан 23 November 2019 в 00:53
поделиться

Я использовал решение 3 раньше (я пишу много приложений django). И я не думаю, что с этим что-то не так. Он так же генерируемый, как и два других (в случае, если вам нужно сделать несколько операций по очистке или тому подобное), и выглядит чище. Кроме того, ваши пользователи могут угадывать URL-адреса (если это общедоступное приложение), и людям нравится иметь возможность идти прямо туда, куда они хотят, и угадывание URL-адресов дает им возможность.

0
ответ дан 23 November 2019 в 00:53
поделиться

Я всегда использовал стиль варианта 1. Кэширование не было проблемой, поскольку в моем случае данные все равно часто меняются. Если вы разрешите настраивать размер страницы, данные снова нельзя будет кэшировать.

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

11
ответ дан 23 November 2019 в 00:53
поделиться

Вариант 1 кажется лучшим, поскольку ваше приложение рассматривает разбиение на страницы как метод создания другого представления того же ресурса.

При этом схема URL-адреса относительно не важна. . Если вы разрабатываете свое приложение для управления гипертекстом (поскольку все приложения REST должны быть по определению), то ваш клиент не будет создавать никаких URI самостоятельно. Вместо этого ваше приложение будет давать ссылки клиенту, и клиент будет следовать по ним.

Один из видов ссылок, которые может предоставить ваш клиент, - это ссылка для разбивки на страницы.

Приятным побочным эффектом всего этого является то, что даже Если вы передумаете о структуре URI разбиения на страницы и на следующей неделе реализуете что-то совершенно другое, ваши клиенты смогут продолжить работу без каких-либо изменений.

24
ответ дан 23 November 2019 в 00:53
поделиться

HTTP имеет большой заголовок Range, который также подходит для разбивки на страницы. Вы можете отправить

Range: pages=1

, чтобы получить только первую страницу. Это может заставить вас переосмыслить, что такое страница. Возможно, клиент захочет другой ассортимент. Заголовок диапазона также работает для объявления заказа:

Range: products-by-date=2009_03_27-

, чтобы получить все продукты старше этой даты, или

Range: products-by-date=0-2009_11_30

, чтобы получить все продукты старше этой даты. «0», вероятно, не лучшее решение, но RFC, похоже, хочет что-то для начала диапазона. Могут быть развернуты HTTP-парсеры, которые не будут разбирать единицы = -range_end.

Если заголовки не являются (приемлемым) вариантом, я считаю, что первое решение (все в строке запроса) - это способ работы со страницами. Но, пожалуйста, нормализуйте строки запроса (сортировка пар (ключ = значение) в алфавитном порядке). Это решает проблему дифференцирования "? A = 1 & b = x" и "? B = x & a = 1".

36
ответ дан 23 November 2019 в 00:53
поделиться

Странно, что никто не указал, что в Варианте 3 параметры расположены в определенном порядке. http // application / products / Date / Descending / Name / Ascending / page / 2 {{ 1}} и http // application / products / Name / Ascending / Date / Descending / page / 2

указывают на один и тот же ресурс, но имеют совершенно разные URL-адреса.

Для меня вариант 1 кажется наиболее приемлемым, так как он четко разделяет «Что я хочу» и «Как я хочу» это (между ними даже стоит вопросительный знак lol) . Полностраничное кеширование может быть реализовано с использованием полного URL-адреса (все параметры в любом случае будут иметь одну и ту же проблему).

Единственное преимущество подхода «Параметры в URL» - чистый URL. Хотя вам нужно придумать способ кодирования параметров и их декодирования без потерь. Конечно, вы можете использовать кодирование / декодирование URL-адресов, но это снова сделает URL-адреса некрасивыми:)

8
ответ дан 23 November 2019 в 00:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: