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

Re: Resources always exist

Expand Messages
  • Paul Prescod
    ... The fact that there is potentially a divergence there is exactly my point. It s okay for HTTP to diverge but if the spec doesn t say clearly one way or
    Message 1 of 17 , Sep 18, 2002
    • 0 Attachment
      S. Mike Dierken wrote:
      > ----- Original Message -----
      > From: "Paul Prescod" <paul@...>
      >
      >>If you DELETE something twice, you usually expect an error message or a
      >>core dump.
      >
      > Do you mean 'delete' in the classic programming language sense (releasing
      > system memory, calling destructors, etc.) or do you mean the HTTP concept of
      > DELETE?

      The fact that there is potentially a divergence there is exactly my
      point. It's okay for HTTP to diverge but if the spec doesn't say clearly
      one way or another, then people will just guess. HTTP says basically
      "DELETE means you should delete."

      Roy describes a very mathematical mode for HTTP (resource is a mapping
      etc.) and if the HTTP methods were described in those terms it would be
      much easier to build interoperable software.

      There are hints that it was politics that prevented this from happening
      the first time around, but what should we do about it now? Just transmit
      the true meanings of the methods through mailing lists? Increment HTTP?
      Write an RFC clarifying? Wait for Roy's new protocol? I'm being serious
      here: I think that there is a problem and a variety of solutions and am
      soliciting opinions on both issues.

      Paul Prescod
    • Mathews, Walden
      Paul, If it hasn t already been done, I think it would be useful to at least formalize the possible interpretations of things like DELETE and anything else
      Message 2 of 17 , Sep 18, 2002
      • 0 Attachment
        Paul,

        If it hasn't already been done, I think it would be useful
        to at least formalize the possible interpretations of things
        like DELETE and anything else people find ambiguity in,
        separate from attempting to make any judgments about which
        interpretations are good and which are not.

        I keep threatening to build some Alloy models of parts of
        HTTP, and I'm getting very close to actually doing that. One
        thing is that I don't want to do it in isolation, so if you're
        interested in this approach, I say we just start with some
        informal language. Unfortunately, the message below is too
        ambiguous about the ambiguity in DELETE for me to get my
        teeth in.

        What do others think about this approach? I think Mark Baker
        proposed something like this, offering to author some new
        methods once we had a clear model. Let's do it, unless it's
        already been done and we'd be duplicating effort.

        I can pledge a genuine interest and *some* time, but can't
        commit to any schedule, unfortunately.

        Walden

        PS - shall I publish a simple Alloy model to this list
        tommorow to drive a stake into the ground?

        > -----Original Message-----
        > From: Paul Prescod [mailto:paul@...]
        > Sent: Wednesday, September 18, 2002 4:31 PM
        > To: S. Mike Dierken
        > Cc: Roy T. Fielding; rest-discuss
        > Subject: [rest-discuss] Re: Resources always exist
        >
        >
        > S. Mike Dierken wrote:
        > > ----- Original Message -----
        > > From: "Paul Prescod" <paul@...>
        > >
        > >>If you DELETE something twice, you usually expect an error
        > message or a
        > >>core dump.
        > >
        > > Do you mean 'delete' in the classic programming language
        > sense (releasing
        > > system memory, calling destructors, etc.) or do you mean
        > the HTTP concept of
        > > DELETE?
        >
        > The fact that there is potentially a divergence there is exactly my
        > point. It's okay for HTTP to diverge but if the spec doesn't
        > say clearly
        > one way or another, then people will just guess. HTTP says basically
        > "DELETE means you should delete."
        >
        > Roy describes a very mathematical mode for HTTP (resource is
        > a mapping
        > etc.) and if the HTTP methods were described in those terms
        > it would be
        > much easier to build interoperable software.
        >
        > There are hints that it was politics that prevented this from
        > happening
        > the first time around, but what should we do about it now?
        > Just transmit
        > the true meanings of the methods through mailing lists?
        > Increment HTTP?
        > Write an RFC clarifying? Wait for Roy's new protocol? I'm
        > being serious
        > here: I think that there is a problem and a variety of
        > solutions and am
        > soliciting opinions on both issues.
        >
        > Paul Prescod
        >
        >
        > ------------------------ Yahoo! Groups Sponsor
        > ---------------------~-->
        > 4 DVDs Free +s&p Join Now
        > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
        > --------------------------------------------------------------
        > -------~->
        >
        > To unsubscribe from this group, send an email to:
        > rest-discuss-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to
        http://docs.yahoo.com/info/terms/
      • Miles Sabin
        Mathews, Walden wrote, ... If it has, the results haven t been published anywhere to the best of my knowledge. ... Please do ... I, for one, would be very
        Message 3 of 17 , Sep 18, 2002
        • 0 Attachment
          Mathews, Walden wrote,
          > What do others think about this approach? I think Mark Baker
          > proposed something like this, offering to author some new
          > methods once we had a clear model. Let's do it, unless it's
          > already been done and we'd be duplicating effort.

          If it has, the results haven't been published anywhere to the best of my
          knowledge.

          > I can pledge a genuine interest and *some* time, but can't
          > commit to any schedule, unfortunately.
          >
          > Walden
          >
          > PS - shall I publish a simple Alloy model to this list
          > tommorow to drive a stake into the ground?

          Please do ... I, for one, would be very interested in taking a look at
          it.

          Cheers,


          Miles
        • inthedarkplace
          The simple fact is that there is no divergence. DELETE is idempotent and therefore deleting something once or deleting something a thousand times is the same
          Message 4 of 17 , Sep 18, 2002
          • 0 Attachment
            The simple fact is that there is no divergence. DELETE is idempotent
            and therefore deleting something once or deleting something a
            thousand times is the same operation. I'm not sure where people got
            the idea that there's something wrong with deleting something twice
            because that's never ever been true of HTTP and in fact most systems
            that expose a delete operation (eg databases, file systems, tuple
            spaces, g-indexes, maps). Further, there is no logical discontinuity
            between this behavior and the meaning of a delete request. I'm not
            sure why some people want to make this more complicated than it is,
            but I think it's clear to the majority.


            - itdp
            --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
            > S. Mike Dierken wrote:
            > > ----- Original Message -----
            > > From: "Paul Prescod" <paul@p...>
            > >
            > >>If you DELETE something twice, you usually expect an error
            message or a
            > >>core dump.
            > >
            > > Do you mean 'delete' in the classic programming language sense
            (releasing
            > > system memory, calling destructors, etc.) or do you mean the
            HTTP concept of
            > > DELETE?
            >
            > The fact that there is potentially a divergence there is exactly
            my
            > point. It's okay for HTTP to diverge but if the spec doesn't say
            clearly
            > one way or another, then people will just guess. HTTP says
            basically
            > "DELETE means you should delete."
            >
            > Roy describes a very mathematical mode for HTTP (resource is a
            mapping
            > etc.) and if the HTTP methods were described in those terms it
            would be
            > much easier to build interoperable software.
            >
            > There are hints that it was politics that prevented this from
            happening
            > the first time around, but what should we do about it now? Just
            transmit
            > the true meanings of the methods through mailing lists? Increment
            HTTP?
            > Write an RFC clarifying? Wait for Roy's new protocol? I'm being
            serious
            > here: I think that there is a problem and a variety of solutions
            and am
            > soliciting opinions on both issues.
            >
            > Paul Prescod
          • Miles Sabin
            inthedarkplace wrote, ... I think a lot turns on what s meant by something wrong with . To take one of your examples, files systems, $ touch foo $ rm foo $ rm
            Message 5 of 17 , Sep 18, 2002
            • 0 Attachment
              inthedarkplace wrote,
              > I'm not sure where people got the idea that there's something wrong
              > with deleting something twice because that's never ever been true of
              > HTTP and in fact most systems that expose a delete operation (eg
              > databases, file systems, tuple spaces, g-indexes, maps).

              I think a lot turns on what's meant by "something wrong with". To take
              one of your examples, files systems,

              $ touch foo
              $ rm foo
              $ rm foo
              rm: cannot remove `foo': No such file or directory
              $

              There's nothing "wrong" with this behaviour.

              rm is idempotent, but, nb., from the point of view of the effect on the
              filesystem, *not* from the point of view of the response displayed to
              the invoker,

              * WRT the filesystem, the effect of n+1 rm's is the same as the effect
              of n.

              * WRT the response displayed to the invoker, the effect of the first rm
              is different from the second and subsequent rm's.

              The gist of my earlier postings is that I believe that RFC 2616
              equivocates between a view of idempotence, similar to the one above,
              defined soley in terms of effects on servers/resources, and one that
              appeals to sameness of results as seen by the client. It's this
              equivocation which I think is wrong, not idempotent DELETEs.

              Cheers,


              Miles
            • Mathews, Walden
              ... I don t want to play any part in complicating things that are obvious. Still, that doesn t rule out modelling simple things about HTTP, because the
              Message 6 of 17 , Sep 19, 2002
              • 0 Attachment
                > -----Original Message-----
                > From: inthedarkplace [mailto:inthedarkplace@...]
                > Sent: Wednesday, September 18, 2002 5:40 PM
                > To: rest-discuss@yahoogroups.com
                > Subject: [rest-discuss] Re: Resources always exist
                >
                >
                > The simple fact is that there is no divergence. DELETE is idempotent
                > and therefore deleting something once or deleting something a
                > thousand times is the same operation. I'm not sure where people got
                > the idea that there's something wrong with deleting something twice
                > because that's never ever been true of HTTP and in fact most systems
                > that expose a delete operation (eg databases, file systems, tuple
                > spaces, g-indexes, maps). Further, there is no logical discontinuity
                > between this behavior and the meaning of a delete request. I'm not
                > sure why some people want to make this more complicated than it is,
                > but I think it's clear to the majority.
                >
                >
                > - itdp

                I don't want to play any part in complicating things that are
                obvious. Still, that doesn't rule out modelling simple things
                about HTTP, because the simpler models serve as the foundation
                for exploring some of the more complex and controversial issues.
                And also for reasoning correctly about extensions.

                Walden
              • Jeffrey Winter
                ... Ambiguity of the spec with regards to DELETE has been recognized for a while, e.g.: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0111.html
                Message 7 of 17 , Sep 19, 2002
                • 0 Attachment
                  > Paul Prescod wrote:
                  >
                  > I think that there is a problem and a variety of solutions and am
                  > soliciting opinions on both issues.

                  Ambiguity of the spec with regards to DELETE has been recognized
                  for a while, e.g.:

                  http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0111.html

                  I get the sense that some common understanding may have been achieved, but
                  if in fact there was one, this agreement is now folkloric and hasn't been
                  explicitly published anywhere.

                  If someone can clearly demonstrate how a reasonable interpretation of the
                  semantics of DELETE will lead to broken client-side code because of
                  inconsistent server-side implementations, it would seem important enough
                  that it should be addressed directly by the TAG, much like was done with
                  regards to GET:

                  http://www.w3.org/2001/tag/doc/get7

                  > Mathews, Walden wrote:
                  >
                  > shall I publish a simple Alloy model to this list
                  > tommorow to drive a stake into the ground?

                  I'd like to see it. It be a good way to bring the ambiguity into relief
                  and help to reinforce the importance of the problem if it does get presented
                  to the TAG.

                  - Winter
                • Mathews, Walden
                  ... Okay, so do I understand correctly that what we want to model is the DELETE operation in two variants: the first says that the resource- representation
                  Message 8 of 17 , Sep 19, 2002
                  • 0 Attachment
                    >
                    > > Mathews, Walden wrote:
                    > >
                    > > shall I publish a simple Alloy model to this list
                    > > tommorow to drive a stake into the ground?
                    >
                    > I'd like to see it. It be a good way to bring the ambiguity
                    > into relief
                    > and help to reinforce the importance of the problem if it
                    > does get presented
                    > to the TAG.
                    >
                    > - Winter


                    Okay, so do I understand correctly that what we want to model
                    is the DELETE operation in two variants: the first says that
                    the resource->representation mapping may be empty and DELETE is
                    still a valid method; the second says the a non-empty mapping
                    is a required pre-condition for DELETE.

                    Translated to response codes, the former says that if the
                    server honors DELETE, then the response code is always 200; the
                    second says that if the server honors DELETE but the resource
                    was unmapped before the delete, then in that case the response
                    is 404, else it's 200.

                    Do I correctly understand the modelling task here?

                    Walden

                    Is that the problem
                  • Jeffrey Winter
                    ... I believe that captures it. I m also left wondering: if subsequent DELETEs after an initial DELETE can return 200, does would imply that GET/HEAD should
                    Message 9 of 17 , Sep 19, 2002
                    • 0 Attachment
                      > Translated to response codes, the former says that if the
                      > server honors DELETE, then the response code is always 200; the
                      > second says that if the server honors DELETE but the resource
                      > was unmapped before the delete, then in that case the response
                      > is 404, else it's 200.
                      >
                      > Do I correctly understand the modelling task here?

                      I believe that captures it. I'm also left wondering: if subsequent
                      DELETEs after an initial DELETE can return 200, does would imply that
                      GET/HEAD should return 200/204 with an empty entity-body too? Perhaps
                      you could include that in your model also?
                    • Mathews, Walden
                      ... I ll include it if I understand it well enough. ;-) So you re saying that if the nth DELETE of some resource (with no intervening operations that could
                      Message 10 of 17 , Sep 19, 2002
                      • 0 Attachment
                        > -----Original Message-----
                        > From: Jeffrey Winter [mailto:j.winter@...]
                        > Sent: Thursday, September 19, 2002 1:34 PM
                        > To: Mathews, Walden; S. Mike Dierken; Paul Prescod
                        > Cc: rest-discuss
                        > Subject: Re: [rest-discuss] Re: Resources always exist
                        >
                        >
                        > > Translated to response codes, the former says that if the
                        > > server honors DELETE, then the response code is always 200; the
                        > > second says that if the server honors DELETE but the resource
                        > > was unmapped before the delete, then in that case the response
                        > > is 404, else it's 200.
                        > >
                        > > Do I correctly understand the modelling task here?
                        >
                        > I believe that captures it. I'm also left wondering: if subsequent
                        > DELETEs after an initial DELETE can return 200, does would imply that
                        > GET/HEAD should return 200/204 with an empty entity-body too? Perhaps
                        > you could include that in your model also?

                        I'll include it if I understand it well enough. ;-) So you're saying
                        that if the nth DELETE of some resource (with no intervening operations
                        that could restore representation mapping) can return 200 (i.e., "OK
                        it's not mapped"), then should a GET at this point (again, no intervening
                        operations to change state) also return 200 (i.e., "OK, the resource
                        is here because resources always exist) with an empty entity-body (i.e.,
                        "just because it exists doesn't mean it maps to any representations")?

                        That's a different kind of modeling problem, and I'm not sure modeling
                        will clarify anything. I believe the rule is that 404 means no
                        representation was found, while it's implicit that any resource that
                        ever existed still does.

                        Walden
                        >
                        >
                      • Jeffrey Winter
                        FWIW: I downloaded Slide, the Apache Jakarta WebDAV implementation. Insofar as this perhaps represents a reference implementation of an extension to the HTTP
                        Message 11 of 17 , Sep 19, 2002
                        • 0 Attachment
                          FWIW: I downloaded Slide, the Apache Jakarta WebDAV implementation.

                          Insofar as this perhaps represents a "reference" implementation
                          of an extension to the HTTP protocol, here's how it behaves:

                          Request: PUT /test.xml HTTP/1.1
                          Response: HTTP/1.1 201 Created

                          Request: GET /test.xml HTTP/1.1
                          Response: HTTP/1.1 200 OK

                          Request: DELETE /test.xml HTTP/1.1
                          Response: HTTP/1.1 204 No Content

                          Request: DELETE /test.xml HTTP/1.1
                          Response: HTTP/1.1 404 Not Found

                          Request: GET /test.xml HTTP/1.1
                          Response: HTTP/1.1 404 Not Found

                          Whether or not this represents some manifestation of the
                          "folkloric" understanding of the behavior of the ambiguous
                          DELETE specification I have no idea, but it of course certainly
                          makes intuitive sense. I think it was also what most people
                          would have expect the behavior to be - right up until Mark
                          Baker's hand-grenade of last week:

                          http://groups.yahoo.com/group/rest-discuss/message/2531

                          I'm not sure this really answers anything but it's an interesting
                          data point. Is Slide wrong?

                          - Winter
                        • S. Mike Dierken
                          ... From: Jeffrey Winter ... Neat - I didn t know there was one. ... I m seeing two viewpoints of what an http request is and they
                          Message 12 of 17 , Sep 19, 2002
                          • 0 Attachment
                            ----- Original Message -----
                            From: "Jeffrey Winter" <j.winter@...>



                            > FWIW: I downloaded Slide, the Apache Jakarta WebDAV implementation.
                            Neat - I didn't know there was one.

                            >
                            > Insofar as this perhaps represents a "reference" implementation
                            > of an extension to the HTTP protocol, here's how it behaves:

                            I'm seeing two viewpoints of what an 'http request' is and they each have
                            different expectations.
                            The first is 'please perform this operation upon this resource' - so a
                            DELETE on a non-existent resource fails.
                            The second is 'please make it such that the resource does not exist' - so a
                            DELETE on a non-existent resource is a 'duh - okay' response.

                            The first is more of a procedural point of view, and the second is more of a
                            declarative/logical assertion point of view. I don't know if that makes any
                            sense, but I hope the HTTP philosophy isn't the declarative/logical
                            assertion approach, since 0.001% of programmers would get it.
                          • firepipe_au
                            ... subsequent ... that ... Perhaps ... saying ... operations ... intervening ... (i.e., ... representations )? ... modeling ... Agreed there. The problem
                            Message 13 of 17 , Sep 19, 2002
                            • 0 Attachment
                              --- In rest-discuss@y..., "Mathews, Walden" <waldenm@i...> wrote:
                              >
                              >
                              > > -----Original Message-----
                              > > From: Jeffrey Winter [mailto:j.winter@n...]
                              > > Sent: Thursday, September 19, 2002 1:34 PM
                              > > To: Mathews, Walden; S. Mike Dierken; Paul Prescod
                              > > Cc: rest-discuss
                              > > Subject: Re: [rest-discuss] Re: Resources always exist
                              > >
                              > >
                              > > > Translated to response codes, the former says that if the
                              > > > server honors DELETE, then the response code is always 200; the
                              > > > second says that if the server honors DELETE but the resource
                              > > > was unmapped before the delete, then in that case the response
                              > > > is 404, else it's 200.
                              > > >
                              > > > Do I correctly understand the modelling task here?
                              > >
                              > > I believe that captures it. I'm also left wondering: if
                              subsequent
                              > > DELETEs after an initial DELETE can return 200, does would imply
                              that
                              > > GET/HEAD should return 200/204 with an empty entity-body too?
                              Perhaps
                              > > you could include that in your model also?
                              >
                              > I'll include it if I understand it well enough. ;-) So you're
                              saying
                              > that if the nth DELETE of some resource (with no intervening
                              operations
                              > that could restore representation mapping) can return 200 (i.e., "OK
                              > it's not mapped"), then should a GET at this point (again, no
                              intervening
                              > operations to change state) also return 200 (i.e., "OK, the resource
                              > is here because resources always exist) with an empty entity-body
                              (i.e.,
                              > "just because it exists doesn't mean it maps to any
                              representations")?
                              >
                              > That's a different kind of modeling problem, and I'm not sure
                              modeling
                              > will clarify anything. I believe the rule is that 404 means no
                              > representation was found, while it's implicit that any resource that
                              > ever existed still does.
                              >

                              Agreed there. The problem with DELETE does not apply for GET.

                              While RFC 2616 says that "the side-effects of N > 0 identical
                              requests is the same as for a single request", this is not the case
                              with DELETE, regardless of response codes, unless the representation
                              being deleted never existed (In which you can always return a 404 -
                              while not stated explicitly as legal in the spec in regards to
                              DELETE, it seems to be implied from other areas).

                              On the first DELETE, there is a side-effect - a representation is un-
                              mapped. On the second and subsequent DELETEs, there is no
                              representation to un-map, so the side effect /cannot/ take place. It
                              seems impossible to me to maintain idempotence across requests 1 and
                              2 with DELETE, and impossible not to (as far as effects on the server
                              go) on all requests > 1.

                              The problem with trying to prove that always (for requests > 0)
                              returning a 200 (duh) OK/202/204 response would break a client is
                              that the spec also states that it is not guaranteed that the intended
                              side-effect actually occurred (perhaps supervisor authorisation must
                              first be granted, for instance). To return a 404 is guaranteeing
                              that the side-effect did not take place; to return a 20X response is
                              more in keeping with the spec where no guarantees are given. However
                              in the 20X case the client can never be sure the request was
                              actioned, and your dream of a consistent interface flies out the
                              window.

                              Imagine if dialog boxes had "Yes", "No" and "Maybe" buttons...

                              As a client, I'd like to see a 404 telling my I'm stupid for trying
                              to delete something that didn't exist. At least then I can check for
                              typos. In which case, 2616 would have to be subject to a minor
                              alteration:

                              "the side-effects of N > 0 identical requests is the same as for a
                              single request [ except in the case of DELETE, where N > 1 ]"
                            • Paul Prescod
                              ... What s the problem? After one request the state of the universe is that the resource does not exist and/or is unmapped. After ten requests, the resource
                              Message 14 of 17 , Sep 19, 2002
                              • 0 Attachment
                                firepipe_au wrote:
                                > --- In rest-discuss@y..., "Mathews, Walden" <waldenm@i...> wrote:
                                >
                                >...

                                > While RFC 2616 says that "the side-effects of N > 0 identical
                                > requests is the same as for a single request", this is not the case
                                > with DELETE, regardless of response codes, unless the representation
                                > being deleted never existed (In which you can always return a 404 -
                                > while not stated explicitly as legal in the spec in regards to
                                > DELETE, it seems to be implied from other areas).
                                >
                                > On the first DELETE, there is a side-effect - a representation is un-
                                > mapped. On the second and subsequent DELETEs, there is no
                                > representation to un-map, so the side effect /cannot/ take place. It
                                > seems impossible to me to maintain idempotence across requests 1 and
                                > 2 with DELETE, and impossible not to (as far as effects on the server
                                > go) on all requests > 1.

                                What's the problem? After one request the state of the universe is that
                                the resource does not exist and/or is unmapped. After ten requests, the
                                resource does not exist and/or is unmapped. That's idempotence!

                                >...
                                > "the side-effects of N > 0 identical requests is the same as for a
                                > single request [ except in the case of DELETE, where N > 1 ]"

                                The *side effect* is the same. There is no resource. The response may be
                                different.

                                Paul Prescod
                              • Julian Reschke
                                ... Huh? The side effect for the single DELETE is that the URI mapping is removed. The side effect for N DELETEs (where N 1) is the same -- the URI mapping
                                Message 15 of 17 , Sep 20, 2002
                                • 0 Attachment
                                  > From: firepipe_au [mailto:michael@...]
                                  > Sent: Friday, September 20, 2002 3:37 AM
                                  > To: rest-discuss@yahoogroups.com
                                  > Subject: [rest-discuss] Re: Resources always exist
                                  >
                                  > ...
                                  >
                                  > Agreed there. The problem with DELETE does not apply for GET.
                                  >
                                  > While RFC 2616 says that "the side-effects of N > 0 identical
                                  > requests is the same as for a single request", this is not the case
                                  > with DELETE, regardless of response codes, unless the representation
                                  > being deleted never existed (In which you can always return a 404 -
                                  > while not stated explicitly as legal in the spec in regards to
                                  > DELETE, it seems to be implied from other areas).

                                  Huh? The side effect for the single DELETE is that the URI mapping is
                                  removed. The side effect for N DELETEs (where N > 1) is the same -- the URI
                                  mapping is removed. What's the problem here?

                                  > On the first DELETE, there is a side-effect - a representation is un-
                                  > mapped. On the second and subsequent DELETEs, there is no
                                  > representation to un-map, so the side effect /cannot/ take place. It

                                  It doesn't have to anymore.

                                  > ...

                                  Julian

                                  --
                                  <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
                                • Mathews, Walden
                                  ... I think a few more than that would get it , but I understand your point nonetheless. Sometimes the programmer doesn t matter as much as the customer. On
                                  Message 16 of 17 , Sep 24, 2002
                                  • 0 Attachment
                                    > I'm seeing two viewpoints of what an 'http request' is and
                                    > they each have
                                    > different expectations.
                                    > The first is 'please perform this operation upon this resource' - so a
                                    > DELETE on a non-existent resource fails.
                                    > The second is 'please make it such that the resource does not
                                    > exist' - so a
                                    > DELETE on a non-existent resource is a 'duh - okay' response.
                                    >
                                    > The first is more of a procedural point of view, and the
                                    > second is more of a
                                    > declarative/logical assertion point of view. I don't know if
                                    > that makes any
                                    > sense, but I hope the HTTP philosophy isn't the declarative/logical
                                    > assertion approach, since 0.001% of programmers would get it.

                                    I think a few more than that would "get it", but I understand
                                    your point nonetheless.

                                    Sometimes the programmer doesn't matter as much as the customer.
                                    On my current project, we have an issue that's right on this
                                    same point. Our customer wants to "update portfolios". Up until
                                    now we've assumed, because the implementation details include
                                    the storing of incremental transaction data for audit, that
                                    the end-user is thinking this way too, but recent evidence seems
                                    to suggest that they always think "declaratively" about their
                                    portfolios. An example, the broker is allowed to run one chart
                                    window, but branch management has decided that brokers would be
                                    happier running the maximum product capability of four chart
                                    windows. Four is the target; four is the meaningful number in
                                    the problem domain; "plus 3" is the language of the application.
                                    The programmers and programing management likes "plus 3"; they
                                    don't want to change...

                                    There's a problem with "plus 3"; in order to get every broker's
                                    config up to four, we need to know in a time-sensitive manner
                                    each broker's current config. This places a high burden on the
                                    freshness of the caches. If we order "plus 3" for a broker who
                                    was participating in a prototype and already has four, we're
                                    making an illegal request. We might spend extra bandwidth to
                                    refresh caches of all affected accounts in order to stick with
                                    this non-idempotent method of portfolio update; or we might go
                                    with the natural format that matches the way portfolio coordinators
                                    and management think and use the declarative (idempotent) method
                                    instead.

                                    Based on bandwidth constraints alone, a development management
                                    who refused to listen to "idempotent" in the abstract must now
                                    pay attention and entertain the necessity of this change.

                                    That's what's been happening in our little world. If programmers
                                    can't keep up with that kind of thinking, their futures are a bit
                                    dark from where I sit. It ain't rocket science either...

                                    Peace,
                                    Walden
                                  • Mathews, Walden
                                    Paul, Just cleaning out my inbox and I found this message from you. I had saved it because it hinted at the potential value of some mathematical models aimed
                                    Message 17 of 17 , Oct 15, 2002
                                    • 0 Attachment
                                      Paul,

                                      Just cleaning out my inbox and I found this message from you.
                                      I had saved it because it hinted at the potential value of some
                                      mathematical models aimed at clarifying HTTP method semantics.

                                      Since then, about a month has passed, during which time myself
                                      and a few others who read the rest-explore list have been
                                      experimenting with such models, and probably now have enough
                                      skill with one particular modeling language (Alloy) to be able
                                      to do what you suggest below, notably:

                                      "Roy describes a very mathematical mode for HTTP
                                      (resource is a mapping etc.) and if the HTTP methods
                                      were described in those terms it would be much easier
                                      to build interoperable software."

                                      I think, for one reason or another, we've gone off more in the
                                      direction of a pure REST model, rather than an HTTP model,
                                      probably mostly because those famous two sentences from Roy's
                                      thesis are about all we really have to go on...

                                      Could you please comment on this effort and your current
                                      thoughts about it. I have been unsuccessful to date in trying
                                      to interest Roy in the benefits of developing such models.
                                      That makes it harder to know what it is we're modeling, and
                                      on whose authority, but it's still possible to build a small
                                      set of models, each of which clarifies a particular interpretation
                                      of an HTTP method. If not authority, at least it might lend
                                      some clarity, especially if we can leverage graphical
                                      representations of the models as a more accessable form for
                                      general consumption. Perhaps the modeling effort converges
                                      on a small number of method usage patterns, which could then
                                      be named, and those names might become useful to applications
                                      that want to extend the HTTP contract?

                                      You haven't said anything about this since mid-September, so
                                      an update from you would be quite valuable, I think.

                                      Thanks,

                                      Walden

                                      > -----Original Message-----
                                      > From: Paul Prescod [mailto:paul@...]
                                      > Sent: Wednesday, September 18, 2002 4:31 PM
                                      > To: S. Mike Dierken
                                      > Cc: Roy T. Fielding; rest-discuss
                                      > Subject: [rest-discuss] Re: Resources always exist
                                      >
                                      >
                                      > S. Mike Dierken wrote:
                                      > > ----- Original Message -----
                                      > > From: "Paul Prescod" <paul@...>
                                      > >
                                      > >>If you DELETE something twice, you usually expect an error
                                      > message or a
                                      > >>core dump.
                                      > >
                                      > > Do you mean 'delete' in the classic programming language
                                      > sense (releasing
                                      > > system memory, calling destructors, etc.) or do you mean
                                      > the HTTP concept of
                                      > > DELETE?
                                      >
                                      > The fact that there is potentially a divergence there is exactly my
                                      > point. It's okay for HTTP to diverge but if the spec doesn't
                                      > say clearly
                                      > one way or another, then people will just guess. HTTP says basically
                                      > "DELETE means you should delete."
                                      >
                                      > Roy describes a very mathematical mode for HTTP (resource is
                                      > a mapping
                                      > etc.) and if the HTTP methods were described in those terms
                                      > it would be
                                      > much easier to build interoperable software.
                                      >
                                      > There are hints that it was politics that prevented this from
                                      > happening
                                      > the first time around, but what should we do about it now?
                                      > Just transmit
                                      > the true meanings of the methods through mailing lists?
                                      > Increment HTTP?
                                      > Write an RFC clarifying? Wait for Roy's new protocol? I'm
                                      > being serious
                                      > here: I think that there is a problem and a variety of
                                      > solutions and am
                                      > soliciting opinions on both issues.
                                      >
                                      > Paul Prescod
                                      >
                                      >
                                      > ------------------------ Yahoo! Groups Sponsor
                                      > ---------------------~-->
                                      > 4 DVDs Free +s&p Join Now
                                      > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
                                      > --------------------------------------------------------------
                                      > -------~->
                                      >
                                      > To unsubscribe from this group, send an email to:
                                      > rest-discuss-unsubscribe@yahoogroups.com
                                      >
                                      >
                                      >
                                      > Your use of Yahoo! Groups is subject to
                                      http://docs.yahoo.com/info/terms/
                                    Your message has been successfully submitted and would be delivered to recipients shortly.