9303Re: The Ambiguous Semantics of PUT: Complete or Incomplete Representations
- Jul 1, 2007* Eric J. Bowman <eric@...> [2007-06-30 22:30]:
> Yes, I realize I'm easier to argue with, but please understandWhy are you assuming I’d take his word for gospel?
> that this isn't something I just made up.
> If your PATCH takes more bytes than it would to accomplish theIf it’s a full-monty PUT:
> same thing with PUT, then what is your reason for using PATCH?
A1. No need for ETag tracking and retry logic on the client in
a number of situations.
A2. Simpler *and* more expressive ETag semantics in cases where
they *are* needed.
If we’re talking about some kind of range-limited PUT (whether
by Content-Range or some URI-based range addressing mechanism):
B1. A single roundtrip regardless of how many aspects of the
resource need changing.
B2. Corollary to #B1 (and partially #A1): no need to invent
a transaction mechanism when consistent resource state is
And if we’re talking specifically about PUT+Content-Range:
B3. More consistent failure modes with regard to intermediaries.
All of these apply regardless of whether PATCH is saving on bytes
Aristotle Pagaltzis // <http://plasmasturm.org/>
- << Previous post in topic Next post in topic >>