Использование REST API для отделения базы данных от других REST API

Question

У меня возникли некоторые проблемы при формулировке вопроса, но в основном я обнаружил, что во время работы я обычно создаю Java Spring Rest API, который подключается к базе данных, и интерфейсное приложение использует этот API (веб-приложение). -> API сервиса -> база данных). Это связывает API службы приложений с хранилищем данных и часто определяет c вариант использования для внешнего интерфейса приложения. Я вижу много сервисных API, создающих одинаковые вызовы get для одной и той же базы данных. Мне это кажется неправильным.

Я считаю, что было бы лучше создать API для самой базы данных, а затем запустить API службы для этого. (веб-приложение -> API сервиса -> API хранилища данных -> база данных). Это позволило бы всем службам получать доступ к базе данных без непосредственного подключения к ней и необходимости управлять доступом к этой базе данных для 30 приложений. Это также позволило бы любому приложению, которому не нужно ничего, кроме данных, просто использовать существующий API хранилища данных. Я помню статью о том, как Amazon требует API для каждого хранилища данных, и вот как я мог бы это увидеть.

Является ли идея иметь API хранилища данных и подключаться к нему с использованием API службы склад ума? Или есть какой-то другой способ, которым я должен справиться с этим?

Answer 1

Читая то, что вы только что написали, мне кажется, что то, что у вас есть, - это "неправильно сделанные микросервисы", поскольку, насколько я понимаю, у вас есть несколько приложений, обращающихся к одной и той же базе данных / хранилищу данных, с точки зрения микросервисов это неправильно.

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

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

Конечно, один размер не подходит для всех, но я верю, что это хорошее руководство.