-
Notifications
You must be signed in to change notification settings - Fork 0
REST
Um die geäußerten Wishes zu matchen, also die Gruppen zu identifizieren die von der selben Location gekauft werden können, muss Anwendungslogik auf dem Dienstgeber ausgelöst werden. Die Frage war nun, zu welchem Zeitpunkt man diese Logik ausführen sollte.
Ein naheliegender Ansatz war es, das Matching der Wishes mit jedem Abruf der Shoppingliste auszuführen. Also jedes mal wenn ein User seine Shoppingliste abfragen will, würde der Dienstgeber im Hintergrund alle Wishes matchen und das errechnete Ergebnis ausgeben. Bei diesem Ansatz gibt es allerdings ein großes Problem. Die “Sicherheit” der HTTP Verben GET wäre nicht länger geben, da nach dem GET eine Änderung auf dem Server stattfindet für die der Client verantwortlich ist. Die Collection “Shoppinglist” hätte nach dem Aufruf von GET andere Sub-Ressourcen als vor dem GET. Dies verstößt gegen die Definition von GET und ist somit nicht REST-Konform.
Ein anderer Ansatz ist es, POST zu verwenden um die Shoppinglist Ressource zu erstellen. Bei dieser Variante müsste ein User, um seine Shoppingliste zu bekommen, einen POST auf die Ressource ausführen und könnte sie dann danach über ein GET abrufen. Diese Variante hat zwei große Nachteile. Zum Einen ist sie weniger intuitiv als der GET-Ansatz: Ein Abruf der Shoppingliste erfordert nun zwei Funktionsaufrufe und nicht nur einen. Zum Anderen kann es bei dieser Variante zu Inkonsistenzen kommen. Wenn z.B. ein User einen Wish nach dem POST auf die Shoppinglist Ressource hinzufügt, wäre dieser Wish nicht in der Shoppinglist und die Daten auf dem Server wären inkonsistent. Der große Vorteil dieser Variante ist aber, dass dank der losen HTTP POST Definition gegen keine Regeln von REST verstoßen wird.
POST is designed to allow a uniform method to cover the following functions: (..) -Extending a database through an append operation.
Die “Sicherheit” von GET bleibt auch weiterhin bestehen, da nun die Datenbank beim POST verändert wird und GET lediglich zum Abruf verwendet wird.
Wir haben uns final dafür entschieden, die POST Variante zu verwenden, da uns bei diesem Projekt REST-Konformität wichtiger als Intuition war.
Zudem konnten wir das Problem der Inkonsistenz dieser Variante umgehen, indem wir den POST auf die Wishes des Events nach dem Erstellen der Shoppingliste blockieren. Wenn es bereits eine Shoppinglist gibt und ein User versucht nachträglich einen Wish hinzuzufügen, bekommt er/sie die Fehlermeldung: "423 LOCKED: Shopping List already generated".