Как можно обрабатывать постраничные результаты из RESTful API с поддержкой гипермедиа, если базовые данные могут измениться?

Question

Я создаю гиперссылку RESTful API, которая будет использоваться для запроса транзакционных данных. Предполагается, что результаты будут разбиты на страницы.

Каждый вызов API запрашивает индексную таблицу базы данных. Поскольку я не хочу сохранять серверы результатов из-за соображений памяти, я думал получить данные на основе rownum, в зависимости от того, какая страница запрашивается. НАПРИМЕР. на странице 1, WHERE rownum <= 10, на странице 2, WHERE rownum BETWEEN 11 AND 20 и т. д.

Однако данная база данных реплицируется из производственной системы и может потенциально добавлять записи в область уже запрошенного набора результатов. НАПРИМЕР. запрашивается страница 1 -> возвращается 10 строк -> транзакция вставлена ​​в строку 5. Теперь вторая страница будет содержать запись, уже отображаемую на первой странице, так как результаты существенно подталкиваются к rownum.

Что было бы хорошим способом достижения моей цели создания API RESTful, управляемого гипермедией, который предоставляет разбитые транзакционные данные из базы данных без привязки к наборам результатов в течение всего сеанса?

Answer 1

Это довольно распространенная проблема, и на самом деле не так много подходов. я могу думать только три, на самом деле:

• Вы не заботитесь, и результат не изменится. Это поведение stackoverflow: если вы на странице 2 страницы вопросов и кто-то задает новый вопрос, при нажатии на стр. 3 вы можете получить один или несколько вопросов, которые уже были указаны на стр. 2, потому что индекс сдвинулся.

• Если вы не хотите хранить в памяти фактические данные, у вас много проблем. Вы можете сохранить обработчик для результирующего набора, а не сами результаты, и зациклиться на нем, получая количество строк, которое вам действительно нужно. Например. вы запускаете select, выбираете 10 строк и сохраняете обработчик набора результатов. Вместе со строками вы возвращаете клиенту уникальный идентификатор запроса. Проблема будет в том случае, если у вас задан диапазон, потому что вы не можете «перемотать» курсор базы данных, и это будет означать кеширование результатов, которые вы, возможно, захотите сделать в любом случае. Но если вы сделаете это так, рано или поздно вы все равно получите все результаты в памяти.

• Вы все еще можете использовать некоторую память, но сохраните только уникальный идентификатор строк, связанных с уникальным идентификатором запроса, как указано выше. Это может работать, но только если строки могут быть добавлены, а не удалены или обновлены (если они обновлены, они могут больше не соответствовать запросу).

Лично я бы с опцией 1.