- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Fri, 9 Jul 2004 12:53:53 -0700
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: ietf-http-wg@w3.org
>
> What is important for interoperability is that the server can indicate
> to the client when an unexpected condition isn't met -- that way, the
> standard doesn't have to define which condition is right for all
> applications. So, I would write that PATCH on an unbound URI may,
> at the server's discretion, either result in an empty representation
> being created prior to application of the patch or an error code from
> the server indicating that the method is not allowed on an unbound URI.
>
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... I've seen clients go through huge numbers of
extra requests on all servers they talked to, because of some server
that couldn't handle the more efficient case. IOW, clients care more
about limiting the branches in their code (maintainability) than
performance, in many cases.
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.
Lisa
Received on Friday, 9 July 2004 15:54:05 UTC