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

Re: [rest-discuss] REST clarifications...

Expand Messages
  • Roy T. Fielding
    ... Josh, while that may be your theory (and you are welcome to it), the notion that there are two levels of REST is completely false. There are different
    Message 1 of 25 , Dec 28, 2004
    • 0 Attachment
      On Dec 28, 2004, at 3:18 PM, Josh Sled wrote:
      > It's hard to say generally, but I think you're seeing two different
      > things:
      >
      > * an inherent similarity in the two methods, including a bit of a
      > semantic overlap with respect to PUT's specification of ability to
      > create things.
      >
      > * the fact that there's two different levels of REST:
      > GET+POST-does-everything-else vs. GET/PUT/POST/DELETE. Not
      > differentiating the two can lead to confusion about which "POST"
      > is being used/described. [1]
      ...
      > [1]:
      > http://asynchronous.org/blog/archives/2004/08/25/levels_of_rest.html

      Josh, while that may be your theory (and you are welcome to it), the
      notion that there are two levels of REST is completely false. There
      are different extents to which a REST-based application will use HTTP
      methods, but that doesn't mean the architectural style has two different
      sets of constraints. The application is either obeying the REST
      constraints or it is not, and POST in particular has the meaning
      "process this" regardless of how REST-compliant it may be because
      REST does not define the meaning of POST (HTTP does).

      ....Roy
    • S. Mike Dierken
      ... When using PUT, the client application knows and identifies the resource that is to be replaced by the content in the request. Whether the server creates
      Message 2 of 25 , Dec 28, 2004
      • 0 Attachment
        > 1) Some material on REST seems to reserve POST for "create" and PUT
        > for "update" while others seem to blur the distinction. Any insight
        > here would be most helpful.
        When using PUT, the client application knows and identifies the resource
        that is to be replaced by the content in the request. Whether the server
        creates or updates a resource is immaterial - after the request succeeds,
        the identified resource simply just has the specified state.
        When using POST, the server is in control of whether the resource specified
        in the request is modified or whether a new resource is created - and the
        client can't guess at what the ID of new resource might be, it needs to be
        provided by the server in the response. If the response fails to arrive at
        the client, it might not be safe for the client application to simply
        re-submit the request.


        >
        > 2) The writings seem to direct one away from using the query string as
        > much as possible. While it is clear that .../somecgi.pl?action=delete
        > is most unREST-ful I assume
        One reason this is unsafe is that a client that does a GET on that resource
        will cause the resource to suddenly disappear. You often see this in email
        confirmation messages that have a 'click here to unsubscribe' or something.
        An email user agent that automatically fetched the links in an email would
        silently cause actions to happen that you didn't intend (and are not liable
        for).

        > 4) I'm unclear as how a PUT works. If we take PUT to mean "update"
        > the resource, does one simply send the updated representation of the
        > resource in a PUT request to the server?
        The meaning of PUT is more similar to an UPSERT (update or insert) operation
        supported by some RDBMS systems.
        The client application does indeed simply send a representation of the new
        state of the resource.
      • S. Mike Dierken
        ... When using PUT, the client is in control of the URI space. So take any PUT enabled file-system based Web server (like Apache) and it becomes a dumb
        Message 3 of 25 , Dec 28, 2004
        • 0 Attachment
          > > 1) Some material on REST seems to reserve POST for "create" and PUT
          > > for "update" while others seem to blur the distinction. Any insight
          > > here would be most helpful.
          >
          > I haven't found a reason to use PUT rather than POST
          > for creating a new resource. I'm still waiting for
          > the killer example where it makes sense.
          When using PUT, the client is in control of the URI space. So take any PUT
          enabled file-system based Web server (like Apache) and it becomes a 'dumb
          server', and the smarts can move into the client application - intelligence
          at the edge. Example apps could be shared music playlists (requires music
          players like iTunes, musicmatch, winamp to be more than brain dead
          embarassments to the software development community - support caching of
          http resources rather than re-fetching, support 'save to the web' for
          playlists, etc..)
          Other examples may come out of the rich client work popping up in
          applications like GMail.

          > Using PUT to create a resource is like using UPDATE
          > in SQL to create a new row.
          Using PUT is more like using UPSERT. Also, new rows are created via the
          INSERT statement, UPDATE doesn't create new rows (although I'm only speaking
          from limited experience in the world of SQL). The UPSERT operation is only
          supported in a few SQL systeems, I'm pretty sure MySQL supports it (but the
          table needs to have a uniqueness constraint on the primary key).
        • Josh Sled
          ... No, you re right; I ve made the mistake of conflating REST with HTTP. ... As per HTTP, POST has two meanings ... submit data-block for data-handling as
          Message 4 of 25 , Dec 29, 2004
          • 0 Attachment
            On Tue, 2004-12-28 at 21:38, Roy T.Fielding wrote:

            > Josh, while that may be your theory (and you are welcome to it), the
            > notion that there are two levels of REST is completely false. There
            > are different extents to which a REST-based application will use HTTP
            > methods, but that doesn't mean the architectural style has two different
            > sets of constraints.

            No, you're right; I've made the mistake of conflating REST with HTTP.


            > The application is either obeying the REST
            > constraints or it is not, and POST in particular has the meaning
            > "process this" regardless of how REST-compliant it may be because
            > REST does not define the meaning of POST (HTTP does).

            As per HTTP, POST has two meanings ... "submit data-block for
            data-handling" as well as "resource {creation,annotation,extension}".
            These represent very different designs; I still think it's critical to
            distinguish the two. But, yes, they're "levels of HTTP", not "levels of
            REST".

            ...jsled

            --
            http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
          • Walden Mathews
            Josh, ... POST can t have two meanings per the spec., because the spec does not define a way to discriminate two meanings for POST. Or do I fail to get your
            Message 5 of 25 , Dec 29, 2004
            • 0 Attachment
              Josh,

              | As per HTTP, POST has two meanings ... "submit data-block for
              | data-handling" as well as "resource {creation,annotation,extension}".
              | These represent very different designs; I still think it's critical to
              | distinguish the two. But, yes, they're "levels of HTTP", not "levels of
              | REST".

              POST can't have two meanings per the spec., because the spec
              does not define a way to discriminate two meanings for POST.
              Or do I fail to get your meaning?

              My understanding is that POST has *one* meaning, and potentially
              infinite consequences, depending on server whim. Such is the
              nature of implicit invoation.

              Walden
            • Roy T. Fielding
              ... Yes, it was certainly a mistake when the NCSA team introduced HTML forms processing via POST (which at the time meant the same as NNTP s post) without
              Message 6 of 25 , Dec 29, 2004
              • 0 Attachment
                On Dec 29, 2004, at 6:47 AM, Josh Sled wrote:
                > As per HTTP, POST has two meanings ... "submit data-block for
                > data-handling" as well as "resource {creation,annotation,extension}".
                > These represent very different designs; I still think it's critical to
                > distinguish the two. But, yes, they're "levels of HTTP", not "levels
                > of
                > REST".

                Yes, it was certainly a mistake when the NCSA team introduced HTML
                forms processing via POST (which at the time meant the same as NNTP's
                post)
                without introducing a distinctive method for "process this". However,
                we
                should also understand why it did not seem important at the time, and
                also why it "just doesn't matter" to REST how many meanings are embodied
                in HTTP's POST.

                visible identifiable
                method safe idempotent semantics resource cacheable
                -----------------------------------------------------------
                GET | X X X X X |
                HEAD | X X X X X |
                PUT | X X X |
                POST(a) | / |
                POST(p) | |
                OPTIONS | X X X O |
                -----------------------------------------------------------

                POST(a), as "append this", is unsafe, non-idempotent, non-cacheable,
                operates on an unknown resource, and has only minor visibility since
                there is no way for an intermediary to anticipate the state of the
                resource after the append aside from "some state was added". POST(p),
                as "process this", doesn't even have that minor visibility. Thus, an
                architectural style like REST can only improve the performance of a
                POST-based architecture by finding ways to escape POST (e.g., 201).

                Note that POST, regardless of which meaning is being used, has none of
                the characteristics that would make it useful for the architecture to
                know exactly what is going on. At most, we can obtain an identifiable
                resource if the response is 201 and Content-Location, but that is true
                of any extension method. That is why it is more efficient in a true
                REST-based architecture for there to be a hundred different methods
                with distinct (non-duplicating), universal semantics, than it is to
                include method semantics within the body of a POST. Inspecting message
                bodies to determine message semantics will always be slower than
                placing the method up front.

                I really should extend the table to include all of the methods that
                webdav has added, just to show how disastrous it was to create PROP*
                (duplicating semantics) instead of linking to the set of properties
                as a separate resource. Maybe someone else has time to add that to the
                wiki.

                ....Roy
              • S. Mike Dierken
                ... I added the table to this wiki page, but no summary or descriptive text. I also added DELETE, and another section for WebDAV methods.
                Message 7 of 25 , Dec 29, 2004
                • 0 Attachment
                  > I really should extend the table to include all of the methods that
                  > webdav has added, just to show how disastrous it was to create PROP*
                  > (duplicating semantics) instead of linking to the set of properties
                  > as a separate resource. Maybe someone else has time to add that to the
                  > wiki.

                  I added the table to this wiki page, but no summary or descriptive text.
                  I also added DELETE, and another section for WebDAV methods.
                  http://rest.blueoxen.net/cgi-bin/wiki.pl?HttpMethods


                  visible identifiable
                  method safe idempotent semantics resource cacheable
                  -----------------------------------------------------------
                  GET | X X X X X |
                  HEAD | X X X X X |
                  PUT | X X X |
                  POST(a) | / |
                  POST(p) | |
                  DELETE | X X X |
                  OPTIONS | X X X O |
                  -----------------------------------------------------------
                  PROPFIND | |
                  PROPPATCH | |
                  MKCOL | |
                  COPY | |
                  MOVE | |
                  LOCK | |
                  UNLOCK | |
                  -----------------------------------------------------------
                • Vincent D Murphy
                  Thanks for the clarification. I have two questions. ... Do you agree that it would be better if human user agents sending HTML forms just put the contents of
                  Message 8 of 25 , Dec 30, 2004
                  • 0 Attachment
                    Thanks for the clarification. I have two questions.

                    Roy T. Fielding wrote:
                    > That is why it is more efficient in a true
                    > REST-based architecture for there to be a hundred different methods
                    > with distinct (non-duplicating), universal semantics, than it is to
                    > include method semantics within the body of a POST. Inspecting message
                    > bodies to determine message semantics will always be slower than
                    > placing the method up front.

                    Do you agree that it would be better if human user agents
                    sending HTML forms just put the contents of the <form method="">
                    attribute in the HTTP method field, no matter what the value is?

                    That way the server can honour the method or return an error, and
                    there is no more subsetting HTTP; you can use PUT or whatever you
                    like in your HTML form.

                    > I really should extend the table to include all of the methods that
                    > webdav has added, just to show how disastrous it was to create PROP*
                    > (duplicating semantics) instead of linking to the set of properties
                    > as a separate resource. Maybe someone else has time to add that to the
                    > wiki.

                    It comes as news to me that PROP* is disastrous. I studied
                    WebDAV this week and thought exactly the same thing; these
                    properties could be in a representation, or a seperate
                    subordinate resource.

                    Do you have this opinion about any of the other methods in
                    WebDAV, such as LOCK, UNLOCK, MKCOL? I wondered why one
                    couldn't just create a lock or collection with POST. I asked
                    how to do Wiki rollback with REST/HTTP here a while back
                    (lots of Wiki software uses GET with a verb in the URL) and
                    one of the suggestions was to use WebDAV COPY and MOVE.

                    I think I'm having difficulty making a value judgement as to
                    when one needs a new method in the protocol versus a new
                    resource.

                    =vdm
                  • Josh Sled
                    ... Every time I read RFC 2616 section 9.5, I come away with two meanings: * process data * subordinate [...] in the same way that a file is subordinate to a
                    Message 9 of 25 , Dec 30, 2004
                    • 0 Attachment
                      On Wed, 2004-12-29 at 11:21, Walden Mathews wrote:
                      > Josh,
                      >
                      > | As per HTTP, POST has two meanings ... "submit data-block for
                      > | data-handling" as well as "resource {creation,annotation,extension}".
                      > | These represent very different designs; I still think it's critical to
                      > | distinguish the two. But, yes, they're "levels of HTTP", not "levels of
                      > | REST".
                      >
                      > POST can't have two meanings per the spec., because the spec
                      > does not define a way to discriminate two meanings for POST.
                      > Or do I fail to get your meaning?

                      Every time I read RFC 2616 section 9.5, I come away with two meanings:

                      * process data

                      * "subordinate [...] in the same way that a file is subordinate to
                      a directory containing it [...]".

                      The latter reading is reinforced when taken in combination with the
                      definition of the semantics of the PUT and DELETE methods.

                      But, no, there's no way within the protocol to discriminate between them
                      [and there doesn't really need to be since the server is in control of
                      the conversation, which is really important].

                      POST then must have "process message" semantic, which subsumes "create
                      subordinate resource". But there are clearly two different senses [in
                      the wordnet ... uh ... sense] at play in the wording of the spec.

                      [And to be clear, my use of "distinguish" in the quoted text was more
                      about person/person communication, not client/server...]


                      > My understanding is that POST has *one* meaning, and potentially
                      > infinite consequences, depending on server whim. Such is the
                      > nature of implicit invoation.

                      For some reason I like it better when it has a constrained meaning
                      rather than an unconstrained one. But it is the unconstrained meaning
                      is what has enabled the web to grow, and I like that. So now I'm
                      confused. :)


                      In any case, I maintain that there are different levels of HTTP:

                      0/ POST
                      1/ POST+GET
                      2/ POST+GET+PUT+DELETE(+HEAD,OPTIONS,TRACE,CONNECT)
                      3/ HTTP + WebDAV [RFC 2518]
                      ...


                      So a question is: is (0) RESTful?

                      In the beginning there was POST. I can see how GET would be factored
                      out of POST, specifically for optimizations of safety and
                      cache-control. PUT and DELETE could be further factored out, but as
                      experience shows: not to great benefit. The extensions specified in
                      WebDAV are [perhaps] further factored out in order to gain particular
                      operational efficiencies and capabilities...

                      I'm really just trying to understand better what "uniform" and
                      "hypermedia as the engine of application state" means, especially as
                      constrasted with RPC.

                      Section 5.1.5 of the dissertation claims that the Uniform Interface
                      constraint is the key differentiator of REST to other network-based
                      styles... but when we allow the possibility that POST has multiple
                      meanings and a very loose semantic, it seems to chip away at that
                      uniformity.

                      At what point does the interface become non-uniform?

                      Is it strictly a function of what method-support-packages [?] are built
                      into the client?

                      And is there something besides uniformity -- the notion that each method
                      has the same semantic between any pair of components -- that is
                      important? If we only had the uniform-though-weak POST operation, the
                      web wouldn't have the same character as it does now, but it would still
                      be uniform. Is the GET/POST distinction critical? [I'm _certain_ it
                      is, but why, exactly? Is it operational "safe"ness? Idempotency?
                      Both?]

                      Let's say that the client receives from the server -- via a uniform and
                      interface like HTTP -- sufficient information which is unique to that
                      particular server, which allows the client to formulate a sequence of
                      method-invocations which carry out some task. In terms of RESTfulness,
                      does it matter if the methods in the elements of that sequence are of a
                      limited set [the HTTP verbs, for instance]? (potential answer: yes,
                      because of the visibility/known-semantics of those operations.)

                      And if not ... what about a client that gets such server-interaction
                      information from a third-party registry rather than the server itself at
                      run-time?

                      Or are all cases non-RESTful not because of the lack of uniform
                      interface, but because hypermedia has stopped becoming the engine of
                      application state...?

                      Is the violation of REST that the client proactively performs more than
                      one action without the server's direction?

                      What about a client which understands how to perform long sequences of
                      interaction with a server, but periodically utilizes the server's
                      responses as a rough guide to application state?

                      Does it matter if the server provides the client with code[-on-demand]
                      -- a javascript "ui-engine" for instance -- that formulates and calls
                      the non-uniform methods [or, calls the existing "uniform" methods in
                      non-uniform ways]?


                      [I've re-edited this message for far too long, now, so I send it with
                      the disclaimer that I'm well-aware the preceding paragraphs are
                      less-than-coherent. If you've even read this far, thanks.]

                      ...jsled

                      --
                      http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
                    • Josh Sled
                      ... [deletia] ... I continue to be confused, though. I understand the importance of orthogonality of operations [generally], but there s a tension here
                      Message 10 of 25 , Dec 30, 2004
                      • 0 Attachment
                        On Wed, 2004-12-29 at 21:28, Roy T. Fielding wrote:

                        > That is why it is more efficient in a true
                        > REST-based architecture for there to be a hundred different methods
                        > with distinct (non-duplicating), universal semantics, than it is to
                        > include method semantics within the body of a POST. Inspecting message
                        [deletia]
                        > I really should extend the table to include all of the methods that
                        > webdav has added, just to show how disastrous it was to create PROP*
                        > (duplicating semantics) instead of linking to the set of properties

                        I continue to be confused, though. I understand the importance of
                        orthogonality of operations [generally], but there's a tension here
                        between "hundreds of methods" and "there's no need for new methods
                        [since everything can be done in the resource-space]", which has been
                        expressed both in this forum and in other REST resources...


                        What's a good example of a new method that's not "disasterous"?


                        I'm familiar with the notion of M{GET,PUT,DELETE} operations from URIQA,
                        but have never really understood why conneg and resources aren't
                        sufficient; the Waka slides also suggest a seperation of data from
                        metadata, but maybe have a different definition of the later [?].

                        I've seen the WebDAV spec, and it sure seems like some of it could be
                        moved into the media-type rather than the protocol [<dav:lock
                        using="post" href="./createLockRelUrl" />, &c.].

                        The recent queue discussion seems to propose an atomic GET+DELETE
                        operation [MarkB's referred to it as "TAKE", but that name's from some
                        other system [?]], though I still believe that a sequence of GET + POST
                        [+ DELETE] can be used to craft a multi-consumer synchronized queue
                        [resistent to transient communication failures, at least].

                        ...jsled

                        --
                        http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
                      • Julian Reschke
                        ... OK, I have filled out what I think the properties of the WebDAV methods are (feedback appreciated): method safe idempotent semantics resource
                        Message 11 of 25 , Dec 30, 2004
                        • 0 Attachment
                          S. Mike Dierken wrote:
                          >>I really should extend the table to include all of the methods that
                          >>webdav has added, just to show how disastrous it was to create PROP*
                          >>(duplicating semantics) instead of linking to the set of properties
                          >>as a separate resource. Maybe someone else has time to add that to the
                          >>wiki.
                          >
                          >
                          > I added the table to this wiki page, but no summary or descriptive text.
                          > I also added DELETE, and another section for WebDAV methods.
                          > http://rest.blueoxen.net/cgi-bin/wiki.pl?HttpMethods
                          > ...

                          OK, I have filled out what I think the properties of the WebDAV methods
                          are (feedback appreciated):


                          method safe idempotent semantics resource cacheable
                          -----------------------------------------------------------
                          GET | X X X X X |
                          HEAD | X X X X X |
                          PUT | X X X |
                          POST(a) | / |
                          POST(p) | |
                          DELETE | X X X |
                          OPTIONS | X X X O |
                          -----------------------------------------------------------
                          PROPFIND | X X X X |
                          PROPPATCH | X X X |
                          MKCOL | X X X |
                          COPY | X X |
                          MOVE | X X |
                          LOCK | X X |
                          UNLOCK | X X |
                          -----------------------------------------------------------


                          Best regards, Julian

                          --
                          <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
                        • Roy T. Fielding
                          ... PROPFIND, PROPPATCH, LOCK, and UNLOCK do not have identifiable resources (they all operate by way of a third party). Is PROPPATCH always idempotent? COPY
                          Message 12 of 25 , Dec 30, 2004
                          • 0 Attachment
                            On Dec 30, 2004, at 7:49 AM, Julian Reschke wrote:
                            > OK, I have filled out what I think the properties of the WebDAV methods
                            > are (feedback appreciated):
                            >
                            >
                            > method safe idempotent semantics resource
                            > cacheable
                            >
                            > -----------------------------------------------------------
                            > GET | X X X X X
                            > |
                            > HEAD | X X X X X
                            > |
                            > PUT | X X X
                            > |
                            > POST(a) | /
                            > |
                            > POST(p) |
                            > |
                            > DELETE | X X X
                            > |
                            > OPTIONS | X X X O
                            > |
                            >
                            > -----------------------------------------------------------
                            > PROPFIND | X X X X
                            > |
                            > PROPPATCH | X X X
                            > |
                            > MKCOL | X X X
                            > |
                            > COPY | X X
                            > |
                            > MOVE | X X
                            > |
                            > LOCK | X X
                            > |
                            > UNLOCK | X X
                            > |
                            >
                            > -----------------------------------------------------------

                            PROPFIND, PROPPATCH, LOCK, and UNLOCK do not have identifiable resources
                            (they all operate by way of a third party). Is PROPPATCH always
                            idempotent?
                            COPY and MOVE are a bit weird due to HTTP's limitation of the target
                            URI.

                            I think we should add all of the webdav methods, not just 2518. Most
                            people
                            have no idea what has been added/proposed for versioning and bindings.

                            ....Roy
                          • Julian Reschke
                            ... Could you please expand on what you mean by they operate by way of a third party (is this about the Depth request header?)? For instance, the results for
                            Message 13 of 25 , Dec 30, 2004
                            • 0 Attachment
                              Roy T. Fielding wrote:
                              > On Dec 30, 2004, at 7:49 AM, Julian Reschke wrote:
                              >
                              >> OK, I have filled out what I think the properties of the WebDAV methods
                              >> are (feedback appreciated):
                              >>
                              >>
                              >> method safe idempotent semantics resource cacheable
                              >> -----------------------------------------------------------
                              >> GET | X X X X X |
                              >> HEAD | X X X X X |
                              >> PUT | X X X |
                              >> POST(a) | / |
                              >> POST(p) | |
                              >> DELETE | X X X |
                              >> OPTIONS | X X X O |
                              >> -----------------------------------------------------------
                              >> PROPFIND | X X X X |
                              >> PROPPATCH | X X X |
                              >> MKCOL | X X X |
                              >> COPY | X X |
                              >> MOVE | X X |
                              >> LOCK | X X |
                              >> UNLOCK | X X |
                              >> -----------------------------------------------------------
                              >
                              >
                              > PROPFIND, PROPPATCH, LOCK, and UNLOCK do not have identifiable resources
                              > (they all operate by way of a third party). Is PROPPATCH always

                              Could you please expand on what you mean by "they operate by way of a
                              third party" (is this about the Depth request header?)? For instance,
                              the results for a PROPFIND applied to the same Request-URI will vary for
                              Depth 0 (just the Request-URI), 1 (+ internal members) and infinity (+
                              all descendants).

                              > idempotent?

                              I would think so. PROPPATCH can either set ("PUT") or remove (aka
                              "DELETE") a property. Of course I can imagine a server getting this
                              wrong, but for the same reason it may get GET and PUT wrong. Possibly
                              this is something that should be clarified in RFC2518bis.

                              > COPY and MOVE are a bit weird due to HTTP's limitation of the target URI.
                              >
                              > I think we should add all of the webdav methods, not just 2518. Most
                              > people
                              > have no idea what has been added/proposed for versioning and bindings.

                              That's correct (a good summary about what the state of affairs is can be
                              found at <http://greenbytes.de/tech/webdav>), but let's get the entries
                              for base WebDAV right first :-)

                              Julian

                              --
                              <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
                            • Mark Baker
                              I agree with your general point Roy, but just had a comment on something you said ... ... I was under the impression that the degree of visibility in both
                              Message 14 of 25 , Dec 30, 2004
                              • 0 Attachment
                                I agree with your general point Roy, but just had a comment on
                                something you said ...

                                On Wed, Dec 29, 2004 at 06:28:30PM -0800, Roy T. Fielding wrote:
                                > POST(a), as "append this", is unsafe, non-idempotent, non-cacheable,
                                > operates on an unknown resource, and has only minor visibility since
                                > there is no way for an intermediary to anticipate the state of the
                                > resource after the append aside from "some state was added". POST(p),
                                > as "process this", doesn't even have that minor visibility.

                                I was under the impression that the degree of visibility in both cases
                                was identical, since the client has just as much trouble anticipating
                                the state of the resources as the intermediary. What I think you're
                                talking about there - please correct me if I'm mistaken - is the amount
                                of information that can be extracted from a message. But I wouldn't
                                personally call that amount of information "visibility" in the section 2
                                of your dissertation sense-of-the-word, since to do so, it seems, would
                                be akin to suggesting that "getStockQuote" is more visible than GET
                                simply because it's more specific, i.e. is equivalent to the GET
                                semantic plus the expected type of the data (a stock quote).

                                Mark.
                                --
                                Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                              • Roy T. Fielding
                                ... That wasn t what I meant, though depth is certainly another can of worms. I guess that is another reason why PROPFIND is not cacheable. I meant that the
                                Message 15 of 25 , Dec 30, 2004
                                • 0 Attachment
                                  >> PROPFIND, PROPPATCH, LOCK, and UNLOCK do not have identifiable
                                  >> resources
                                  >> (they all operate by way of a third party). Is PROPPATCH always
                                  >
                                  > Could you please expand on what you mean by "they operate by way of a
                                  > third party" (is this about the Depth request header?)? For instance,
                                  > the results for a PROPFIND applied to the same Request-URI will vary
                                  > for
                                  > Depth 0 (just the Request-URI), 1 (+ internal members) and infinity (+
                                  > all descendants).

                                  That wasn't what I meant, though depth is certainly another can of
                                  worms.
                                  I guess that is another reason why PROPFIND is not cacheable.

                                  I meant that the client is using the resource URI to access other
                                  resources that just happen to be properties of the resource URI. The
                                  indirection means that the client has no way to identify those
                                  properties
                                  as resources, apply access control to them as resources, version them as
                                  resources, etc.

                                  >> idempotent?
                                  >
                                  > I would think so. PROPPATCH can either set ("PUT") or remove (aka
                                  > "DELETE") a property.

                                  okay.

                                  ....Roy
                                • Roy T. Fielding
                                  ... They are effectively the same, yes, but visibility is a continuous function. Just knowing something about the intent of the client may be better than
                                  Message 16 of 25 , Dec 30, 2004
                                  • 0 Attachment
                                    On Dec 30, 2004, at 3:49 PM, Mark Baker wrote:
                                    > On Wed, Dec 29, 2004 at 06:28:30PM -0800, Roy T. Fielding wrote:
                                    >> POST(a), as "append this", is unsafe, non-idempotent, non-cacheable,
                                    >> operates on an unknown resource, and has only minor visibility since
                                    >> there is no way for an intermediary to anticipate the state of the
                                    >> resource after the append aside from "some state was added". POST(p),
                                    >> as "process this", doesn't even have that minor visibility.
                                    >
                                    > I was under the impression that the degree of visibility in both cases
                                    > was identical, since the client has just as much trouble anticipating
                                    > the state of the resources as the intermediary.

                                    They are effectively the same, yes, but visibility is a continuous
                                    function.
                                    Just knowing something about the intent of the client may be better
                                    than nothing.

                                    > What I think you're
                                    > talking about there - please correct me if I'm mistaken - is the amount
                                    > of information that can be extracted from a message. But I wouldn't
                                    > personally call that amount of information "visibility" in the section
                                    > 2
                                    > of your dissertation sense-of-the-word, since to do so, it seems, would
                                    > be akin to suggesting that "getStockQuote" is more visible than GET
                                    > simply because it's more specific, i.e. is equivalent to the GET
                                    > semantic plus the expected type of the data (a stock quote).

                                    There are many variables involved in determining visibility, not just
                                    the self-descriptiveness of the message. For example, simplicity and
                                    visibility are intertwined: being very specific, to the point of
                                    describing
                                    all possible details, will reduce visibility regardless of how
                                    descriptive
                                    the message becomes -- the additional information becomes noise.
                                    Making the method data-specific, as in your example, creates complexity
                                    because the expected types of data in an open system are potentially
                                    infinite,
                                    but it is only when the system as a whole is considered that we find the
                                    trade-off unacceptable.

                                    I keep feeling that there should be an easier way to describe this stuff
                                    so that the constraints follow from the design goals of the Web. The
                                    problem
                                    is that the design encompasses a number of independent factors that
                                    become
                                    a feedback loop, with the goal of that loop being continual growth of
                                    the
                                    Web itself (i.e., more information being linked-in). For example, the
                                    main
                                    reason that getStockQuote is evil, far more so than the issue of
                                    visibility
                                    described above, is because then a URI alone would not be sufficient to
                                    to identify the resource, which would mean the resource could not be
                                    linked-in with the rest of the Web, which would mean the Web loses that
                                    potential for growth and we all lose because the value of the Web to
                                    each user is influenced by Metcalfe's Law.


                                    Cheers,

                                    Roy T. Fielding <http://roy.gbiv.com/>
                                    Chief Scientist, Day Software <http://www.day.com/>
                                  • Julian Reschke
                                    ... Correct. RFC2518 already specifies PROPFIND as non-cacheable. ... Ah! Now that depends on whether one considers those properties as different resources (as
                                    Message 17 of 25 , Dec 31, 2004
                                    • 0 Attachment
                                      Roy T. Fielding wrote:
                                      >>>PROPFIND, PROPPATCH, LOCK, and UNLOCK do not have identifiable
                                      >>>resources
                                      >>>(they all operate by way of a third party). Is PROPPATCH always
                                      >>
                                      >>Could you please expand on what you mean by "they operate by way of a
                                      >>third party" (is this about the Depth request header?)? For instance,
                                      >>the results for a PROPFIND applied to the same Request-URI will vary
                                      >>for
                                      >>Depth 0 (just the Request-URI), 1 (+ internal members) and infinity (+
                                      >>all descendants).
                                      >
                                      >
                                      > That wasn't what I meant, though depth is certainly another can of
                                      > worms.

                                      Correct. RFC2518 already specifies PROPFIND as non-cacheable.

                                      > I guess that is another reason why PROPFIND is not cacheable.
                                      >
                                      > I meant that the client is using the resource URI to access other
                                      > resources that just happen to be properties of the resource URI. The
                                      > indirection means that the client has no way to identify those
                                      > properties
                                      > as resources, apply access control to them as resources, version them as
                                      > resources, etc.

                                      Ah! Now that depends on whether one considers those properties as
                                      different resources (as one can easily construct a URI for each of these
                                      properties, this is certainly a valid point of view). Let's stick with a
                                      very simple example such as:

                                      HEAD /foo HTTP/1.1
                                      Host: example.com

                                      vs

                                      PROPFIND /foo HTTP/1.1
                                      Host: example.com
                                      Depth: 0
                                      Content-Type: application/xml

                                      <propfind xmlns="DAV:">
                                      <prop><getcontenttype/><getcontentlength></prop>
                                      </propfind>

                                      At least in this case, PROPFIND doesn't seem to be more than a different
                                      way of getting the same information.

                                      So is your concern about cases such as custom properties on a resource?

                                      Best regards, Julian

                                      --
                                      <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
                                    • Jan Algermissen
                                      Julian Reschke wrote: [...] ... Does anyone happen to know why the functionality of PROPFIND has not simply been enabled by the definition of a set of
                                      Message 18 of 25 , Jan 1, 2005
                                      • 0 Attachment
                                        Julian Reschke wrote:

                                        [...]

                                        >Let's stick with a
                                        >very simple example such as:
                                        >
                                        >HEAD /foo HTTP/1.1
                                        >Host: example.com
                                        >
                                        >vs
                                        >
                                        >PROPFIND /foo HTTP/1.1
                                        >Host: example.com
                                        >Depth: 0
                                        >Content-Type: application/xml
                                        >
                                        ><propfind xmlns="DAV:">
                                        > <prop><getcontenttype/><getcontentlength></prop>
                                        ></propfind>
                                        >
                                        >At least in this case, PROPFIND doesn't seem to be more than a different
                                        >way of getting the same information.
                                        >
                                        >
                                        Does anyone happen to know why the functionality of PROPFIND has not
                                        simply been enabled by
                                        the definition of a set of additional headers, e.g.

                                        HEAD /foo HTTP/1.1
                                        Host: example.com
                                        DAV-GetProps: ContentType; ContentLength

                                        ???

                                        Or would this use of headers be unRESTful anyhow?

                                        Jan


                                        >So is your concern about cases such as custom properties on a resource?
                                        >
                                        >Best regards, Julian
                                        >
                                        >
                                        >


                                        --
                                        Jan Algermissen
                                        Consultant & Programmer
                                        http://jalgermissen.com
                                      • Julian Reschke
                                        ... Extensibility of header names? Internationalization considerations? Namespace operations? Updates of properties? Anyway, this: WebDAV and the Birth of
                                        Message 19 of 25 , Jan 1, 2005
                                        • 0 Attachment
                                          Jan Algermissen wrote:
                                          > Does anyone happen to know why the functionality of PROPFIND has not
                                          > simply been enabled by
                                          > the definition of a set of additional headers, e.g.
                                          >
                                          > HEAD /foo HTTP/1.1
                                          > Host: example.com
                                          > DAV-GetProps: ContentType; ContentLength
                                          >
                                          > ???
                                          >
                                          > Or would this use of headers be unRESTful anyhow?
                                          >
                                          > Jan

                                          Extensibility of header names? Internationalization considerations?
                                          Namespace operations? Updates of properties?

                                          Anyway, this:

                                          "WebDAV and the Birth of Properties"
                                          <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html>

                                          may also be an interesting read...

                                          Julian

                                          --
                                          <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
                                        • Roy T. Fielding
                                          ... Yeah, Yaron s twisted little view of history. It would be more accurate to say that some people insisted HTTP could not carry internationalized data in
                                          Message 20 of 25 , Jan 1, 2005
                                          • 0 Attachment
                                            On Jan 1, 2005, at 1:06 PM, Julian Reschke wrote:
                                            > Extensibility of header names? Internationalization considerations?
                                            > Namespace operations? Updates of properties?
                                            >
                                            > Anyway, this:
                                            >
                                            > "WebDAV and the Birth of Properties"
                                            > <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/
                                            > 0074.html>
                                            >
                                            > may also be an interesting read...

                                            Yeah, Yaron's twisted little view of history. It would be more
                                            accurate to say
                                            that some people insisted HTTP could not carry internationalized data in
                                            header fields (which is blatantly false -- it is only inconveniently
                                            encoded),
                                            and thus spawned an incredibly convoluted XML format for properties,
                                            which
                                            later got boiled down to name-value pairs (like all metadata systems).
                                            DASL
                                            got invented because an XML search interface was needed to deal with
                                            the complex
                                            properties, but was later dropped due to lack of interest in a
                                            half-assed
                                            variation of what the real database people were working on with XQuery.

                                            The issue of identification started because of a really bad paper tiger
                                            design
                                            for munging URIs that was proposed by someone else, rejected, and then
                                            replaced
                                            by me during a meeting at Xerox PARC with the imagemap-style URI
                                            provided
                                            by the server. Larry did not object to that style of munging. The
                                            design was
                                            not used by WebDAV because the editors chose not to for some unknown
                                            reason,
                                            not because there was any objection from the working group (on the
                                            contrary,
                                            both Henrik and I objected to the extra methods). All of that nonsense
                                            about extra round-trips is just bullshit invented by Yaron --
                                            Microsoft's own
                                            implementations had no such concern for round-trips and actually made
                                            two
                                            unnecessary requests prior to each WebDAV resource action just to check
                                            if it
                                            was actually WebDAV-enabled.

                                            WebDAV is stuck with that design because we let Microsoft dominate the
                                            working group as the only significant implementation. Apache's mod_dav
                                            didn't come along until much later. Henrik's implementation in libwww,
                                            completed during the HTTP/1.1 design, was ignored because it didn't use
                                            XML.

                                            ....Roy
                                          • Julian Reschke
                                            ... OK, another interesting read is in Jim Whitehead s and Yaron Goland s The WebDAV Property Design .
                                            Message 21 of 25 , Jan 2, 2005
                                            • 0 Attachment
                                              Roy T. Fielding wrote:
                                              > ...
                                              > Yeah, Yaron's twisted little view of history. It would be more
                                              > accurate to say
                                              > that some people insisted HTTP could not carry internationalized data in
                                              > header fields (which is blatantly false -- it is only inconveniently
                                              > encoded),
                                              > and thus spawned an incredibly convoluted XML format for properties,
                                              > which
                                              > later got boiled down to name-value pairs (like all metadata systems).
                                              > DASL
                                              > got invented because an XML search interface was needed to deal with
                                              > the complex
                                              > properties, but was later dropped due to lack of interest in a
                                              > half-assed
                                              > variation of what the real database people were working on with XQuery.

                                              OK, another interesting read is in Jim Whitehead's and Yaron Goland's
                                              "The WebDAV Property Design"
                                              "<http://www.cs.ucsc.edu/~ejw/papers/spe-whitehead.pdf>.

                                              I came to WebDAV only in early 2001 (when all design decisions were
                                              already made and DeltaV was nearing completion). However, I do agree
                                              with some of the points made about using HTTP headers for properties, in
                                              particular:

                                              HTTP header values can use non-ASCII characters (RFC2231), but the
                                              header names itself can't (or am I missing something)? So if it is a
                                              requirement that property *names* can use arbitrary characters, they
                                              can't be mapped to header names.

                                              It would be an interesting exercise to define a new request header for
                                              GET/HEAD that would basically transport PROPFIND (depth=0) information
                                              in headers. Anybody interested?

                                              > The issue of identification started because of a really bad paper tiger
                                              > design
                                              > for munging URIs that was proposed by someone else, rejected, and then
                                              > replaced
                                              > by me during a meeting at Xerox PARC with the imagemap-style URI
                                              > provided
                                              > by the server. Larry did not object to that style of munging. The
                                              > design was
                                              > not used by WebDAV because the editors chose not to for some unknown
                                              > reason,
                                              > not because there was any objection from the working group (on the
                                              > contrary,
                                              > both Henrik and I objected to the extra methods). All of that nonsense

                                              I'd really like to see that proposal, however I haven't been able to
                                              find it in the mailing list archives so far. Unfortunately, the other
                                              archive that's supposed to have it
                                              (<http://ftp.ics.uci.edu/pub/ietf/webdav/>) seems to be
                                              misconfigured/down right down.

                                              > about extra round-trips is just bullshit invented by Yaron --
                                              > Microsoft's own
                                              > implementations had no such concern for round-trips and actually made
                                              > two
                                              > unnecessary requests prior to each WebDAV resource action just to check
                                              > if it
                                              > was actually WebDAV-enabled.
                                              >
                                              > WebDAV is stuck with that design because we let Microsoft dominate the
                                              > working group as the only significant implementation. Apache's mod_dav
                                              > didn't come along until much later. Henrik's implementation in libwww,
                                              > completed during the HTTP/1.1 design, was ignored because it didn't use
                                              > XML.

                                              Although I'm not happy with many parts of the WebDAV design, there
                                              doesn't seem to be a lot of competition, probably because it's "good
                                              enough". However, that doesn't mean that it wouldn't be a good thing to
                                              actually document an alternate design -- maybe it could get traction
                                              outside the Microsoft world (such as Apache/mod_dav and Apache Slide).

                                              Best regards, Julian

                                              --
                                              <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
                                            Your message has been successfully submitted and would be delivered to recipients shortly.