Thanks John for the great feedback. > On the source account, you'd initiate a transfer with the > arguments being the target account and the amount. The > result on success would be that specific transfer's ID.
Ah, but you're not saying how you 'initiate a transfer'. It's one of the questions I'm struggling with. It could be: POST /account/123 Host: myserver.com Content-Length: XXX <action> Transfer</action> <toAccount>456</toAccount> <amount>300</amount> Or: POST /transfer/account/123 Host: myserver.com Content-Length: XXX <toAccount>456</toAccount> <amount>300</amount> The problem I have with the first approach is that I'm still passing an action, i.e. doing some kind of RPC. My understanding is that in a 'pure' RESTful API the only way to specify the action is via the HTTP method (get,post,put,delete). The second solution seems even worse as it mixes the action with the resource. > You authenticate and then post to the account's close. So, same approach: POST /account/123 Host: myserver.com Content-Length: XXX <action>close</action> Again, this smells like RPC to me. And what if I want to close all accounts that have been inactive for at least a year, without retrieving them one by one? Would this approach: POST /account/?inactivityPeriod=365 Host: myserver.com Content-Length: XXX <action>close</action> be more appropriate than this one? POST /account/ Host: myserver.com Content-Length: XXX <action>closeInactive</action> <inactivityPeriod>365</inactivityPeriod> > You might want to look at the Atom protocol for a good example. I reviewed this protocol, but it seems to me that --with Atom- the entire business logic is run on the client, letting the server act as a simple data repository. In that case it's easy to have a 100% RESTful with no traces of RPC. Thanks, -Vincent.
