Restservice(s) Best Practice

Java-Forum Jakarta EE (Java EE)
1

Hallo Community,

ich brauche eure Erfahrung in Bereich Restservice und mobile Apps. Ihr kennt doch diese Auswahlfelder, wo zuerst das erste Dropdown Feld gefüllt ist und wenn dort was ausgewählt wird, wird das nächste gefüllt. Ich habe 4 von solchen Dropdownfeldern (Kontinent => Land => Ort => Lagerplatz). Diese Informationen sind nicht fix und müssen dynamisch über Restservices geladen werden.

Nun ist die Frage, ob ich alle Daten beim ersten mal lade, oder 4 Requests durchführe. Bei einem großen Request können im schlimmsten Falle 50-100Kb geladen werden. Bei 4 kleinen Request sind es vielleicht 4x2Kb. Rein von der Datenmenge wäre die Entscheidung klar. Aber was ist, wenn das Smartphone eine schlechte Internetverbindung hat. Können die kleinen Request zwischen den Auswahlfeldern dann so langsam werden, dass die Userexperience deutlich gestört ist? Was sind da eure Erfahrungen bei Restservices und langsamen Internetverbindungen?

2

Es kommt darauf an.

Der Vorteil bei einem grossen Request ist, wenn ich den Fall korrekt sehe, dass dieser nur ein einziges Mal gemacht werden muss.
D.h. der Client könnte unter Umständen auch das Ergebnis cachen, wenn der Request immer das gleiche zurück gibt.
Ist ja meist so, dass man nicht nur einmal etwas einlagert, sondern evtl. mehrere Sachen hintereinander.

Hier kann man z.B. mit den E-Tags arbeiten.

Die Anfrage an den Server, wäre also einmalig alle Daten holen und dann nur noch die Abfrage, ob sich das Ergebnis geändert hat, also ein weiterer Lagerplatz hinzugekommen ist.
Bleibt alles gleich, dann kommen da auch kaum zusätzliche Daten zusammen. HTTP Status 304

Ändert sich hier regelmässig etwas, oder ist die Antwort Kontextabhängig, dann kommen damit schon mehr Daten zusammen.

Ein weiteres entscheidendes Kriterium ist die Zeit, die ein Request benötigt um überhaupt, den Weg zum Server zu finden und die Antwort zum Client zu transportieren. Das kann die UX schon ganz schön stören.

Aber um es ganz genau herauszufinden, wäre wohl ein Experiment das Beste, wohl auch nicht allzu aufwendig . Dann gibt es eine empirische Antwort, die auch auf den Fall passt.

3

allgemein genannt:
Hintergrund-Laden, und bei gleichmäßig mehrstufigen Verzweigungen
10 - 100 - 1000 - 10.000
könnte man etwas überlappend laden, für das Beispiel hier genannt:

am Anfang braucht es ja eh die ersten 10 Einträge, 10 Kontinente (Anzahlen nur Beispiel),
da könnte man dann auch gleich neben den 10 Kontinenten die insgesamt 100 möglichen Länder am Anfang parat haben, Datenmenge hält sich in Grenzen

wird ein Kontinent ausgewählt, dann sind die 10 Länder für die zweite Wahl sofort vorhanden,
intern könnte schon die 100 Orte des Kontinents, der 10 Länder, geladen werden,

ist ein Land ausgewählt dann 10 Orte des Landes sofort verfügbar usw.,

ist nicht so effizient wie jeweils nur die 10 benötigten Elemente zu laden, dafür aber auch nicht unbedingt zu warten,
je nachdem wie schnell der Bediener vs. Nachladen ist,
das Laden von Zehntausenden Daten dennoch vermieden, ein Mittelweg

bei deinem Beispiel dürften Kontinente und Länder problemlos direkt am Anfang als Daten vorhanden sein,
mit Programm geladen oder was immer als Updates geplant,
falls keine Updates und Länder auf Server später hinzukommen, ok, dann vielleicht nicht so leicht machbar…

bei Auswahl eines von nur 6 Kontinenten sämtliche Orte des Kontinents nachzuladen, das erscheint hier nicht ganz verhältnismäßig,
dann lieber doch Land auswählen lassen und an dieser Stelle eine kleine Wartezeit riskieren

wieviele ‘Lagerplätze’ gibt es pro Ort? falls nur einstellige Zahl im Mittel, dann könnten die beim Laden der Orte gleich dazukommen,
oder auch bei vielen Lagerplätzen wenn dazu entschlossen,

so insgesamt nur einmal Nachladen vielleicht akzeptabel

4

Ich argumentiere im Akku-Verbrauch dass die 50-100kb besser sind. Smartphones schalten den Netzbetrieb auf Standby um Akkuleistung zu sparen, viele einzelne Requests halten die Netzverbindung unnötig lange aktiv.

Diese kleinen Antennen im Smartphone müssen das Signal immerhin mehrere Kilometer weit transportieren.

Deshalb lieber einzelne Große statt viele Kleine.

*** Edit ***

Können die Daten nicht auf dem Smartphone gecached werden und stattdessen erstmal auf Gültigkeit validiert werden.

5

Sorry, wenn ich nochmal Frage, aber habe den Satz nicht ganz verstanden, da etwas zweideutig.

• Caching funktioniert nicht unter android
vs
• Versuche es doch mal mit caching

Zumal es noch auf die jeweilige Technologie ankommen kann. Mit einem Standard-Browser stehen andere Möglichkeiten offen, als mit einer App.
Zudem kann man bei einer App auch noch andere libs nutzen, die einem einen teils erweiterten Funktionsumfang bieten oder zumindest einfachere Nutzbarkeit.

[OT]Apropos Akkuverbrauch, habe letztens noch von einer Studie gehört, bei der Collections bezgl. der Energieeffizienz untersucht wurden.[/OT]

6

Sehr interessant, was hier noch für Ideen kommen. Auf das Vorladen von 2 Dropdown Feldern wäre ich nie gekommen :slight_smile:
Auch das mit dem Cache ist noch interessant, sodass man nur fragen muss, ob die Daten noch passen. Die werden sich selten ändern. Den ETag kannte ich noch nicht.

Den Akkuverbrauch hatte ich auch schon im Kopf, aber zuerst UX, dann Akku.

Danke :slight_smile: