постраничный результат запроса с несколькими заголовками

Question

У нас есть микросервис для моделирования отношений между объектами. Отношение определяется между первичными и вторичными объектами с ограничениями мощности, такими как 1-1, 1-N, N-N и т. Д. Микросервис предоставляет API, такие как Создать отношение, Найти отношения, Получить дополнительные, Получить основные цвета и т. Д.

API запроса «Получить вторичные объекты» принимает первичный объект и возвращает обратно все связанные вторичные объекты. Поскольку связанный вторичный объект может быть большим, результаты разбиваются на страницы.

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

Мы недавно определили, что микросервис-потребитель немного болтал с микросервисом отношений, поскольку ему приходилось многократно вызывать API-интерфейс «Получить вторичные данные», учитывая, что было несколько первичных объектов, для которых нужно было извлекать вторичные объекты.

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

Здесь мы ищем предложения по разработке этого массового API. Любые входные данные приветствуются.

Answer 1

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

Простой и обслуживаемый способ обработки вашей службы отношений - это предварительная обработка запроса путем некоторой сортировки запрошенных первичных объектов (т.е. сортировка в алфавитном порядке по Id), а затем просто итерация по первичным объектам, добавление вторичных объектов до ответа, пока ответ не будет заполнен.

Самое простое для клиентов - всегда использовать один и тот же пакетный запрос и просто добавить индексный номер или маркер страницы в запрос.

Я бы порекомендовал маркер страницы, который упоминает последний увиденный элемент (например, lastSeen=primaryId,secondaryId (который вы должны каким-то образом запутать, чтобы избежать утечки абстракции)). Затем служба может просмотреть исходный запрос и узнать, где продолжить итерацию по всем первичным объектам.

Кроме того, вы можете закодировать достаточно информации в маркер страницы, чтобы вы могли восстановить все, что вам нужно, из исходного запроса. Это позволяет вам внести некоторые коррективы в запрос при последующих запросах. (Например, если клиент запрашивает праймериз A-Z и вы возвращаете вторичные объекты A1 - J5 в первом ответе, вы можете изменить запрос на J-Z; already seen J5, закодировать его, чтобы не пропустить детали реализации и верните его клиенту в качестве маркера страницы.) Затем, вместо ответа original request + page number, клиент просто отвечает маркером страницы.

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

Еще одним соображением является база данных, которую вы используете. Например, в DynamoDB способ получения 100-го элемента для запроса, подобного select * from secondaries where primaryId='ABC', требует, чтобы вы прочитали все элементы до 100-го элемента. Если у вас есть база данных NoSQL или вы думаете, что можете перейти к базе данных NoSQL в будущем, вы можете обнаружить, что маркер страницы значительно упрощает поддержание того, где вы находитесь в наборе результатов (по сравнению с порядковый номер).

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

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