> 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
>
>
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
> >456
> >300
> >
>
> It *seems* like you're pass
cent
> Envoyé : lundi 18 septembre 2006 05:53
> À : discuss@restlet.tigris.org
> Objet : Re: Re: How 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 i
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 o
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,
whic
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 th
6 matches
Mail list logo
