Stateful vs. Stateless Webservices

Question

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?

Answer 1

I've had reasonable luck with stateful web services. They do feel slightly dirty because the hole cookie session thing on top of HTTP is that; but on the other hand they were SOAP, so it would be kind of stupid to get too upset about beauty at that point.

One thing to keep in mind is interoperability: if you are doing stateful web service your clients will have to support the same idea of state you do (usually cookies). But again -- worked fine for me.

P.S. I assume you are in a container that will take care of keeping track of the sessions for you.