REST and re­li­a­bil­i­ty

When­ev­er I see a pre­sen­ta­tion on REST I am im­pressed by its sim­plic­i­ty. With just four op­er­a­tions (GET, POST, PUT, DELETE) it seems to ac­com­plish a sim­ple mod­el for ser­vice-ori­ent­ed ar­chi­tec­tures, where every busi­ness re­source has a URL.

With this sim­plic­i­ty, REST also lever­ages the ubiq­ui­tous HTTP pro­to­col as the un­der­ly­ing mech­a­nism. More and more peo­ple seem to like this, in­clud­ing me.

How­ev­er, the big ques­tion for me is: how do you make this re­li­able? Imag­ine that you in­te­grate 4 sys­tems in a REST style. You would be us­ing HTTP and a syn­chro­nous in­vo­ca­tion mech­a­nism for each ser­vice. Now comes the ques­tion: how re­li­able is this? The an­swer: less than the least re­li­able sys­tem that you are us­ing! More pre­cise­ly, avail­abil­i­ty goes down quick­ly be­cause your ag­gre­gat­ed ser­vice fails as soon as one of the ser­vices fails...

With trans­ports like JMS you can im­prove re­li­a­bil­i­ty, but how do you do REST of JMS, giv­en its close re­la­tion­ship with HTTP and URLs? That is the prob­lem with REST for me.