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

Re: [rest-discuss] More on versioned resources

Expand Messages
  • Julian Reschke
    ... Well, I personally think that a redirect here is the wrong approach. If only if user agents only may follow a redirect without user interaction if the
    Message 1 of 19 , Jan 2, 2007
    View Source
    • 0 Attachment
      Jan Algermissen schrieb:
      >
      > On Jan 2, 2007, at 4:00 PM, Julian Reschke wrote:
      >
      >>
      >>
      >> Well, all the problems go away if the resource *is* changed.
      >
      > The issue IMO is that the client needs no knowledge whatsoever about
      > versioning, it just understands PUT and the server uses plain HTTP
      > facilities (redirect) to guide the client. The client will work equally
      > with a non-versioning and a versioning server. In fact, the client
      > hardly cares if there are versions or not, it just wants the server to
      > 'store' what it sends.

      Well, I personally think that a redirect here is the wrong approach. If
      only if user agents only may follow a redirect without user interaction
      if the method is safe, which PUT is not (see
      <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.3>).

      Best regards, Julian
    • Julian Reschke
      ... But that is only the case when you have a server with autoversioning. PUT on a RFC3744-versioncontrolled resource is idempotent unless you do
      Message 2 of 19 , Jan 2, 2007
      View Source
      • 0 Attachment
        Alan Dean schrieb:
        >
        >
        > On 1/2/07, Julian Reschke <julian.reschke@ gmx.de
        > <mailto:julian.reschke%40gmx.de>> wrote:
        > > [snip] Can anybody please explain
        > > why it's so bad to just do what RFC3744 describes as "checkout-in- place"
        > > feature?
        >
        > Because it violates idempotency, see
        > http://www.w3 org/Protocols/ rfc2616/rfc2616- sec9.html# sec9.1.2
        > <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2>
        >
        > 'Silently' creating a new copy (on a public URI) as you suggest has a
        > side-effect (namely an increment of the publicly-visible version
        > number).

        But that is only the case when you have a server with autoversioning.
        PUT on a RFC3744-versioncontrolled resource is idempotent unless you do
        autoversioning.

        > However, if the request returns a redirect to the next version number
        > then the caller can elect not to follow the redirect if they choose
        > (or PUT repeatedly and idempotently onto the 'versioned' URI)

        If a PUT request returns a 3xx, a sane client will assume that the PUT
        has not been executed at all.

        > Of course, if the versioning is entirely private and not accessible to
        > callers, you can do whatever you like. Idempotency only refers to what
        > callers can see evidence of.
        >
        > Hope that helps,
        > Alan Dean

        Best regards, Julian
      • Roy T. Fielding
        ... *sigh* Just ignore the definition of idempotent in RFC 2616. Anything specified in HTTP that defines how the server shall implement the semantics of an
        Message 3 of 19 , Jan 2, 2007
        View Source
        • 0 Attachment
          On Jan 2, 2007, at 7:15 AM, Chris Burdess wrote:
          > Benjamin Carlyle wrote:
          > > If I PUT several times to <http://example.com/mydocument>, is it
          > > important to me that the <http://example.com/mydocument;1>,
          > > <http://example.com/mydocument;2>, and <http://example.com/
          > mydocument;3>
          > > resources are created? My operation has succeeded. Whatever else the
          > > server chooses to do with my submission is up to it. I don't see any
          > > need to redirect a client to a specific new document version in
          > order to
          > > allow their PUT operation to proceed.
          >
          > It does seem to be a bit of a bone of contention. If we assume that
          > /mydocument *does* change, i.e. that it is equivalent to
          > /mydocument;current or maybe /mydocument?revision=current , and always
          > reflects the state of the last change, then the PUT to /mydocument is
          > only idempotent with respect to /mydocument and not to the entire
          > namespace. This is a problem since RFC 2616 defines an idempotent
          > method
          > in terms of its side-effects not its direct effects, if you see what I
          > mean.

          *sigh*

          Just ignore the definition of idempotent in RFC 2616. Anything
          specified in HTTP that defines how the server shall implement the
          semantics of an interface method is wrong, by definition. What
          matters is the effect on the interface as expected by the client,
          not what actually happens on the server to implement that effect.

          ....Roy
        • Walden Mathews
          In 2616*, I interpret side effects to mean resource state changes, as opposed to values returned in the response. I think Chris is interpreting side
          Message 4 of 19 , Jan 2, 2007
          View Source
          • 0 Attachment
            In 2616*, I interpret "side effects" to mean resource state changes,
            as opposed to values returned in the response. I think Chris is
            interpreting
            "side effects" to mean changes to resources other than the target
            of the request. Is there any more to the issue than that? Or is my
            interpretation wrong?

            Walden

            * section 9.1.2 specifically

            ----- Original Message -----
            From: "Roy T. Fielding" <fielding@...>
            To: "Chris Burdess" <dog@...>
            Cc: "REST Discuss" <rest-discuss@yahoogroups.com>
            Sent: Tuesday, January 02, 2007 3:16 PM
            Subject: Re: [rest-discuss] More on versioned resources


            : On Jan 2, 2007, at 7:15 AM, Chris Burdess wrote:
            : > Benjamin Carlyle wrote:
            : > > If I PUT several times to <http://example.com/mydocument>, is it
            : > > important to me that the <http://example.com/mydocument;1>,
            : > > <http://example.com/mydocument;2>, and <http://example.com/
            : > mydocument;3>
            : > > resources are created? My operation has succeeded. Whatever else the
            : > > server chooses to do with my submission is up to it. I don't see any
            : > > need to redirect a client to a specific new document version in
            : > order to
            : > > allow their PUT operation to proceed.
            : >
            : > It does seem to be a bit of a bone of contention. If we assume that
            : > /mydocument *does* change, i.e. that it is equivalent to
            : > /mydocument;current or maybe /mydocument?revision=current , and always
            : > reflects the state of the last change, then the PUT to /mydocument is
            : > only idempotent with respect to /mydocument and not to the entire
            : > namespace. This is a problem since RFC 2616 defines an idempotent
            : > method
            : > in terms of its side-effects not its direct effects, if you see what I
            : > mean.
            :
            : *sigh*
            :
            : Just ignore the definition of idempotent in RFC 2616. Anything
            : specified in HTTP that defines how the server shall implement the
            : semantics of an interface method is wrong, by definition. What
            : matters is the effect on the interface as expected by the client,
            : not what actually happens on the server to implement that effect.
            :
            : ....Roy
            :
            :
            :
            : __________ NOD32 1953 (20070102) Information __________
            :
            : This message was checked by NOD32 antivirus system.
            : http://www.eset.com
            :
            :
          • Mark Baker
            I think the answer you re looking for is found in the explanation often given about GET and side-effects; that the client didn t request them and so can t be
            Message 5 of 19 , Jan 2, 2007
            View Source
            • 0 Attachment
              I think the answer you're looking for is found in the explanation
              often given about GET and side-effects; that the client didn't request
              them and so can't be held accountable. Similarly, from the POV of
              this thread, if a server non-idempotently "versions" a resource on a
              PUT, the client isn't requesting that action, the server just decided
              to do it, and therefore it's not a violation of PUT semantics ... as
              long as the server also sets the state of the targetted resource to
              that represented in the request, of course.

              I've understood this distinction for some time, but it still catches
              me on occasion...

              Mark.

              On 1/2/07, Walden Mathews <waldenm@...> wrote:
              > In 2616*, I interpret "side effects" to mean resource state changes,
              > as opposed to values returned in the response. I think Chris is
              > interpreting
              > "side effects" to mean changes to resources other than the target
              > of the request. Is there any more to the issue than that? Or is my
              > interpretation wrong?
              >
              > Walden
              >
              > * section 9.1.2 specifically
              >
              > ----- Original Message -----
              > From: "Roy T. Fielding" <fielding@...>
              > To: "Chris Burdess" <dog@...>
              > Cc: "REST Discuss" <rest-discuss@yahoogroups.com>
              > Sent: Tuesday, January 02, 2007 3:16 PM
              > Subject: Re: [rest-discuss] More on versioned resources
              >
              >
              > : On Jan 2, 2007, at 7:15 AM, Chris Burdess wrote:
              > : > Benjamin Carlyle wrote:
              > : > > If I PUT several times to <http://example.com/mydocument>, is it
              > : > > important to me that the <http://example.com/mydocument;1>,
              > : > > <http://example.com/mydocument;2>, and <http://example.com/
              > : > mydocument;3>
              > : > > resources are created? My operation has succeeded. Whatever else the
              > : > > server chooses to do with my submission is up to it. I don't see any
              > : > > need to redirect a client to a specific new document version in
              > : > order to
              > : > > allow their PUT operation to proceed.
              > : >
              > : > It does seem to be a bit of a bone of contention. If we assume that
              > : > /mydocument *does* change, i.e. that it is equivalent to
              > : > /mydocument;current or maybe /mydocument?revision=current , and always
              > : > reflects the state of the last change, then the PUT to /mydocument is
              > : > only idempotent with respect to /mydocument and not to the entire
              > : > namespace. This is a problem since RFC 2616 defines an idempotent
              > : > method
              > : > in terms of its side-effects not its direct effects, if you see what I
              > : > mean.
              > :
              > : *sigh*
              > :
              > : Just ignore the definition of idempotent in RFC 2616. Anything
              > : specified in HTTP that defines how the server shall implement the
              > : semantics of an interface method is wrong, by definition. What
              > : matters is the effect on the interface as expected by the client,
              > : not what actually happens on the server to implement that effect.
              > :
              > : ....Roy
              > :
              > :
              > :
              > : __________ NOD32 1953 (20070102) Information __________
              > :
              > : This message was checked by NOD32 antivirus system.
              > : http://www.eset.com
              > :
              > :
              >
              >
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
              >


              --
              Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
              Coactus; Web-inspired integration strategies http://www.coactus.com
            • Roy T. Fielding
              ... Yes, that s it. We have to keep dancing around that bush because terminology is a committee-driven process. Everyone has an opinion and so no opinion is
              Message 6 of 19 , Jan 2, 2007
              View Source
              • 0 Attachment
                On Jan 2, 2007, at 4:42 PM, Mark Baker wrote:
                > I think the answer you're looking for is found in the explanation
                > often given about GET and side-effects; that the client didn't request
                > them and so can't be held accountable. Similarly, from the POV of
                > this thread, if a server non-idempotently "versions" a resource on a
                > PUT, the client isn't requesting that action, the server just decided
                > to do it, and therefore it's not a violation of PUT semantics ... as
                > long as the server also sets the state of the targetted resource to
                > that represented in the request, of course.
                >
                > I've understood this distinction for some time, but it still catches
                > me on occasion...

                Yes, that's it. We have to keep dancing around that bush because
                terminology is a committee-driven process. Everyone has an opinion
                and so no opinion is spec'd consistently.

                ....Roy
              • Andrzej Jan Taramina
                ... That about sums it up. ;-) ... and ... Reminds me of a post I read the other day on Why Specs Matter , with an amusing binary taxonomy of developers,
                Message 7 of 19 , Jan 4, 2007
                View Source
                • 0 Attachment
                  Roy said:

                  > *sigh*

                  That about sums it up. ;-)

                  > Just ignore the definition of idempotent in RFC 2616. Anything
                  > specified in HTTP that defines how the server shall implement the
                  > semantics of an interface method is wrong, by definition. What
                  > matters is the effect on the interface as expected by the client,
                  > not what actually happens on the server to implement that effect.

                  and

                  > We have to keep dancing around that bush because
                  > terminology is a committee-driven process. Everyone has an opinion
                  > and so no opinion is spec'd consistently.

                  Reminds me of a post I read the other day on "Why Specs Matter", with an
                  amusing binary taxonomy of developers, which lends some insight into why this
                  might be the case.

                  Found here:

                  http://diveintomark.org/archives/2004/08/16/specs

                  Enjoy!


                  Andrzej Jan Taramina
                  Chaeron Corporation: Enterprise System Solutions
                  http://www.chaeron.com
                • Alan Dean
                  ... More recently, from the same blog: http://diveintomark.org/archives/2006/12/07/rest-for-toddlers ... Alan Dean
                  Message 8 of 19 , Jan 4, 2007
                  View Source
                  • 0 Attachment
                    On 1/4/07, Andrzej Jan Taramina <andrzej@...> wrote:
                    > Reminds me of a post I read the other day on "Why Specs Matter", with an
                    > amusing binary taxonomy of developers, which lends some insight into why this
                    > might be the case.
                    >
                    > Found here:
                    >
                    > http://diveintomark.org/archives/2004/08/16/specs

                    More recently, from the same blog:

                    http://diveintomark.org/archives/2006/12/07/rest-for-toddlers

                    :-)
                    Alan Dean
                  Your message has been successfully submitted and would be delivered to recipients shortly.