Нужно ли разделять API для клиентской и административной части?

Question

Я думаю о следующей задаче. В моем проекте 2 части:

1) API с использованием Android клиента
2) бэк-офис (часть администратора)

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

Структура проектов будет выглядеть следующим образом:

MyProject.FrontOffice.API
MyProject.FrontOffice.Services
MyProject.FrontOffice.Data

MyProject.BackOffice.API
MyProject.BackOffice .Services
MyProject.BackOffice.Data

Оба проекта находятся в одном решении, но проблема в том, что довольно большая часть кода будет продублирована в обеих частях.

Вторая идея состоит в том, чтобы не отделять его и разрешать его с помощью балансировщиков нагрузки (он будет балансировать между несколькими экземплярами API; некоторые для клиента и некоторые для части администратора).

Как вы думаете, какие лучше подойдет и почему?

Answer 1

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

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

Настоятельно рекомендуем использовать отдельные бизнес-логики c слой, предоставляемый через конечные точки API.

Answer 2

Это факт.

Вы НЕ ДОЛЖНЫ отделять свой API на основе роли ваших клиентов!

По очень простой причине. В конечном итоге вы столкнетесь с дублированием кода, несоответствием и многими другими проблемами.

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

Например:

• MyProject.ProductsApi
• MyProject.OrderingApi
• MyProject.PaymentApi
• et c.

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

Однако в некоторых случаях вы хотите развернуть один и тот же API (один и тот же лог c и код) в нескольких местах. Например, если у вас есть ограничения на ресурсы, предоставляемые для обслуживания вашего API, и в пиковое время ваши клиенты будут вызывать медленный или недоступный API, вы можете не захотеть, чтобы ваш бэк-офис страдал от той же проблемы, и они всегда должны оставаться работоспособными. от того, что. Для этого вы делаете облачное развертывание и одно локальное развертывание.

Есть и другие факторы, такие как измерения безопасности, ограничение скорости, атаки, мониторинг и т. Д. c. которые должны управляться другими инструментами, а не путем разделения / дублирования кода API.