Stellen Sie sich eine komplexere CRUD-Anwendung vor, die eine dreistufige Architektur aufweist und über Webservices kommuniziert. Der Client startet eine Konversation mit dem Server und führt einige Assistenten aus. Um den Assistenten ausführen zu können, benötigt der Client eine Rückmeldung vom Server.

Wir haben eine Diskussion über zustandsbehaftete oder zustandslose Webservices für diesen Ansatz gestartet. Ich habe einige Recherchen durchgeführt, die mit meinen eigenen Erfahrungen kombiniert wurden, was mich auf die später angesprochene Frage hinweist.

Stateless Webservices mit den folgenden Eigenschaften (in unserem Fall):

+ high scalability
+ high availability
+ high speed
+ rapid testing
- bloated contract
- implementing more logic on server-side

Aber wir können die ersten beiden Punkte streichen, unsere Anwendung benötigt keine hohe Skalierbarkeit und Verfügbarkeit.

So kommen wir zum stateful Webservice. Ich habe eine Reihe von Blogs und Forenbeiträgen gelesen und der erfinderischste Punkt bei der Implementierung eines Stateful Webservice war:

+ simplifies contract (protocol)
- bad testing
- runs counter to the basic architecture of http 

Aber haben nicht fast alle Webanwendungen diese Nachteile? Webanwendungen verwenden Cookies, Abfragezeichenfolgen, Sitzungs-IDs und alles andere, um die Zustandslosigkeit von http zu vermeiden.

So warum ist es so schlimm für Webservices?