> Okay, so this brings up the question of "how pure do you want to be?"
More exactly, it brings the question of "what am I gaining by trying to be 100% ‘pure’?" > To be much more pure, you'd do this in stages: > PUT to e.g.: /<authinfo>/account/123/transfer > and get back a transfer transaction ID. Then, you'd do the specific > > transfer: > POST to e.g.: /<authinfo>/account/123/transfer/≤transactionID> > amount=$1,000.23 > targetAccount=456789 > and you'd get back a confirmation code or whatever as the body of the > 200 response (if the 200 response isn't enough all by itself). Yes, I’m starting to see that (although it seems to me that you have your POSTs and PUTs backward: shouldn’t you use a POST to create the transfer transaction, and a PUT to send the tx details?). > Then, you can always do a get to e.g.: > /<authinfo>/acount/123/transfer/≤transactionID> to e.g., get the > details of that transfer. > > 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> > > Um, er, isn't that just something that is done on the server? Is this > for an admin client instead of a user client? It was just an example. So, yes, you can imagine it’s for an admin console. Following the approach you suggested, I guess it would look like this: Client -> server: POST /<authinfo>/accountJanitor server -> client: 201 Created server-> client: Location: >/accountJanitor/12 client -> server: PUT accountJantor/12 <inactivityPeriod>365</inactivityPeriod> As I’ve mentioned in my response to Jerome, I think this solution has the merit of helping make all requests idempotent. My problem was that I would most likely want to extend this mechanism to resources creation as well; i.e. instead of POSTing a account resource, I would POST a tx resource and PUT the account details in this tx. -Vincent.
