> I think the approach you're advocating forces the client to know way more about the server than it should, and to make it do way more work than it has to.
> > POST /transfer/account/123 > > Host: myserver.com > > Content-Length: XXX > > <toAccount>456</toAccount> > > <amount>300</amount> > > > > It *seems* like you're passing an action, but IMO what you're actually > doing is turning the action into a resource, which is very powerful. > That resource has a unique address, a state that can be transferred, and > is only manipulated with our four magic verbs. You can even make it > asynchronous by posting a transaction and polling for its status later > at the resource's URL. > http://tech.groups.yahoo.com/group/rest-discuss/message/6561 So, you're suggesting that a URL like /transferMoney/account/123 is indeed a resource, especially if it is used in conjunction with a transaction (as Benjamin suggested in his post): client -> server: POST /transferMoney server -> client: created; location: http://myserver.com/transferMoney/789 client -> server: PUT /transferMoney/789 <fromAccount>123</fromAccount> <toAccount>456</toAccount> <amount>300</amount> The fact that the transfer happens inside a transaction is a server concern; the client does not need to have this knowledge. Plus, it forces the client to make 2 calls instead of one. > > > 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: > > > > If you don't want to retrieve them one by one I think you can do the > same thing, invert an action into a resource with something like: > > GET /accounts/?inactivityPeriod=365 > > You get back a set of account URLs: > > <accounts> > <account link="/account/1234" /> > <account link="/account/1235" /> > <account link="/account/1236" /> > </accounts> > > Which maybe you can POST to an 'account closing' resource: > > >> > POST /account-closer > <accounts> > <account link="/account/1234" /> > <account link="/account/1235" /> > <account link="/account/1236" /> > </accounts> Here are the issues I see with this approach: - you force the server to expose an extra search API - the result set could be huge. - increased traffic between the client and the server - you still have a RPC-sounding resource (the accountCloser) > Or whatever. I'm pretty sure this isn't gospel, but it makes sense to > me, and I think demonstrates the power of the 'resource' abstraction. Hmmmm, it seems to me that you're bending to API to make it fit the REST model, to the point where you end up breaking the abstraction layers (client knows/does too much). I'm a REST newbie, so I might very well change my mind and adopt your point of view, but -at this point- I'm still unconvinced by this 'action as a resource' approach. -Vincent.
