Pracujemy nad interfejsem API REST, który między innymi będzie używany przez interfejs HTML5 za pomocą javascript. Aplikacja jest przeznaczona do użytku w organizacji i zwykle ma około 300 użytkowników, ale chcemy dobrze skalować do około 1000 użytkowników.
Zwykle połączenia z interfejsem API będą wykonywane w sieci LAN, więc jakość i opóźnienie połączenia będą dobre, chociaż nie jest wykluczone sporadyczne korzystanie z Internetu, gdzie połączenia mogą być wolniejsze i z większym opóźnieniem przez 3G / 4G.
Dwie opcje, które pomyśleliśmy to:
Interfejs wykona kilka jednoczesnych asynchronicznych wywołań interfejsu API, aby załadować różne komponenty interfejsu.
- Plusy: Prostota.
- Minusy: więcej połączeń z serwerem.
Kontroler interfejsu wykona pojedyncze wywołanie interfejsu API, przekazując parametry, które obiekty należy pobrać.
- Plusy: tylko jedno połączenie z serwerem, chociaż serwer nawiąże kilka połączeń z bazą danych.
- Minusy: Wymaga mechanizmów zarówno w interfejsie użytkownika, jak i interfejsie API. To komplikuje projekt.
Dalsze objaśnienia: Będą różne zasoby ... / Produkt ... / Lokalizacje itp. Te zasoby można pobrać osobno, ale będą też inne zasoby abstrakcyjne ... / screen? Produkt i lokalizacje, które pobiorą oba w jednym połączeniu.
/screen?Product&Locations
jest złe , przynajmniej z całym moim doświadczeniem w tworzeniu interfejsów API REST i aplikacji internetowej, która ich używała. Z czysto monolitycznego punktu widzenia (np. W Ruby on Rails) posiadanie drogi do/screen
tego, która ładuje oba zasobyProduct
iLocation
zasoby, jest całkowicie w porządku. Jednak z perspektywy REST nigdy nie będziesz chciał, aby trasa ładowała więcej niż jedną (chyba że jesteś JOINING tabelami, aby uzyskać więcej danych naraz). Co/screen
należy zrobić, to załadować podstawowy układ strony i Ajax swoje API, aby uzyskać dane (Product
,Location
itp)./screen
AJAXHTTP GET
do/products/popular
i/locations
). Twój interfejs API nie powinien być tym, który wykonuje wiele ładowań, ponieważ jest mało prawdopodobne, aby dane były wyświetlane w ten sam sposób w aplikacji internetowej na przykład na Androidzie.