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?

Pomfret

Pretty close to a dupe: https://mcmap.net/q/672897/-why-is-it-bad-programming-to-use-a-stateful-webservice-and-why-would-it-be-allowed – Kammerer

Put the state into a place that can easily handle state: the database – Brigid

Answer 1

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.

Lodging

Well, it depends on what the platform is. A lot of times the container will take care of sessions for you. – Cassidy

Why not simply use a container that's designed for this purpose such as a RDMS. – Lodging

I'm not sure I understand. If you put stuff into RDMS it basically means rolling your own sessions which will probably perform worse. It doesn't sound like he needs persistent information in the session, so why put it there? – Cassidy

What I meant by putting state in a database was to design web service methods that are capable of retrieving the state from the database. For example prefer a web method User GetUser(int userId) instead of User GetUser() which will look in some custom made state container for the current user id and return its information. It's up to the consumer of the web service to decide how to handle state. – Lodging

Answer 2

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.

Cassidy

Answer 3

State is where most bugs hide, too.

Luettaluevano