- From: Roy T.Fielding <fielding@gbiv.com>
- Date: Fri, 9 Jul 2004 15:33:37 -0700
- To: Lisa Dusseault <lisa@osafoundation.org>
- Cc: ietf-http-wg@w3.org
On Friday, July 9, 2004, at 12:53 PM, Lisa Dusseault wrote:
> I find that client implementations generally act in ways that they
> find the server can be predictable. With what you describe, a client
> implementor can write this code
>
> Try PATCH on known empty resource
> trap error {
> send PUT
> }
>
> Or:
>
> Send PUT on known empty resource
>
> Gee, which is simpler...
That depends on the application. There is nothing preventing the client
from making that decision on its own, so there is no reason for the
protocol to standardize one over the other. Likewise, some servers
may choose to allow PATCH but not PUT (for resources that only allow
a certain type of modification, for example). The protocol does not
need to be restricted to the common case.
> So the predictable thing for PATCH would be to either to have
> consistent and predictable behavior for the method with all patch
> types, OR at least to have consistent and predictable behavior for a
> given patch type.
You can't require that a server accepts a request. Whether it is PATCH
or PUT, empty or existing, the only thing the protocol can do is state
the syntax and meaning of the messages. A reasonable thing to specify
is that if a server is willing to accept a PATCH on a URI that has no
current representations, then its behavior must be consistent with the
patch being applied to an empty representation.
The client can choose which method to use on its own, based on its own
environment and its own constraints.
....Roy
Received on Friday, 9 July 2004 18:33:10 UTC