Doubts about links in banking applications

Stefan Titkov has posted a Doubts about links entry where he talks about why doing

GET http://example.com/192879202039374738

is better than having a method like

Customer getCustomer(ID id) :

If I have an id, I need to know that a) it is, indeed, a customer ID and b)
that I have to call get getCustomer() method to retrieve more information.
There’s no agreement, no uniformity to the interface.

etc... This is all the proper REST talk from Stefan.

The reason this entry caught my attention was that a sample application referred to was a banking application. Surprisingly, bank/accounts are talked about very often in the context of discussions about web services, I myself used to refer to banking applications few times before.
Surprise, surprise, I've never written a banking application before :-), but those banks are so handy when discussing applications built around factory patterns.

As it happens, I'm thinking a lot, like many other people too, when and why I would use a RESTful style when building a service as opposed to using a more coarse-grained approach.

Questions like : what is the audience (who is going to consume the service), what is an ultimate benefit, how practical it is, etc are bothering me. I see a lot of potential from exposing different types of data resources to the WEB. Their state can be transient but top-level resources themselves should be fairly stable, as far as their life-time is concerned.

After all, as far as programming REST is concerned it's all about making the life of consumers easier, right ? It's nice when they can use their browser and see the application data, or use, say, an Atom-enabled reader and check the events coming of my application. It's cool when they can build mashups on top of my own data.

So when I see people saying, ok, when you do your banking applications, just use GET when referring to say people's accounts, because it's RESTful, I'm getting confused. I'd love to see at least one analysis out there which would explain what does it mean, practically, to write a banking application using a RESTful approach.

When I'm doing my online banking I'm going to http://mybank/internet, login there, and start a transient and secure session. I'm not going to add a link to my account to my Favourites folder nor I'm going to build a cool mashup on top of it. There's unlikely to be some kind of generic intermediary sitting between the client and a server and doing some advanced caching.

I'd like to understand what does to mean, to write a banking application using a RESTful approach. I'd also love to see, at least once, someone unreservedly advocating REST, saying : may be for some types of applications a resource-oriented approach might not be the best fit...

I know, I can write most of my applications using a RESTful approach. But I also know that I can use XSLT to split a 1MB string using recursive functions or solve a complex chess problem, the question is, what for ?, as XSLT is really perfect at doing apply-templates and match, but not at solving algorithmic problems.

So as far as I'm concerned I'd like to see the ultimate goal of going with REST for a given service, rather than doing it for just the sake of it and then failing to figure out, who is going to benefit from it ?, while telling at the same time to all my friends that I've written a RESTful service.

I'm looking forward to seeing more pragmatic and practical discussions in this area.