Any preservation of state with a SOAP API or a RESTful architecture is up to you the programmer.
why is it said that difference between SOAP and REST is that SOAP is stateful whereas REST is stateless.
Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer
A practical example.
Suppose we have a cluster of 12 identical J2EE webapp servers. Each one has the same application installed on it. We expect thousands of hits per hour.
If the webapp was stateful, once a client had logged into one of those servers, the session state (HttpSession) would (usually) reside in RAM within that server. If a later request came in and that server was loaded down but other servers were idle, they could not be employed to handle the request. Or at a minimum, could not be employed unless the cluster was set up to serialize sessions and ship them between servers, which is extra overhead. There would be an asymmetry between the server currently holding the user's state and the other webapp servers.
A stateless webapp, on the other hand, wouldn't establish an HttpSession. Any ongoing state would be an artefact of (presumably distributed) backend processes. So you could send out requests to any server in the cluster that happened to be free at the moment. They would all be symmetrical in their response.
Any preservation of state with a SOAP API or a RESTful architecture is up to you the programmer.
Monica Shiralkar wrote:REST - Can be made stateful if we want to.
Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer
SOAP is state-neutral.
You can build webapps using SOAP that are stateful and you can build webapps using SOAP that are stateless.
SOAP is not defined by its statelessness or statefullness
REST, however, has statelessness as part of its definition
Monica Shiralkar wrote:But why so when statefulness is also possible using it.
chocolate shake without chocolate can't be called a chocolate shake
Tim already explained that in detail. Please read the responses.
Why SOAP not meant to be scalable. As we see scaling is such a useful then why should SOAP web service be devoid of the benefits of scaling?
Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer
William Brogden wrote:Note that SOAP has a whole lot of capabilities such as encryption and authentication which make it useful for high value secure communications.
If AJAX, JSON and YAML have tackled encryption and authentication I would love to hear about it.
Here is the wikipedia SOAP entry.
Bill
Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer
All messaging APIs are intended to tackle the problem of scaling up.
Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer
ReST cannot be stateful because the very definition of ReST is not being stateful:
But the server itself holds no state.
Monica Shiralkar wrote:It is required to be stateful.
It is required to be stateful.
Now for the above requirement which type of web services should be built? SOAP or REST (stateless protocol)?
Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer
I hadn't been here for fifteen years
It is required to be stateful.
Now for the above requirement which type of web services should be built? SOAP or REST (stateless protocol)?
Sit down and meditate on the following 2 statements you made:
Think about what you said carefully.
Monica Shiralkar wrote:I
I have one more doubt. Why are SOAP based web services not as good to scale as RESTful web services. Any reason for that?
I hadn't been here for fifteen years
Monica Shiralkar wrote:It should be a SOAP based web services because it is required to be stateful and RESTful cannot be stateful.
Paul Clapham wrote:
Monica Shiralkar wrote:It should be a SOAP based web services because it is required to be stateful and RESTful cannot be stateful.
You seem to be assuming that SOAP and REST are the only two possibilities which exist. That is far from being the case, isn't it?
I hadn't been here for fifteen years