Stateful und stateless WebServices

Hallo,

ich arbeite mich grad in WebServices ein - wo es ja zwei unterschiedliche Vorgehensweisen gibt: Stagteful (REST) bzw stateless (z.B. Roman Model) Services.
Vorteile von REST liegen auf der Hand (einheitliche Schnittstelle, einfach zu benutzen etc.) - doch was geht damit nicht - bzw: was geht mit stateful services besser/schneller als mit stateless Services?

Es wäre schön, wenn mir jemand vielleicht ein paar einfache Beispiele/Anwendungsgebiete zeigen kann, wo stateful services im Vorteil sind (bzw wo es ungünstig ist, stateless services einzusetzten). Habe leider nicht viel sinnvolles dazu gefunden.

Schönen Abend noch,

ItsJustMe

Headhunter

Hallo,
informiere dich nochmal über REST, das ist 100% statilos. Es dient hauptsächlich zum Austausch von Daten vom Server zum Client, ein schönes Beispiel ist die Twitter API, die man auch über den Browser aufrufen kann.

Der Größte Vorteil von stateles Webservicen ist, dass sie einfacher zu entwickeln sind als ein stateful Webservice und dass man Sie (theoretisch) unbegrenzt horizontal skalieren kann.

Hi, das habe ich auch gefunden. Allerdings geht es mir um das Umgekehrte: wo liegen die Grenzen von REST, also wo haben zustandsorientierte WebServies Vorteile gegenüber zustandslosen?
Mehr als ein abstraktes "manchmal schneller" (ohne weitere Erklärung) konnte ich leider nicht finden. Da es aber viele Veröffentlichungen auch zu zustandsorietnierten Servies gibt (z.B. über das Roman Model), scheint ja eine gewisse daseins-Berechtigung zu existieren.
Weiß wer einige Vorteile?

Headhunter

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