#javascript #angular #typescript
Вопрос:
Допустим, у меня есть форма, которую я использую для редактирования клиента. В дополнение к различным полям ввода в нем также будет несколько выпадающих списков для установки некоторых полей (например. Страна, категория, статус…). Для каждого выпадающего списка потребуются отдельные списки, которые мне нужно получить из бэкенда для заполнения. Это означает, что если я хочу отредактировать клиента с помощью своей формы, мне нужно загрузить:
- Объект клиента, который будет отредактирован
- Список стран
- Список категорий
- Список различных типов статусов
- …
Мой вопрос: следует ли загружать каждую из этих вещей отдельно с помощью собственного внутреннего вызова API или мне следует написать внутренний вызов API, который объединит все эти вещи в один объект и будет использовать его для загрузки моих данных?
Комментарии:
1. Честно говоря, это зависит от сценария — для выпадающих списков; есть ли другие части системы, которые использовали бы те же данные? Лично я бы разработал API с учетом возможности повторного использования — если конкретная конечная точка обслуживает несколько частей системы, то ее последующее изменение становится проще. Но в то же время, если система не изменится в будущем, загрузка всех данных одним нажатием, как правило, будет лучше для пользователя.
2. Да, API, которые будут загружать списки, должны использоваться повторно во многих местах
3. Я использую Spring Boot в качестве бэкэнда, используя шаблон Контроллера/службы/репозитория. Я предполагаю, что я мог бы создать на своем уровне контроллера конечную точку, которая будет создавать всеобъемлющий объект данных и в то же время иметь конечные точки для отдельных объектов данных, и все они будут использовать один и тот же метод обслуживания
Ответ №1:
Я думаю, что в этой ситуации лучше использовать несколько вызовов API. После сравнения плюсов и минусов, как показано в таблице ниже, я всегда выбираю несколько вызовов API для проектов.
Заслуга Эндрю Корригана и Амрита напоминает мне о некоторых критериях.
| Единый API | Несколько API | |
|---|---|---|
| Сеть | Меньше запросов | Множественный запрос => Кэширование |
| Визуализация пользовательского интерфейса | Визуализация данных почти за одно и то же время | Визуализируйте, если есть какой-либо ответ api |
| Повторно используйте компонент FE | Нужно вызвать большой API, чтобы взять один массив данных | Получите то, что нужно |
| API для повторного использования | Низкий | Высокий |
| Единая Ответственность | НЕТ | ДА |
| Гибкий | НЕТ | ДА |
Комментарии:
1. Хороший момент, но для «Повторного использования компонента FE» я хочу сказать, что если я контролирую серверную часть, я могу просто настроить разные конечные точки API для разных вариантов использования. Это означает, что я могу сделать 1 конечную точку, которая загружает только объект клиента, и другую, которая загружает объект клиента вместе со списком задач для этого клиента. Но это потенциально означало бы огромное количество конечных точек. Не уверен, что это хорошая идея.
2. Теперь ваша проблема заключается в архитекторе приложения. Я не предлагаю эту реализацию, потому что приложение быстро усложняется. Так что теперь вы должны заботиться об ответственности каждого варианта использования и гибкости вашего приложения.
Ответ №2:
Это основано на мнении и сценарии , но, по моему предложению, я бы предпочел, чтобы вещи загружались отдельно с помощью собственного внутреннего API, потому что :
1.Single api will be heavy and UX will be badly impacted
2.User may not change all field when form opens so only changing fields will be using api