wood burning stoves 2.0*
The moose likes Web Services and the fly likes REST vs SOAP - stateful/stateless Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "REST vs SOAP - stateful/stateless" Watch "REST vs SOAP - stateful/stateless" New topic
Author

REST vs SOAP - stateful/stateless

Suma Rangaraj
Ranch Hand

Joined: Feb 02, 2005
Posts: 50

Hello -

This might be a simple question but I could not understand it very well. All the information on the internet got me more confused and I am a newbie to the concept.

1. In one of the posts that I read, it is mentioned that the difference between REST and SOAP is that REST is stateless and SOAP is stateful. My understanding is that the statelessness and statefulness depends on the underlying protocol. So, if we choose HTTP as a protocol then both SOAP and REST can be stateless unless we pass some session ifnormation in the request. Is my understanding correct?

2. If I am right, how do we achieve statefulness using SOAP? Just by using a different protocol like SMTP (I believe SMTP is stateful)? Can some one explain me teh details?

3. Also, in REST, we do not need any specific contract like WSDL am I correct? In that case, how is the service distributed to the client? In case we are converting a SOAP based service to REST based service, what the steps to be considered?

Thanks a ton folks!!
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18715
    
    8

Suma Rangaraj wrote:1. In one of the posts that I read, it is mentioned that the difference between REST and SOAP is that REST is stateless and SOAP is stateful.


Could you provide a link to that post?

My understanding is that the statelessness and statefulness depends on the underlying protocol. So, if we choose HTTP as a protocol then both SOAP and REST can be stateless unless we pass some session ifnormation in the request. Is my understanding correct?


No, that's incorrect. "Stateful" means that the server stores information about the client and uses that information over a series of requests. You can do that over HTTP with any higher-level protocol. I have written a client for a stateful SOAP protocol.

2. If I am right, how do we achieve statefulness using SOAP? Just by using a different protocol like SMTP (I believe SMTP is stateful)? Can some one explain me teh details?


No, I'm sorry, that is just ridiculous. SMTP is e-mail. So, not stateful at all, and because of its unreliability it's not suitable for web services.

3. Also, in REST, we do not need any specific contract like WSDL am I correct? In that case, how is the service distributed to the client? In case we are converting a SOAP based service to REST based service, what the steps to be considered?


You can do whatever you like in a REST protocol. And the way that the service is distributed to the client is that the server people write some documentation and post it in a place where potential clients can see it.

Really, I'm sorry to say this, but you just have no idea. And you have structured your learning in completely the wrong way, I'm afraid. Instead of learning about the protocols and how they work, you have seized on the concept of "state". Trying to learn about protocols from that point of view isn't going to work.

Suma Rangaraj
Ranch Hand

Joined: Feb 02, 2005
Posts: 50

Could you provide a link to that post?


This is a post to name one - http://edn.embarcadero.com/article/40558

You can do whatever you like in a REST protocol. And the way that the service is distributed to the client is that the server people write some documentation and post it in a place where potential clients can see it.


OK It is distributed via documentation. I am still not clear when you say - so can do anything. are you saying WSDL is a way of distributing

Instead of learning about the protocols and how they work, you have seized on the concept of "state". Trying to learn about protocols from that point of view isn't going to work


If you know of a good URL, please post it here.

I know I don't understand it well, but I will be glad if some one can be a little patient in explaining this.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18715
    
    8

That link goes to a perfectly good article, but it's clear that you didn't understand much of it. That's because it wasn't written for complete beginners. If you don't understand any of the technical terms in an article then you aren't going to get anything out of that article.

I don't know why you started with that article, but if you want to learn from links then I would suggest starting with Wikipedia.

H Paul
Ranch Hand

Joined: Jul 26, 2011
Posts: 471
    
    4
"A day spent without the sight or sound of beauty,
the contemplation of mystery, or the search of truth or perfection is a poverty-stricken day;
and a succession of such days is fatal to human life."


Any time, I hear Rest vs Soap, I go back to this link/article to re-examine/re-fresh/re-question my own understanding.

http://www2008.org/papers/pdf/p805-pautassoA.pdf

So if it help clarify your understand, then so let it be.
Suma Rangaraj
Ranch Hand

Joined: Feb 02, 2005
Posts: 50
Thank you Paul for putting up with my ignorance. I will go through the article that you ahve mentioned below.

Hope I can ping if I have further questions.

Thanks.
John M Brown
Ranch Hand

Joined: Nov 29, 2001
Posts: 62
Hi Suma,
I agree that you can find some other links that will build up your knowledge of REST 1st, because there are a lot of links that assume the basics are known or at such a high level that certain assumptions cannot be made from them...

A useful article from Zapthink gives a good explanation of how state works in a RESTful application. The last 2 letter of the acronym for REST is State Transfer, so this gives you an idea of how state is managed, but this article talks about application state vs. resource state. Ignore the fact it talks about Cloud computing as the explanation stands on its own: http://www.zapthink.com/2011/11/22/the-secret-to-a-restful-cloud/

As far as the WSDL comment, if you return hypermedia links in your representations to drive your app, you do not need a service specification (and very little documentation beyond the home URL or docRoot entrypoint to your app. If you are using XML as the format for your REST representations, then something like WADL can be used. If you are using JSON, then there is no current formal specification for JSON although there are groups working on that. A large part of the JSON community fears that using a specification in JSON will render it inflexible during design as WSDL has done with SOAP. I don't necessarily agree with that notion. Here's a few links to people looking at JSON specifications:

  • http://json-schema.org/
  • http://www.wrml.org/

  • Also I'm copying a private blog post I've made at work on REST to help guide you to some good starters for REST design as I was researching REST. Can't attach the powerpoint here, so you will have to ignore that comment in the blog post. Hope this helps your journey


    __________________________________________________________________________________________________________________
    Moving from CRUDyRest to HyperRest

    So I started to do some more research via books like Rest in Practice, Internet blogs and such. I came across quite a debate of what was considered a RESTful architecture. I lot of it stems from the work of Leonard Richardson dubbed the Richardson Maturity Model. The blog by Martin Fowler linked in the previous sentence discusses the model as steps toward the glory or REST. But Roy T. Fielding who created the REST dissertation made it pretty clear in his blog that hypermedia was a prerequisiteto a RESTful architecture.


    As I found more information and started exploring this concept, I realized that the 4 levels (level 0 to 3) of the RMM are not steps to build a RESTful architecure. These are learning steps, or evolutionary steps for an existing HTTP service implementation. It doesn't make sense to start at one step and build to the others unless your architecture is already at a step.


    My first inclination in designing a RESTful system was to start at defining the resources and their relationships as most people do. This technique naturally steers you toward building an RMM level 2 CRUDy REST API. Sure, you can enhance your system into a level 3 from there, but for all those client apps that relied on the resource structures and relationships to build their client code - they are now coupled to that model and probably will need to change to take advantage of the hypermedia aspect coming down the road. Also any changes to the resource and resource relationships (which can inevitably happen when trying to get to level 3) will break the application code for those early-adopting clients.


    The author of the Richardson Maturity Model, Leonard Richardson wrote an abstract on how he built a client (in Python) to take advantage of the Hypermedia As The Engine Of Application State (HATEOAS) concept over RESTful services. This was to show results on the advantages of this approach as it seems to be hard to grasp for many developers.


    So I'm now attempting to identify a checklist (in no particular order) of analysis/design techniques for building RESTful architectures.


    Although I have not prescribed a particular order to promote an iterative approach, all good designs and architectures start with enough requirements and analysis to design and build something useful.

    I'm not going to go into a soapbox on Agile vs. Waterfall and Incremental vs Iterative here as it's not the point of this post. I will probably be expanding on this in the future. Just resign yourself to the fact that you are not going to know 100% of all the requirements to design your entire system before providing workable code.


    Here's those initial analysis techniques to start off with:

  • Come up with a good (or cool) REST API name and concept that preferably aligns with the domain area you are tackling (for the REST in Practice book this is the "Restbucks" system)
  • Identify Actors/Personas/Roles for those that will be using the REST API. What are their needs and motivations?
  • Identify the Business Process / Sagas that will be going on in your system. This may be very basic and simple at first, but will evolve more.
  • Identify Use Cases / User Stories that will involve your system
  • Identify the common base media types that clients will want to use to communicate with the REST API (i.e. JSON, ATOM, XML, etc)


  • These analysis techniques can be used in any order to drive out refinement for each other. For example I can start with an initial user story and use that to identify some personas (or actors). This user story may lead identifying another user story that can then be filled out in the saga / business process.


    After getting a good set of analysis data to where you have a good direction you can then start designing the API.


    Here' the design techniques you can use on the analysis to build a good API.

  • From the use cases / user stories identify your entry points into the REST API. Then build a home resource (or URI) that returns a representation with transition links to these entry points. This is similar in concept to the home page of a website providing the links needed to get started based on a user's need.
  • For the entry points, design the representation that will bring back the appropriate transition links for the next possible steps in the use case / user story. The allowable transitions states will depend on where in the business process / saga the client app is (think of this as business process state). These transitions can also be constrained by the internal state of the resources.
  • Start building your resources and resource relationships. This is essentially designing the URI structures returned by the transition links. Remember that the structure of your resources and their relationships to other resources should be abstracted from the client via the hyperlinks returned in the representations as much as possible.


  • Ideally a client using a well designed REST API that follows these techniques should be able to to the following...


    1. Perform a GET on the home URI

    2. Extract the entry point links from the representation

    3. Use one of the transition links to perform another REST call based on client decision logic

    4. Extract the transition links from the next representation

    5. Repeat steps 3 and 4 until business process is done


    This flow is very similar to the one described in Leonard Richardson's abstract above for how someone browses the WEB...


    1. Retrieve a hypermedia representation of the home page.

    2. Decode the representation to determine the current resource state.

    3. Based on the representation's semantic cues, decide which hypermedia link or form is likely to bring you closer to your goal.

    4. Click the link or fill out the form. Your browser will make another HTTP request and the result will be another hypermedia representation.

    5. Go back to step 2 and repeat until the resource state is to your liking.



    Through this process the client should never have to generate or append to a URI in order to make the RESTful call. It only relies on the link name for out-of-band information.


    For an animated presentation of this process, you can download and view the power point deck attached.


    In a follow-up blog, I will discuss the challenges of reducing out-of-band information for the client app. For calls with no parameters or input representations this is pretty easy, but can be more involved when using query parameters, path parameters, and input representations.


    <a href="mailto:JBROWN2002@cfl.rr.com" rel="nofollow">JBROWN2002@cfl.rr.com</a>
    Paul Clapham
    Bartender

    Joined: Oct 14, 2005
    Posts: 18715
        
        8

    Suma Rangaraj wrote:Thank you Paul for putting up with my ignorance. I will go through the article that you ahve mentioned below.


    Don't forget that a web service is created for some specific purpose. I mean, to do actual real-world work for somebody. If you approach studying web services in an abstract way, you are likely to get diverted by things which are minor details (as you did). So when I said "You can do whatever you like in a REST service" that's what I meant. If you want a REST service which tells you the next day that garbage will be collected from a particular address, you can do that.

    Here's an analogy for you: if you haven't ever driven a car, then reading articles about how steering wheels are constructed isn't going to be very useful.

    Hope I can ping if I have further questions.

    Thanks.


    Absolutely! That's what the Ranch is here for.
    Suma Rangaraj
    Ranch Hand

    Joined: Feb 02, 2005
    Posts: 50
    Thank you James for your detailed answer.

    The following posts gave me a fairly good idea of statelessness means for REST. Good explanation for newbie like me. Posting it here for the benefit of all -


    http://stackoverflow.com/questions/544474/can-you-help-me-understand-this-common-rest-mistakes-sessions-are-irrelevant

    http://www.ibm.com/developerworks/webservices/library/ws-restful/
     
     
    subject: REST vs SOAP - stateful/stateless