REST API Design: Кілька викликів проти одного виклику в API

Ми розробляємо 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 відпочинку - один або багаторазовий дзвінок, поясніть плюси та мінуси?

На що знадобиться більше часу, щоб відповісти на запит?

У Теорії кілька одночасних дзвінків є більш гнучкими і настільки ж швидкими.

Однак на практиці, якщо ви завантажуєте сторінку, а потім завантажуєте кожну її частину, демонструючи завантаження спінерів по всьому, поки результати не повернуться, результат буде повільним і непересічним.

З цієї причини запити AJAX щодо даних слід застосовувати ощадливо і лише тоді, коли у вас є розділ сторінки, який повільно завантажується або його потрібно оновити в іншому циклі до решти сторінки. Скажіть головний / детальний дисплей, де ви хочете вибрати параметр із головного та відображати відповідну деталь, не перезавантажуючи головну.

Загальна конструкція полягає в тому, щоб зберігати окремі API для гнучкості кодування та проблем мікро-сервісу, але поєднувати сторону сервера даних на веб-сайті. так що клієнту потрібно здійснити лише один дзвінок на власний веб-сайт. Дзвінки API з відповідним кешуванням повинні бути швидкими в центрі обробки даних.

Також врахуйте, що взагалі немає викликів API клієнта. просто генеруйте сторону HTML-сервера. Хоча рамки додатків на одній сторінці javascript виштовхують вас по маршруту api. Зазвичай це не оптимальний підхід для сайтів електронної комерції з великим обсягом.

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

У вашому випадку, проте, я не впевнений, що це повна історія.

API REST - дещо неоднозначний термін, обумовлений різними інтерпретаціями статті, яка зробила ідею популярною. Навіть з найбільш ліберальної інтерпретації того, що є API REST, однак те, що у вас є, насправді не підходить.

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

У вашому конкретному випадку у всіх ваших методах у назві є слово "отримати". Вам слід змінити дієслово, яке використовується у запиті HTTP, щоб вказати, що ви хочете "отримати" доступний ресурс у цьому місці.

Ваша схема URI повинна представляти логічну ієрархію ресурсів, які ви хочете зробити доступними для користувачів вашого API, тож у вашому випадку я б розглядав можливість використовувати щось на кшталт /api/products?category=slidersфільтрації вашої колекції продуктів. Це означає, що коли клієнти хочуть отримати всі ваші продукти, вони можуть просто опустити рядок запиту.