What does it imply to call a web service (SOAP over HTTP) stateless?

Question

I had a concept that HTTP is stateless, so SOAP over HTTP (for web services) is also stateless. I used to think that state meant “state of the object”. For an example, suppose I have a class called Employee and methods called setSalary and getSalary. If a caller of the web service calls setSalary and makes the salary 1000, then if getSalary is called, the caller should not necessarily get the value 10000. When I tested getsalary and got 1000 (i.e., the value assigned by setSalary), I was wondering how the state of the Employee object was maintained.

The Stack Overflow question Webservices are stateless? mentions tricks like cookies used to maintain state, but since I did not made any explicit effort to maintain state, how was the state of the Employee object maintained?

Please let me know if I have misunderstood the concept of state/stateless altogether.

Solution 1

Stateless means the state of the service don't persist between subsequent requests and response. whereas, in stateful the state is persisted between subsequent requests i.e. each request need to know and retain changes made in previous requests.

Banking application is an example of stateful application,where user first login then make transaction and logs out. If user tries to make the transaction after logout, he will not be able to do so.

Yes, http protocol is essentially a stateless protocol but to make it stateful we make use of HTTP cookies. So, is SOAP by default. But it can be make stateful likewise, depends upon framework you are using.

The case you provided, Are you trying to set and get values in subsequent requests or in same requests? Then only, i can comment on that.

Solution 2

In a stateless protocol, like HTTP, each request is independent. In each request, the client calls the server, and the server responds. Each request is independent. The client needs to reestablish its relationship with the server on each request. That doesn’t mean that the server forgets about previous requests. If the client requests the salary of an employee, the server will respond with the salary information it has for that employee. That’s what getSalary means. And if the client tells the server what an employee’s salary is, the server will save that salary value for that employee. That’s what setSalary means.

If you do the setSalary before the getSalary, you’ll get back the value you set. What else would you expect to happen? What on earth would be the point of a setSalary method which did not cause the server to actually save the value set, and to return that value on subsequent getSalary requests?

Comments

[Pritesh]

2 webservice call 1. setSalary 2. getSalary one after other.

[shashankaholic]

Can you share the web service class with these methods ?