Способы предоставления данных фронтенду

По мере разработки бэкенда этого сайта (с использованием django и DRF, но я не думаю, что это имеет значение в данном вопросе), я столкнулся с вопросом об организации конечных точек API, особенно в отношении предоставления данных для фронтенда. Моя цель - обеспечить, чтобы реализация бэкенда соответствовала стандартам и была оптимизирована для производительности.

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

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

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

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

Спасибо за помощь!

При разработке REST API лучше разделять конечные точки по ресурсам, поэтому если у вас на главной странице есть продукты, услуги и отзывы, то лучше иметь 3 отдельные конечные точки по нескольким причинам

  1. Благодаря наличию выделенных конечных точек для каждого ресурса, например для товаров, обновление становится более простым. Вы точно знаете, куда идти, чтобы изменить или получить конкретные данные, без необходимости искать их в нескольких местах. Это снижает риск упустить из виду или сломать связанные функциональные возможности.
  2. Если впоследствии вы захотите добавить конечную точку для отображения сервисов в другом месте, вы либо реализуете дополнительную конечную точку для сервисов, не использующих вашу домашнюю конечную точку, либо снова будете использовать домашнюю страницу для получения всех остальных данных
    3. .
  3. Даже если вы являетесь full-stack разработчиком, работающим как с фронтендом, так и с бэкендом, обеспечение простоты использования и понимания API очень важно. потому что со временем легко забыть детали реализации. Наличие хорошо организованных конечных точек облегчает запоминание и использование API без постоянного поиска URL-адресов бэкенда во время разработки фронтенда. Так, если вам нужны продукты, вы будете знать, что нужно искать /api/products и так далее
    4. .

отметим, что наличие одной конечной точки не увеличит производительность из-за параллелизма, поскольку фронт будет отправлять 3 запроса параллельно, не дожидаясь завершения одного из них перед отправкой другого, поэтому вам не придется ждать возвращения одного из них перед отправкой другого, однако

Но, несмотря на это, это может быть немного лучше с точки зрения производительности, потому что это уменьшит сетевые накладные расходы сервера, так как он получает один запрос вместо трех. Вы можете обойтись одной агрегированной конечной точкой для вашей домашней страницы, если вы уверены, что ничто на домашней странице не используется где-то еще, и домашняя страница не будет изменена позже, чтобы использовать что-то из других конечных точек. И если вы собираетесь реализовать это, то лучше использовать что-то похожее на сервисный слой, где у вас есть метод в файле service.py под названием get_products(), и в представлении продуктов вы просто вызываете этот метод а теперь в представлении home вы просто вызываете эти 3 метода Таким образом, теперь вы повторно используете код & у вас все еще есть 3 основные конечные точки для последующего повторного использования, а ваша главная страница просто вызывает эту одну конечную точку, которая вызывает 3 метода в бэкенде

Вернуться на верх