27

I have been reading about about Restful webservices being Stateless. I can also see that most of Soap based webservices are also stateless and can be made stateful if needed and making them stateful will depend on implementation. So if a soap based webservice is stateful then a session id will passed with every request, to continue with session.

My query is why can't same be done with Restful webservices, I think i should be able implement a webservice which can continue with same session where session id is passed by Restful webservice making is Stateful.

So my question is, Are RestFul webservices just a concept with a guideline not to make them stateful? or there will be checks in Restful webservice libraries [like Jersey ] to stop people from doing so?

Lokesh
  • 7,810
  • 6
  • 48
  • 78
  • 8
    You can surely make REST services stateful. But it goes against REST philosophy. You won't be able to scale (notably, because of server affinity). – David Brabant Nov 17 '13 at 14:24
  • There are no such checks in any REST library that I know of, but as @DavidBrabant also said your service will not be RESTful anymore. Why would you want to make them stateful? – Leonard Brünings Nov 17 '13 at 14:27
  • @Leonard: I am just trying to grab the concept. Everywhere this is highlighted that Restful is stateless. Going by your point if i make a Get request of Rest webservice stateful then it will not be Restful? It will not be Soap for sure then what will it be? – Lokesh Nov 17 '13 at 14:33
  • 1
    @Lokesh you will have a webservice that uses a REST library for a stateful application. – Leonard Brünings Nov 17 '13 at 14:38

3 Answers3

27

The statelessness of REST is designed to ensure applications scale well. You can add state, but it's at a trade-off in scalability.

One of the most common reasons to add state to REST is for authentication. Once a secure connection is established, a secure cookie can be sent to the client. This cookie is then added by the client to all requests for the session. The server maintains state and then loads that state in with every request based on the cookie.

Consider a simple web page. If you are not maintaining state, you can put up a reverse proxy, cache the page in memory by URL, and distribute that resource across many servers for load. If you now add the name of the currently logged in user to that web page, you can no longer cache anything (at least at the most basic HTTP level). The response can now be cached only with a combination of the authentication cookie and the URL.

rich remer
  • 3,407
  • 2
  • 34
  • 47
  • 4
    Statelessness may have been "designed" to permit scale, but what about cases where scale is not an issue and never will be? – John Saunders Mar 19 '14 at 20:24
  • 2
    There are some reasons to prefer statelessness related to system complexity, but mostly it's scaling. If you are not going to scale, then adding state probably won't cause any headache. Web sites have been doing this for decades. It's just not very REST-ful anymore. – rich remer Mar 19 '14 at 21:00
  • 1
    Rich, i just question whether "REST-ful" is an actual requirement or not. There are many aspects of "REST" that I have never seen as requirements. I have never seen a requirement for [HATEOAS](https://en.wikipedia.org/wiki/HATEOAS), for instance. – John Saunders Mar 19 '14 at 21:03
  • 1
    Perhaps not. But since the questions asks about making RESTful services stateful, it seems like the answer is: not really, it's not REST anymore. You can certainly add a state layer on top, as when using an auth cookie. – rich remer Mar 19 '14 at 21:20
  • 1
    @JohnSaunders HATEOAS was introduced to decouple clients from domain specifc knowledge like building the URI of related resources or determin the next possible actions. Sure, plenty of self-named REST services are not RESTful, even Roy Fielding claimed that many enterprises misused the term REST for their marketing strategies. – Roman Vottner Aug 02 '16 at 14:27
  • @roman even two years later, I've still not seen a case where next steps should be dictated by the server – John Saunders Aug 02 '16 at 16:05
  • 2
    @JohnSaunders they are not dictated but suggested. In a browser you are able to type in an URI, though I bet often times you surf to new sites using links. REST is copying (generalizing) this idea and suggest to change services and clients to behave like browsing web pages. Instead of the user knowing every possible URI that can be entered in the location bar, a start site is requested and depending on the presented result further decision **can** be made – Roman Vottner Aug 02 '16 at 16:39
  • The obvious case where the server should "dictate" next steps is during pagination, where the server should provide an HTTP link with the `next` relationship. – rich remer Jul 24 '18 at 23:35
1

As long as I know, we(.net developers) can use WS-binding in wcf for stateful Web services.

Ali Fattahian
  • 495
  • 1
  • 6
  • 24
1

Web service, whether it is Rest or SOAP, is by default, designed stateless. But there can be use cases where it is required to be stateful. Web Services Resource Framework (WSRF) provided by OASIS, can be used to make a SOAP web service, stateful. Add a ResourceProperties attribute to the endpoint and add a ResourceProperty operation to the WSDL and pass it across web services.

Rest engages in state transfer and to make them stateful, we can use client side or db persisted session state, and transfer them across web service invocations as an attribute in either the header or a method parameter.

Siddhartha Tripathy
  • 21
  • 3