Because not everything in the world maps well onto request-response, and trying to put stateful bi-directional communication on top of HTTP is an ugly hack.
While that's true, it seems that a function call maps precisely onto request-response: call a function, get back a return value. Statefulness isn't a problem for REST or HTTP either, because it's the communication protocol that's stateless, not the resources. For example, websites are REST services, the pages on the website are the resources, and they certainly exist: that's their state. What's stateless is that it doesn't matter what order you retrieve the pages; you'll always get the same page for a given URL. The only exception is when the request is intended to change the state of some resource, such as this thread changing state when I submit the comment I'm writing.
For a RESTful function call service, each function would be a resource, and the functions would be required not to have side-effects (eg: don't change the state of the service). That's often good design for any API, not just RPC-type services. Again, the exception would be function calls whose purpose is to modify the service state in some way.
When the service state is intended to be different for each user of the service, HTTP has a solution for that too: a cookie which contains a token identifying the session. Any state changes can be associated with the token.
Now you mention bi-directional. If you mean that either side of the interaction can initiate an exchange, then you're right; HTTP is no good for that. Not many RPC services work that way though; it's more complex to design. It's much more common and simpler to have client/server interactions where the client initiates every exchange, and the server listens and responds. You can do a lot with that model.
> It's much more common and simpler to have client/server interactions
I can’t agree with such a blanket statement. It completely depends on your goals and application logic. All kinds of protocols/applications are designed to be bi-directional (multiplayer games (think MUDs, FICS, etc.), IRC/Jabber/other chat, VoIP, push email, message queues, multi-user document editors, telnet/SSH, remote device monitoring apps, etc. etc. etc.
Just because such apps aren't so often seen on the web, where their function would have to be hacked on top of HTTP, doesn't mean they aren't common, in general.
Running your multi-player game protocol over HTTP, using cookies to record the session, and polling for updates, just so you can say you’re being RESTful (and "simpler"?) is a terrible terrible idea, because if the semantics of your app stay the same, you basically have equally complex logic, now with several layers of indirection and overhead tossed in for no reason.
> For a RESTful function call service, each function would be a resource, and the functions would be required not to have side-effects
Okay, I want my function call to be "I just captured your queen with my rook, and you'd better find out about it because it's now your turn". How does that work exactly?
I didn't say that everything was a client/server type of interaction; I said that client/server interactions are more common than bi-directional client/client interactions. You've provided a list of client/client protocols, which is great, but I still think client/server is much more common.
For client/client, you're right: HTTP is not appropriate. If you can stomach the XML Jabber (aka XMPP, right?) looked like a good general-purpose bi-directional protocol, and if I'm not mistaken that's what Google Wave is using. If you don't want to pay the XML parsing/serializing overhead, other protocols are available, and maybe that's why BERT-RPC was created. My original point was simply that, depending upon the requirements, the existing HTTP protocol might be sufficient for the kind of interaction needed and it's supported by a rich infrastructure.
