Re: The Ambiguous Semantics of PUT: Complete or Incomplete Representations
>Quoting Dr. Fielding once more, if you don't like what I say about PATCH
>>>* Julian Reschke <julian.reschke@...> [2007-06-30 09:30]:
>>> Eric J. Bowman wrote:
>>> But the overriding purpose of PATCH is to save bytes over
>>> using PUT. If
>> It may be the overriding one for you, but that's not
>> necessarily the case for everybody.
>I donâ€™t even see how it would save bytes, actually. That wasnâ€™t
>what I consider PATCH to be good for at all.
saving bytes, then take it up with him because I'm saying exactly the
>Yes, I realize I'm easier to argue with, but please understand that this
>PATCH has very specific semantics and a very specific
>goal of reducing bits on updates.
isn't something I just made up. "...very specific goal of reducing bits
on updates..." is very, very unambiguous. If your PATCH takes more bytes
than it would to accomplish the same thing with PUT, then what is your
reason for using PATCH?
- * Stian Soiland <ssoiland@...> [2007-07-04 15:05]:
> What about PUTing with the Content-Type: multipart/byterangesIf the server accepts any MIME type for the resource at that URI,
> ? If the server don't understand multipart/byteranges, it
> will say 406 Not Acceptable.
then it will try to store the patch as the content of the
resource. If arbitrary media types are not acceptable, the PUT
will probably be rejected. That’s what PUT means.
> It has already been agreed that since all representationsSure, but it’s a red herring here. The fact that a client can’t
> are/can be partial on GET, so would representations that are
> uploaded with PUT often be partial.
fill in all aspects of the resource with a single representation
doesn’t mean that it *intends* the missing aspects to be filled
in from the previous state of the resource; it merely gives the
server licence to fill them in appropriately, probably by setting
them to some default state, although deriving from some previous
state of the resource is also legal.
The difference between PUT and PATCH is that with the latter, the
client is explicitly requesting that the previous state of the
resource be taken into account, and that the entity body it sends
is not a (possible) rendition of the resource, but a rendition of
the differences between the previous state of the resource and
the intended new state.
Aristotle Pagaltzis // <http://plasmasturm.org/>