What does it mean when it is said that RESTful web service are stateless?

[Monica Shiralkar]

I have read that SOAP web service are stateful while RESTful web services are stateless.What does it mean when we say that RESTful web services are stateless. Suppose it is said that an object is stateful then it means it has members e.g Employee class has member employeeId. But in case of web service what does it mean that web services are stateful or statless and what is not possible in RESTful web services in this regards.

thanks

[William Brogden]

Any preservation of state with a SOAP API or a RESTful architecture is up to you the programmer.

Bill

[Monica Shiralkar]

Any preservation of state with a SOAP API or a RESTful architecture is up to you the programmer.

Yes. This is the reason this doubt came up. If any preservation of state with a SOAP API or a RESTful architecture is up to the programmer, then it means that both SOAP and REST can be madeful to be stateful if required.In that case why is it said that difference between SOAP and REST is that SOAP is stateful whereas REST is stateless.

thanks

[William Brogden]

why is it said that difference between SOAP and REST is that SOAP is stateful whereas REST is stateless.

Possible reasons:

1. that source is ignorant or confused
2. that source is trying to push some toolkit or similar product
3. that source is not good at articulating a design/architecture problem

Remember the real difference:
SOAP is a messaging API with a huge background of standardization effort - WS-* security etc etc
while REST is an architecture - basically a philosophy about how to use HTTP methods to accomplish management
of resources exposed on the web.

Bill

[Tim Holloway]

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.

[Santhosh Muralidharan]

Basically REST is stateless means every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all information necessary for the server to fulfill that request. The server never relies on information from previous requests. If that information was important, the client would have sent it again in this request.
Statelessness is easier to distribute across load-balanced servers. Since no two requests depend on each other, they can be handled by two different servers that never coordinate

[Monica Shiralkar]

thanks everyone.

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.

Is this not possible with REST? As William said

Any preservation of state with a SOAP API or a RESTful architecture is up to you the programmer.

REST - Can be made stateful if we want to.
SOAP- Can be made stateful.


There are a lot of differences between REST and SOAP but is there any difference with regards to statefulness and statelessness. Dont say that REST is stateless and SOAP is stateful as REST too can be made stateful as mentioned by William.

[Bear Bibeault]

Monica Shiralkar wrote:REST - Can be made stateful if we want to.

If you do, then it isn't REST anymore, so, no.

It's like saying "This is a chocolate shake" when you make it with strawberry. If you don't make it with chocolate, it isn't a chocolate shake. If you make an API stateful, it isn't RESTful.

[Monica Shiralkar]

If you do, then it isn't REST anymore, so, no.

If we make a SOAP web service stateful it remains SOAP web service. if we make REST web service stateful it does not remain RESTful.This means that SOAP is by default stateful whereas REST is by default stateless.Is it correct? What is the reason why SOAP is by default stateful?

thanks

[Tim Holloway]

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 simply an XML-based request/response data architecture.

ReST is, however, by definition stateless. It doesn't define the transfer data format as much as it does the concept of stateless operation.

It can get a little confusing, perhaps, considering that some ReST-based apps are interacting with persistent storage such as databases, which themselves are inherently holders of state. But the apps themselves retain no state.

[Monica Shiralkar]

I understood the explanation that REST is stateless but have doubt regarding below:

SOAP is state-neutral.

But why is it state-neutral. Is SOAP by default stateful?If so then why do we say so?

You can build webapps using SOAP that are stateful and you can build webapps using SOAP that are stateless.

This can be done with REST too but as Bear said the RESTful web service no more remains REST if we do so whereas SOAP web service remains SOAP. My doubt is that why so?

[Bear Bibeault]

SOAP is not defined by its statelessness or statefullness. Whoever told you that is full of bunk.

REST, however, has statelessness as part of its definition. So if it is stateful, it is not REST, even it meets all the other criteria of REST.

Again, a chocolate shake without chocolate can't be called a chocolate shake.

[Monica Shiralkar]

A coffee can be hot coffee or cold coffee. If it is cold coffee, then it does not lose its coffee behaviour.

SOAP is not defined by its statelessness or statefullness

I used to think that any technology is defined by what all is possible using it and statefulness is possible using SOAP.But then statefulness is also possible using REST too.

REST, however, has statelessness as part of its definition

But why so when statefulness is also possible using it.



thanks

[Bear Bibeault]

Monica Shiralkar wrote:But why so when statefulness is also possible using it.

It isn't. Again, by definition if it it is stateful, it isn't a REST API. You can call it RESTful all you want, but if it is stateful, it is not REST.

So you can't make a REST API stateful, because the act of doing so makes it not a REST API.

[Monica Shiralkar]

chocolate shake without chocolate can't be called a chocolate shake

Chocolate is to Chocolate Shake what X is to RESTful web services

What is X here.?


I think X cannot statelessness , because X has to be presence of something not absence of something. I am trying what is X.

thanks

[Bear Bibeault]

If not going to write a tutorial on REST APIs for you. In order for an API to be RESTful it must fit the definition of a REST interface; you can look it all up yourself. But apropos to this discussion, being stateless is one of the requirements for an API to be considered RESTful.

[Monica Shiralkar]

thanks

[Monica Shiralkar]

Apart from the reason told by Bear, there is one secondary reason too which I read on internet regarding why REST should not be stateful.It was written that REST cannot be stateful as REST is meant to be scalable . Now I am trying to understand what is the connection between scalability and statefulness.

[Bear Bibeault]

Tim already explained that in detail. Please read the responses.

[Monica Shiralkar]

Tim already explained that in detail. Please read the responses.

Thanks to Bear and Tim, I have understood. However now I have one doubt. 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?

[William Brogden]

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?

I can't imagine where you are getting these ideas.

All messaging APIs are intended to tackle the problem of scaling up.

Thats why messaging APIs exist - they let a client make a query without worrying about the exact connection to some server that can answer the query.

Thats the whole point - a SOAP message can be transmitted any way you can imagine to get XML formatted text from one place to another.

Bill

[Tim Holloway]

As a side note, SOAP isn't all that popular these days. It grew out of an era when XML was new and shiny and The Solution To Everything and CORBA (another Solution To Everything) had proven to be ill-suited to the Internet.

So one of the things people were trying to use SOAP for was as a Remote Procedure Call mechanism.

As it turns out, the latencies in the Internet meant that RPC wasn't the best approach for remote client interaction and XML is relatively expensive in terms of the work required to marshall and unmarshall and in the bandwidth it takes to transmit it.

So SOAP got pushed aside in favor of AJAX and Web Services and XML is mostly ignored in favor of the more compact and more easily-parsed JSON and YAML data formats. Along the way, the concept of ReST gained popularity as yet another way of adding performance.

This does not mean that SOAP was then or is now in any way preferential to either stateful or stateless communications. It cares not one way or the other whether ReST disciplines are used.

And speaking of which, if you haven't read this article: https://en.wikipedia.org/wiki/Representational_state_transfer then you should. It's pretty clear about the concept.

[William Brogden]

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

[Tim Holloway]

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

It's kind of apples and oranges. SOAP is a protocol that can handle payload encryption and authentication where the endpoints are separated by multiple intermediaries.

AJAX gets its authentication from the server it's talking to and its encryption from SSL/TLS. Any downstream encryption is in the infrastructure, not in the data.

JSON and YAML are simple data formats, not protocols, and whatever A&A mechanisms are applied are expected to be external.

[Monica Shiralkar]

Thanks.

All messaging APIs are intended to tackle the problem of scaling up.

If scaling has to happen then statefulness cannot exist.
statefulness can happen in SOAP and not REST.
This means REST can use scaling in all cases (because it is never statefull).
This would also mean the SOAP can scale at certain times (when it is not statefull).

So it implies that the below statement is wrong:

REST cannot be stateful as REST is meant to be scalable

[Tim Holloway]

Incorrect.

ReST cannot be stateful because the very definition of ReST is not being stateful: Representational State Transfer. What we actually mean by "stateless" here is that state is not held on the server. Databases, as I said, are stateful. Client workflows are stateful processes. But the server itself holds no state. The fact that it scales well is merely one of its attributes. Although it's an attribute that makes choosing ReST over any number of competing protocols desirable in many cases.

Likewise, just because a process involves server state doesn't mean that it's not scalable literally. It means that the cost of scaling relative to the server is proportional to the number of processes currently maintaining state. Whereas in "stateless" processing, that overhead is maintained on the clients and thus scalability is proportional to the server's ability to process client requests regardless of its internal state-storage capacity.

[Monica Shiralkar]

ReST cannot be stateful because the very definition of ReST is not being stateful:

ok..suppose the requirement says to build web services such that :

Requirement:

a) It is required to be a simple light weight web service (SOAP features like encryption, security etc are not required).
b) It is required to be stateful.



Now for the above requirement which type of web services should be built? SOAP or REST?


Suppose someone builds RESTful webservices using API such as RestEasy,Restlet and makes it stateful (also stores in database). It is no more RESTful for the reasons discussed in this thread that a web service which is stateful cannot be REST. But it is not based on SOAP too.So it is not RESTful,it is not SOAP based and it is a web service built using RESTful API, then which one is it?

But the server itself holds no state.

So does it mean that in case of SOAPful web services, the server itself can hold state? Is so then what does it mean in case of SOAP based web services.

thanks

[Ron McLeod]

Monica Shiralkar wrote:It is required to be stateful.

Can you give an example of why statefulness would needed for your web service?

[Tim Holloway]

Sit down and meditate on the following 2 statements you made:

It is required to be stateful.



Now for the above requirement which type of web services should be built? SOAP or REST (stateless protocol)?

Think about what you said carefully.

[A.J. Côté]

I have never seen so many posts on such a trivial subject.

So I will go with my own reply too: REST services are stateless because they like to rest so much, they haven't got time to maintain state!

Seriously, make your REST like service stateful if you want to, I won't complain about it if you do so ;-)

NOTE: you don't need to use HttpSession, you can use your own unique token that is sent every time although it is similar to what HttpSession does.

Cheers,

[Monica Shiralkar]

I wrote

It is required to be stateful.
Now for the above requirement which type of web services should be built? SOAP or REST (stateless protocol)?

Tim Holloway wrote

Sit down and meditate on the following 2 statements you made:
Think about what you said carefully.

Ok so the answer to my question is : It should be a SOAP based web services because it is required to be stateful and RESTful cannot be stateful. But the requirement had also said that it should be lightweight and does not require SOAP features like SOAP security and SOAP encryption. Thats why all this doubt came up.

I have one more doubt. Why are SOAP based web services not as good to scale as RESTful web services. Any reason for that?

thanks

[A.J. Côté]

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?

Because they might have to maintain state which is more complicated with a pool of servers although experience has shown that this can be mitigated relatively well.

Also, but not directly related to horizontal scaling, parsing soap xml incurs a non-negligible load on the server compared to parsing xml-rpc or key/value pairs. This will make a difference when you scale vertically,

[Paul Clapham]

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?

[A.J. Côté]

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?

Again, make your REST, custom key/value pairs, xml-rpc, ajax or whatever service stateful if you wish. It's not like there is some kind of law preventing you from doing so. Use the right solution in your humble opinion for the use case. If you choose the wrong path, you will learn from it and do better next time thus; gaining experience ;-)