img - GitHub Pages

4.3. RP2 Application Logic 60
Diskussion
REST ist ein immer wichtigerer Architekturstil und wird in dieser Form überall eingesetzt
(siehe Twitter [Twib], Stripe [Str], etc.). Es definiert die wichtigsten Grundbedürfnisse
und überlässt applikationsspezifische Entscheidungen dem Software Entwickler.
Seit einiger Zeit ist es immer wichtiger eine generische Schnittstelle auch für kleinere
Applikationen zu erstellen. Vielfach wird seit dem aufkommen von Smartphones nicht
nur eine Webseite erstellt, sondern auch entsprechende Apps.
Dadurch dass REST keine Serialisierungsform festlegt, ist es dem Entwickler der
API möglich, verschiedene Datenformate zu unterstützen (siehe auch 4.7 “RP6 Should-
Formats”). Dies ermöglicht beispielsweise die Nutzung eines kompakten Datenformats,
damit insgesamt weniger grosse Daten übertragen werden müssen.
Durch die relativ flexible REST-Definition mit einigen wenigen Randbedingungen tut
sich aber auch ein wichtiger Diskussionspunkt auf: Mit welchem HTTP-Verb (POST
oder PUT) werden Updates gehandhabt Es gibt hier verschiedene Ansichten und die
Diskussion ist bei Weitem nicht abgeschlossen. Eine gute Hilfestellung hierfür bietet
“Stack Overflow - HTTP PUT vs POST in REST” [Comc].
Abschliessend gibt das Projektteam folgenden Rat: Ist eine flexible und generische API
nötig, ist REST eine sehr gute Lösung. Es erlaubt Entwicklern bestehendes Know-How
über die Web-Entwicklung wiederzuverwenden. Zudem wird die API durch die Zustandslosigkeit
skalierbar.
4.3. RP2 Application Logic
Die Logik einer Applikation kann in zwei Kategorien unterteilt werden:
1. Businesslogik
2. Präsentationslogik
Businesslogik
Die Businesslogik beinhaltet das eigentliche Herz der Applikation. Sie legt fest, welche
Zustandsübergänge für Ressourcen möglich sind, welche Daten erlaubt sind und was bei
API-Aufrufen ausgeführt wird.
Zur Businesslogik gehört laut den “ROCA”-Autoren auch die logikbasierte Validierung.
Diese beinhaltet [HST] Funktionalität zur Überprüfung der Korrektheit der übertragenen
Daten im Sinne der Businesslogik.
Präsentationslogik
Bei jeder Aktion eines Benutzers müssen zwei Aktionen durchgeführt werden:
• API-Aufrufe (lokal und remote)
• Darstellung der nächsten Ansicht