> 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.
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?