Loading ...
Sorry, an error occurred while loading the content.

9303Re: The Ambiguous Semantics of PUT: Complete or Incomplete Representations

Expand Messages
  • A. Pagaltzis
    Jul 1, 2007
      * Eric J. Bowman <eric@...> [2007-06-30 22:30]:
      > Yes, I realize I'm easier to argue with, but please understand
      > that this isn't something I just made up.

      Why are you assuming I’d take his word for gospel?

      > If your PATCH takes more bytes than it would to accomplish the
      > same thing with PUT, then what is your reason for using PATCH?

      If it’s a full-monty PUT:

      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
      a requirement.

      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
      or not.

      Aristotle Pagaltzis // <http://plasmasturm.org/>
    • Show all 102 messages in this topic