Webservices are stateless?

Question

Why do we say that web services are stateless?

Aminta

Answer 1

They don't persist any state between requests from the client. i.e. the service doesn't know, nor care, that a subsequent request came from client that has/hasn't made a previous request. Basically, its a 'give me this piece of info and forget about me' which puts the onus on the client to maintain any state.

Celebration

The version I commented on was a lot shorter, and basically said "because they dont persist state." I'm deleting my comment plus here's an upvote. – Christhood

@mike: my bad. I felt the same way. That's why I updated it. – Celebration

@brian: What about subscription streaming in EWS 2010 onwards? Does that keep some type of state like an open TCP connection from the EWS web server to the Exchange server? The reason I am asking is because of performance. Also with general request, is there an overhead on the server in terms of sessions left open from the EWS web server to the exchange server? – Idiotic

Answer 2

Because web services are based on HTTP, which is a stateless protocol.

Quoting wikipedia :

A stateless server is a server that treats each request as an independent transaction that is unrelated to any previous request.

i.e. each request is independant from the previous one : even if we use some "tricks", like cookies for instance, to preserve some state between requests, this is not something defined by the protocol.

Esurient

There's a big difference between a stateless protocol and stateless web service. The application can be stateful (using "tricks", as you mention) while the underlying protocol is stateless. Also, web services do not necessarily imply HTTP. SOAP can work with SMTP as a transport layer, for example. – Gerri

I would hesitate to call an SMTP SOAP service a "web service". There are lots of types of services, but to me, web service = HTTP or HTTPS. SMTP was around before the web. So I think Pascal's correlation is fine. – Hixson

Answer 3

Because HTTP is stateless. After a client request is fulfilled by the server, no information is stored for use in future transactions.

Thomism

Answer 4

The concept of a web serivce is to model a RPC (Remote Procedure Call) aka a Function. Thus you should not need to use session. In addition, the idea of being stateless comes from the need to scale out web servers into a server farm and thus enable higher capacity.

However, the choice of using state is dependant upon the technology and the developer. There is nothing to prevent you from creating an ASP.Net Web Service and setting "EnableSession=True" in the method definition.

This can be useful in some basic authentication scenarios, i.e. home-grown forms authentication or to provide automatic correlation for short-lived "workflow"'s. (However I strongly urge you consider more modern techniques will provide a higher level of security and performance).

Infatuation

Answer 5

Requests are independent from one another.

Pretermit