Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

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

 
Monica Shiralkar
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Any preservation of state with a SOAP API or a RESTful architecture is up to you the programmer.

Bill


 
Monica Shiralkar
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks
 
Monica Shiralkar
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim already explained that in detail. Please read the responses.
 
Monica Shiralkar
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 1432
207
Android Angular Framework Eclipse IDE Java Linux MySQL Database Redhat TypeScript
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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é
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 886
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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é
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 22185
38
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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é
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ;-)
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!