Запросы составленных ресурсов - PullRequest
Новая
       24

Запросы составленных ресурсов

0 голосов
/ 14 ноября 2018

В настоящее время я пытаюсь создать небольшой REST API.

Допустим, у меня есть ресурс (book), который состоит из нескольких других ресурсов (например, author).

Оба ресурса имеют отдельные API, которые развернуты в разных сервисах (со своими собственными базами данных).

Автор ничего не знает о книгах. Однако книги знают своего автора.

Теперь я хочу поддерживать такие запросы, как books?author.surname=Poe.

Я пытаюсь понять, как может выглядеть реализация, поддерживающая такого рода фильтрацию связанных ресурсов.

Поскольку автор не знает о книгах, я не могу попросить автора API дать мне подходящих авторов и перейти к соответствующим книгам. Что я мог сделать, так это спросить для каждой книги, которую я имею в БД, API автора для этого автора книги, а затем отфильтровать его по имени автора. Но это звучит ужасно нереально.

Я полагаю, что почти каждая SOA сталкивается с этой проблемой довольно рано в проекте.

Я спрашиваю, существует ли уже общий шаблон или лучший метод , который решает эту проблему?

1 Ответ

0 голосов
/ 15 ноября 2018

Ваш случай явно требует реализации надежного отношения типа «один ко многим» между этими объектами (ресурсами). Шаблон, который вы ищете, это ... реляционные базы данных ! Они были изобретены для этого конкретного случая использования.

Вот что я бы предложил:

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

Рассмотрим следующие основные недостатки:

  1. Возможно, вы получите недостаточно выполняющихся запросов ;
  2. Вы не сможете использовать индексирование базы данных и другие полезные функции в будущем. Это может помешать вашей способности правильно масштабировать в будущем
  3. Возможно, вы получите противоречивые данные . Например, автор в Книге, которого сейчас нет в Авторах. Таким образом, вам нужен способ иметь надежные ограничения (подумайте внешние ключи) между базами данных, хотя это может быть достижимо ненужная сложность
  4. Вы пропускаете контекст внутренней транзакции , который предоставляет база данных. Если это понадобится вам в будущем, у вас возникнут проблемы.

После рассмотрения вышеизложенного , если вы по-прежнему считаете, что у вас есть веские основания размещать эти связанные данные в разных базах данных, вы можете попробовать любой из следующих вариантов, которые приходят на ум (учитывая, что каждый из них является Обходной путь, который имеет свои недостатки):

  1. Реализация своего рода соединения между API doing as little calls as possible. Я имею в виду уникальный идентификатор автора на ресурсе «Авторы», сначала запросите авторов с именем и получите его уникальный идентификатор. Затем используйте этот идентификатор для запроса книг и получения всех соответствующих книг. Таким образом, у вас будет только 2 звонка вместо тысяч. Это решение имеет постоянную O (1) вместо O (N) - линейная - сложность.

  2. Replication данных (но это как бы отрицательно сказалось на цели, если целью вашего проекта является изоляция данных). Это решит проблему с запросом, но вам придется заниматься репликациями и дополнительным администрированием вместе.

  3. Реализация соединения между отдельными базами данных с использованием dblink или аналогичной функции баз данных, которые вы используете, для запроса их как единой базы данных.

  4. Используйте среду для связи с событиями между отдельными микро-сервисами, но соглашайтесь на возможную согласованность и другие недостатки. См. Статью здесь.

Надеюсь, это поможет!

...