REST API Design: несколько вызовов против одного вызова API

Мы разрабатываем Rest API для веб-сайта электронной коммерции, который будет использоваться мобильными приложениями.

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

Два варианта выполнения вызовов API:

Одиночный звонок:

www.example.com/api/GetAllInHome

Несколько звонков:

www.example.com/api/GetSliders

www.example.com/api/GetTopBrands

www.example.com/api/GetBestSellingProducts

www.example.com/api/GetTrendingProducts

Какой подход лучше всего подходит для остальных API? Один или несколько вызовов, объясните плюсы и минусы?

Что займет больше времени, чтобы ответить на запрос?

— shaijut
источник

Ответы:

В теории множественные одновременные вызовы являются более гибкими и такими же быстрыми.

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

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

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

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

— Ewan
источник

Спасибо, на самом деле этот API используется в приложениях Android и I Phone, я хочу знать, когда загружается домашняя страница приложения, если я получу все ресурсы, такие как: ползунки, бренды, продукты в одном вызове API или сделать отдельный вызов API для отдельного ресурса, когда пользователи прокручивают вниз?

— Shaijut

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

— Ewan

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

— Shaijut

нет, если у вас нет веской причины, по которой эти разделы не просто загружаются страницей / основными данными

— Ewan

У меня последний вопрос, как бы работали такие приложения, как amazon, flipkart? Не загружают ли они все ресурсы домашней страницы за один раз, когда пользователь открывает приложение? Я хочу знать, что будет лучшим подходом к этому.

— Shaijut

TL; DR: если не учитывать все другие аспекты применения, выполнение одного вызова будет быстрее, чем выполнение нескольких вызовов. Выполнение вызовов асинхронно может сократить общее время, необходимое для выполнения данной операции с точки зрения вашего пользователя (что вполне может быть всем, что вам нужно), но в совокупности время, затрачиваемое на множественные вызовы, все равно будет больше.

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

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

Основной принцип заключается в том, что у вас есть ресурс, на котором вы хотите выполнить действие. URI идентифицирует интересующий вас ресурс, и вы обычно используете HTTP-глаголы, чтобы указать, что вы хотите сделать с этим ресурсом.

В вашем конкретном случае все ваши методы имеют слово «get» в своем имени. Вы должны изменить глагол, используемый в HTTP-запросе, чтобы указать, что вы хотите «получить» ресурс, доступный в этом месте.

Ваша схема URI должна представлять логическую иерархию ресурсов, которые вы хотите сделать доступными для пользователей вашего API, поэтому в вашем случае я бы хотел использовать что-то вроде /api/products?category=slidersфильтрации вашей коллекции продуктов. Это означает, что когда клиенты хотят получить все ваши продукты, они могут просто пропустить строку запроса.

— richzilla
источник

Спасибо, значит вы имеете в виду single urlfor API, но следует ли запрашивать разные ресурсы с помощью Query String? Также проверьте это .

— Shaijut

Да, выполнение ваших вызовов асинхронно уменьшит абсолютное время, необходимое для извлечения данных, но в совокупности время будет еще больше; Дополнительные вызовы должны повторять издержки соединения TCP и двусторонней связи. Даже используя такие функции, как, не keep-aliveсобираюсь полностью удалить это.

— Ричзилла

Категория будет свойством отдельного ресурса продукта. По логике вещей вы должны были бы получить коллекцию товаров и отфильтровать все товары в указанной категории

— richzilla,

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

— Shaijut

Это зависит от того, что ваш пользователь ожидает увидеть в каждой точке вашего приложения. Возьмем, к примеру, этот веб-сайт. Когда вы нажимаете на него, questionsвы видите URI /questions, когда вы нажимаете на один из ваших любимых тегов, URI/questions/tagged/<tagname>

— richzilla,