to compromise when designing a RESTful API?
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
On 9/16/06, Vincent [EMAIL PROTECTED] wrote:
[...]
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
On 9/18/06, Vincent [EMAIL PROTECTED] wrote:
[...]
Yes, but objects have state *and* behaviour. All the REST articles I've seen so
far conveniently ignore the behaviour part by carefully choosing examples where
the server does not need to perform any business logic (e.g. the ATOM protocol,
which
On 9/18/06, Vincent [EMAIL PROTECTED] wrote:
[...]
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?).
Ah, yes, this is a major bone of contention
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
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
toAccount456/toAccount
amount300/amount
It
6 matches
Mail list logo
