Re: I-D Action:draft-snell-http-prefer-03.txt

["Roy T. Fielding" <[e-mail]>]

On Mar 29, 2011, at 11:31 AM, Poul-Henning Kamp wrote:

> In message <[e-mail]>, Mark Nottingham wri
> tes:
> 
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-snell-http-prefer-03.txt
> 
> Couldt we please try to make it a habit to include some kind of use-case
> or justification for these "bolt-on" drafts ?
> 
> It's probably my imagination that is flawed, but the only mental connection
> I can attach to this draft is RFC748, so somebody please explain:
> 
> 1. Whats the point.
> 
> 2. How dows this help.
> 
> 3. How much will it help.
> 
> Poul-Henning

heh, I just asked Mark the same question ...

The goal seems to be to ask for the server's result of a PUT or POST
to be returned as part of the same action instead of requiring the
client to make an additional GET request.

The problem with any such desire is that the mechanism handling
a PUT is not always in control of the resource's final state.  The
reason is simply that the mechanism for handling GET may be an
entirely different system from that handling PUT, may have access
to additional sources of metadata, and may be impacted by background
jobs independent of the HTTP request (i.e., event-based triggers on
content changes that result in workflows being run that eventually
change the content shortly after the client has received its response).
Moreover, the programmer writing the PUT handler is probably not
the same programmer developing those other systems, so this feature
is not going to be very reliable.

I agree, the draft should contain use cases to justify the feature
and make it clear that it may only work with very simple,
synchronous, self-contained implementations.

....Roy