Projekt interfejsu API REST: wiele wywołań vs. pojedyncze wywołanie interfejsu API

Opracowujemy interfejs Rest API dla witryny eCommerce, który będzie wykorzystywany przez aplikacje mobilne.

Na stronie głównej aplikacji musimy wywoływać wiele zasobów, takich jak suwaki, najlepsze marki, najlepiej sprzedające się produkty, popularne produkty itp.

Dwie opcje wykonywania połączeń API:

Pojedyncze połączenie:

www.example.com/api/GetAllInHome

Wiele połączeń:

www.example.com/api/GetSliders

www.example.com/api/GetTopBrands

www.example.com/api/GetBestSellingProducts

www.example.com/api/GetTrendingProducts

Jakie jest najlepsze podejście do projektowania interfejsu API spoczynkowego - pojedyncze lub wielokrotne połączenie, wyjaśnienie zalet i wad?

Które zajmie więcej czasu, aby odpowiedzieć na prośbę?

W teorii wiele jednoczesnych połączeń jest bardziej elastycznych i równie szybkich.

Jednak w praktyce, jeśli załadujesz stronę, a następnie załadujesz każdą część tej strony, wyświetlając ładowanie spinnerów aż do odzyskania wyników, wynik będzie powolny i rozłączny.

Z tego powodu żądania AJAX dotyczące danych powinny być wykorzystywane oszczędnie i tylko wtedy, gdy masz wolną sekcję strony lub która wymaga odświeżenia w innym cyklu niż reszta strony. Powiedz ekran główny / szczegółowy, w którym chcesz wybrać opcję z głównego i wyświetl odpowiedni szczegół bez ponownego ładowania głównego.

Powszechnym rozwiązaniem jest zachowanie oddzielnych interfejsów API dla zapewnienia elastyczności kodowania i problemów związanych z mikrousługami, ale połączenie strony serwera danych w witrynie. aby klient musiał wykonać tylko jedno połączenie z własną witryną. Wywołania API z odpowiednim buforowaniem powinny być szybkie w centrum danych.

Należy również rozważyć, czy w ogóle NIE ma wywołań interfejsu API klienta. po prostu wygeneruj stronę serwera HTML. Mimo że jednostronne ramy aplikacji javascript popychają Cię w dół interfejsu API. Zazwyczaj nie jest to optymalne podejście do witryn o dużym natężeniu handlu elektronicznego.

TL; DR: Pomijając wszystkie inne kwestie związane z aplikacjami, wykonanie jednego połączenia byłoby szybsze niż wykonanie wielu połączeń. Asynchroniczne uruchamianie połączeń może skrócić całkowity czas potrzebny na wykonanie danej operacji z perspektywy użytkownika (co może być wszystkim, czego potrzebujesz), ale w sumie czas potrzebny na wielokrotne połączenia byłby dłuższy.

W twoim przypadku nie jestem jednak pewien, czy to cała historia.

Interfejsy API REST są terminem nieco dwuznacznym, ze względu na różne interpretacje artykułu, dzięki którym pomysł stał się popularny. Jednak nawet najbardziej liberalna interpretacja tego, co stanowi interfejs API REST, tak naprawdę nie pasuje.

Podstawową zasadą jest to, że masz zasób, na którym chcesz wykonać akcję. Identyfikator URI identyfikuje zasób, który Cię interesuje, i zwykle używasz czasowników HTTP, aby wskazać, co chcesz zrobić z tym zasobem.

W konkretnym przypadku wszystkie metody mają w nazwie słowo „get”. Powinieneś zmienić czasownik użyty w żądaniu HTTP, aby wskazać, że chcesz „uzyskać” zasób dostępny w tej lokalizacji.

Twój schemat URI powinien reprezentować logiczną hierarchię zasobów, które chcesz udostępnić użytkownikom interfejsu API, więc w twoim przypadku rozważę użycie czegoś takiego jak /api/products?category=slidersodfiltrowanie Twojej kolekcji produktów. Oznacza to, że gdy klienci chcą uzyskać wszystkie Twoje produkty, mogą po prostu pominąć ciąg zapytania.