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

19

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ę?

Shaijut
źródło

Odpowiedzi:

15

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.

wprowadź opis zdjęcia tutaj

Ewan
źródło
Dzięki, w rzeczywistości Ten interfejs jest używany w aplikacjach na Androida i na telefony, chcę wiedzieć, kiedy strona główna aplikacji jest ładowana, czy powinienem uzyskać wszystkie zasoby, takie jak: suwaki, marki, produkty w jednym wywołaniu interfejsu API lub osobne połączenie z interfejsem API dla pojedynczego zasobu, gdy użytkownicy przewijają w dół?
shaijut
Obowiązuje ta sama logika, minimalizuj jednoczesne połączenia tam, gdzie nie jest to wymagane. Aplikacja zapewnia jednak nieco większą elastyczność pobierania informacji w tle. Możesz przejść na metodę GetChangesSInce (data)
Ewan,
Podsumowując, najlepiej jest mieć pojedynczy interfejs API, aby wywoływać natychmiastową odpowiedź wszystkich zasobów strony głównej, gdy strona główna aplikacji się ładuje, i różne interfejsy API dla suwaków, marek itp. Osobno dla mikro-usług, gdy masz część strony do zaktualizowania ?
shaijut
nie, chyba że masz dobry powód, dla którego te sekcje nie są tylko ładowane stroną / głównymi danymi
Ewan
Mam ostatnie pytanie, jak działałyby aplikacje takie jak Amazon, Flipkart? Czy nie ładują wszystkich zasobów strony głównej podczas jednego połączenia, gdy użytkownik otwiera aplikację? Chcę wiedzieć, jakie byłoby najlepsze podejście w tej sprawie.
shaijut
5

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.

Richzilla
źródło
Dzięki, więc masz na myśli single urldla API, ale prośba o inne zasoby powinna być złożona za pomocą ciągu zapytania? , również to sprawdź .
shaijut
Tak, asynchroniczne uruchamianie połączeń skróciłoby bezwzględny czas potrzebny na pobranie danych, ale w sumie czas ten będzie jeszcze dłuższy; Więcej połączeń musi powtarzać narzut połączenia TCP i komunikację w obie strony. Nawet korzystanie z takich funkcji, jak to, keep-alivenie spowoduje całkowitego usunięcia tego.
richzilla,
Kategoria byłaby własnością pojedynczego zasobu produktu. Logicznie pobierałbyś kolekcję produktów i filtrowałbyś wszystkie z określonej kategorii
richzilla,
więc masz na myśli, że gdy użytkownik otworzy stronę główną aplikacji, jedno połączenie powinno przejść do interfejsu API, który zwraca wszystkie wyżej wymienione zasoby? lub kiedy przewija wykonane, poszczególne połączenia powinny być wykonywane dla określonych zasobów, co jest najlepszą praktyką?
shaijut
Zależy to od tego, czego oczekuje użytkownik w każdym punkcie aplikacji. Weźmy tę stronę internetową, na przykład, kiedy klikniesz questions, zobaczysz URI /questions, kiedy klikniesz jeden z twoich ulubionych tagów, URI jest/questions/tagged/<tagname>
richzilla