H
Man sollte Webservices immer statuslos bauen, außer es geht nicht anders.
Wenn es nur darum geht Daten zu holen und evtl. anzuzeigen ist ein RESTful Model recht nett: Einfach zu implementieren, einfach aufzurufen. Die Server sind auch fast beliebig austauschbar- der Client kann seine Aufrufe an Server A, B oder C stellen, je nach Last. Bei statusbehafteten Servern geht das nicht, wurde eine Session einmal bei Server A geöffnet wissen B und C nichts davon - ist Server A down, ist auch der Status verloren.
Wo liegen die Grenzen von REST? Es ist sehr (zu?) simpel. Authentications lassen sich nicht 100% sauber damit abbilden (weil bei einem Loginsystem eigentlich der Status "ist eingeloggt" auf dem Server benötigt wird, aber auf dem Server gibt es keinen Status). Weiterhin ist REST konzeptionell sehr begrenzt.. DELETE, POST, PUT und GET sind ja schön für CRUD - aber wie soll man beispielsweise eine Suche sauber abbilden?
Zustandsorientierte Webservices haben Ihre Berechtigung. Das Paradebeispiel ist der Checkout-Prozess bei einem Onlineshop: 1) Waren aussuchen und in Warenkorb legen, 2) Bezahlung auswählen & Bestelldaten eingeben, 3) evtl. Lieferadresse und Kreditkartendaten eingeben ... So ein Prozess wird idR. mit Zuständen gelöst , weil es wesentlich einfacher und natürlicher zu implementieren ist als ein zustandsloser Webservice (obwohl das auch geht).
Zusammengefasst würde ich sagen:
Pro zustandsloser Webservice:
- Einfach zu implementieren (Client&Server)
- Skalierbar & Redundantes Setup möglich
- Geringer Overhead
Contra:
- Zustandsübergänge sind schwer abzubilden
- Geschäftslogik per REST zu exportieren ist oft notwendig aber konzeptionell unschön
- Authentifizierung nur durch Extraservice möglich
Pro zustandsbehafteter Webservice:
- So kennt man es (normale Webseite mit Session entspricht zustandsbehaftetem Webservice)
- Einfach komplette Geschäftslogik zu exportieren
- Modellierung mit Spring Flow möglich (Java)
Contra:
- Status auf Server immer ein Problem - komplex
- Anbindung von Fremdsystemen erfordert Kenntnis der Geschäftslogik
- Skaliert nicht so gut