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

diff + HTTP PATCH == wrong?

Expand Messages
  • Philippe Rathé
    Hi, does anyone sees applying a changeset to a resource as a complete replacement? I use to think that. I see devs blindly associating diff-like media with
    Message 1 of 9 , Jul 26, 2012
    • 0 Attachment
      Hi,

      does anyone sees applying a changeset to a resource as a complete
      replacement? I use to think that.

      I see devs blindly associating diff-like media with PATCH because of
      the largely popular diff/patch utility pair. IMO PUT should be use.
      Another reason is that diff resolution is a good candidate for
      idempotency.


      --
      Philippe
    • Steve Klabnik
      ... PUT requires a full replacement, which makes it not appropriate for a diff. (unless you have a resource that s a diff, eg,
      Message 2 of 9 , Jul 26, 2012
      • 0 Attachment
        Diff formats get used with patch because you are required to:

        > The PATCH method requests that a set of changes described in the
        > request entity be applied to the resource identified by the Request-
        > URI. The set of changes is represented in a format called a "patch
        > document" identified by a media type.

        > IMO PUT should be use.

        PUT requires a full replacement, which makes it not appropriate for a
        diff. (unless you have a resource that's a diff, eg,
        https://github.com/rails/rails/commit/b1d7283b2ac6763973e1a64475fc1c279cec8775.diff
      • Peter Williams
        ... PUT has replacement semantics, not fullness semantics. This is obviously the case because you don t have to provide each and every representation of a
        Message 3 of 9 , Jul 26, 2012
        • 0 Attachment
          On Thu, Jul 26, 2012 at 10:04 AM, Steve Klabnik <steve@...> wrote:
          > PUT requires a full replacement

          PUT has replacement semantics, not fullness semantics. This is
          obviously the case because you don't have to provide each and every
          representation of a resource. Further, the server may modify the
          provided representation in any way it sees fit before actually
          performing the replacement.

          This leaves us with the logical conclusion that PUT requests should
          include a complete enough representation to allow the server to
          construct all the representations it needs. Complete enough can only
          be defined by the server and/or the media type. So PUT has replace
          semantics, full stop. If the server can "replace" the existing
          representations with representations constructed from the
          representation in a particular PUT request it should do so.
          (Regardless of what anyone else thinks of the "fullness" of that
          representation.)

          Peter
          barelyenough.org
        • Julian Reschke
          ... ... Partial content updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource, or by
          Message 4 of 9 , Jul 26, 2012
          • 0 Attachment
            On 2012-07-26 17:44, Philippe Rathé wrote:
            > Hi,
            >
            > does anyone sees applying a changeset to a resource as a complete
            > replacement? I use to think that.
            >
            > I see devs blindly associating diff-like media with PATCH because of
            > the largely popular diff/patch utility pair. IMO PUT should be use.
            > Another reason is that diff resolution is a good candidate for
            > idempotency.
            > ...

            "... Partial content updates are possible by targeting a separately
            identified resource with state that overlaps a portion of the larger
            resource, or by using a different method that has been specifically
            defined for partial updates (for example, the PATCH method defined in
            [RFC5789])."

            --
            <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-20.html#rfc.section.2.3.5.p.10>

            Best regards, Julian
          • Philippe Rathé
            ... My point is that a diff entity if it contains an hyperlink to the original resource via let s say an original link relation can stand for a complete
            Message 5 of 9 , Jul 26, 2012
            • 0 Attachment
              On Thu, Jul 26, 2012 at 12:04 PM, Steve Klabnik <steve@...> wrote:
              > PUT requires a full replacement, which makes it not appropriate for a diff

              My point is that a diff entity if it contains an hyperlink to the
              original resource via let's say an "original" link relation can stand
              for a complete representation.

              Everything is there, e.g. the resource is represented by applicable
              content to an original representation (not necessarily the eventual
              PUT URI, nor the context URI). The instructions and content (the
              diff) media type and the "original" link relation would be registered.
              I did not meant the representation to only holds the applicable
              content without the "original" link relation. The URI of the
              "original" probably would most of the time be the same as the resource
              URI (PUT URI).

              So now with the link relation to the original resource, I don't see
              how a "diff" express as so can still be partial content? Quite compact
              yes. Different from the resource yes.

              Still disagree?

              --
              Philippe
            • Steve Klabnik
              ... http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-20#section-2.3.5 ... and ... See above.
              Message 6 of 9 , Jul 26, 2012
              • 0 Attachment
                > PUT has replacement semantics, not fullness semantics.

                From httpbis:

                > A successful PUT of a given
                > representation would suggest that a subsequent GET on that same
                > target resource will result in an equivalent representation being
                > returned in a 200 (OK) response.

                http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-20#section-2.3.5

                Now, the next sentence is interesting, too:

                > However, there is no guarantee that
                > such a state change will be observable, since the target resource
                > might be acted upon by other user agents in parallel, or might be
                > subject to dynamic processing by the origin server, before any
                > subsequent GET is received.

                and

                > still disagree with me?

                See above.
              • Philippe Rathé
                Hi Peter
                Message 7 of 9 , Jul 26, 2012
                • 0 Attachment
                  Hi Peter

                  On Thu, Jul 26, 2012 at 3:33 PM, Peter Williams <pezra@...> wrote: 

                  PUT has replacement semantics, not fullness semantics. This is
                  obviously the case because you don't have to provide each and every
                  representation of a resource. Further, the server may modify the
                  provided representation in any way it sees fit before actually
                  performing the replacement.

                   Awesome, that is illuminating. I agree.
                • mike amundsen
                  fullness semantics , Gracie ? mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me ... fullness semantics , Gracie ? mca
                  Message 8 of 9 , Jul 26, 2012
                  • 0 Attachment
                    "fullness semantics", Gracie<g>?


                    mca
                    http://amundsen.com/blog/
                    http://twitter.com@mamund
                    http://mamund.com/foaf.rdf#me




                    On Thu, Jul 26, 2012 at 10:47 PM, Philippe Rathé <prathe@...> wrote:


                    Hi Peter

                    On Thu, Jul 26, 2012 at 3:33 PM, Peter Williams <pezra@...> wrote: 

                    PUT has replacement semantics, not fullness semantics. This is
                    obviously the case because you don't have to provide each and every
                    representation of a resource. Further, the server may modify the
                    provided representation in any way it sees fit before actually
                    performing the replacement.

                     Awesome, that is illuminating. I agree.



                  • Peter Williams
                    ... Since we are certainly talking about application/domain semantic -- not syntactic -- equivalence, i assert that only the origin server and/or the media
                    Message 9 of 9 , Jul 26, 2012
                    • 0 Attachment
                      On Thu, Jul 26, 2012 at 5:01 PM, Steve Klabnik <steve@...> wrote:
                      > > PUT has replacement semantics, not fullness semantics.
                      >
                      > From httpbis:
                      >
                      >> A successful PUT of a given
                      >> representation would suggest that a subsequent GET on that same
                      >> target resource will result in an equivalent representation being
                      >> returned in a 200 (OK) response.

                      Since we are certainly talking about application/domain semantic --
                      not syntactic -- equivalence, i assert that only the origin server
                      and/or the media type can define equivalence of representations.
                      Therefore, *anything* the server wants to do is a-ok as long as it is
                      a) not actively disallowed by the media type and b) is idempotent from
                      the application perspective.

                      Peter
                      barelyenough.org
                    Your message has been successfully submitted and would be delivered to recipients shortly.