Imagine a more complex CRUD application which has a three-tier-architecture and communicates over webservices. The client starts a conversation to the server and doing some wizard like stuff. To process the wizard the client needs feedback given by the server.
We started a discussion about stateful or stateless webservices for this approach. I made some research combined with my own experience, which points me to the question mentioned later.
Stateless webservices having the following properties (in our case):
+ high scalability
+ high availability
+ high speed
+ rapid testing
- bloated contract
- implementing more logic on server-side
But we can cross out the first two points, our application doesn’t needs high scalability and availability.
So we come to the stateful webservice. I’ve read a bunch of blogs and forum posts and the most invented point implementing a stateful webservice was:
+ simplifies contract (protocol)
- bad testing
- runs counter to the basic architecture of http
But doesn’t almost all web applications have these bad points? Web applications uses cookies, query strings, session ids, and all the stuff to avoid the statelessness of http.
So why is it that bad for webservices?
Because keeping state in a webservice is difficult and if you aren’t extremely careful and/or experienced sooner or later you might hit some very difficult to find bugs.