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

Re: [rest-discuss] Getting problem in use REST in development of webservice

Expand Messages
  • Elias Sinderson
    ... This is good advice, and the above seems to be what one would generally expect, more or less. Depending on the application, POST may have alternate
    Message 1 of 24 , Apr 11, 2006
    • 0 Attachment
      Nic wrote:

      > To make a REST webservice simply build a normal webapp with different
      > resources. Restrict yourself to the HTTP methods as the verbs for your
      > webservice, eg:
      >
      > GET get the resource
      > POST create a new resource
      > PUT edit the resource
      >
      >
      This is good advice, and the above seems to be what one would generally
      expect, more or less. Depending on the application, POST may have
      alternate semantics and, assuming the client knows where things are
      supposed to go or owns the URI space (e.g. operations within a users own
      account area), PUT may be used for resource creation.

      > DELETE move the resource
      >
      >
      What? That's just crazy. How did DELETE suddenly become MOVE? Would you
      then need to use POST for DELETE? Seems not so good to me, but if you
      aren't willing to support WebDAV methods for namespace operations than
      this might be acceptable, if slightly unorthodox.

      This has been, to some extent, a personal crusade of mine -- to get
      people to realize that REST is more than GET, PUT, POST and DELETE.
      There are other methods available whendeveloping REST applications
      within the framework of the Web; MOVE, COPY and MKCOL for namespace
      operations, PROPPATCH and PROPFIND for working with resource metadata,
      LOCK and UNLOCK for managing access to resources, etc.

      > HEAD brief overview of the resource
      >
      >
      Well, in as much as the HTTP headers returned on a GET provide an
      overview of a resource... Some systems will maintain 'summary resources'
      that have their own URI. Obviously the approach taken depends on the
      specifics of your particular application.


      Cheers,
      Elias

      P.S. Welcome to REST, Manoj! :-)
    • Mark Baker
      ... I suspect Nic intended to say *re*move . Nice over-reaction though, Elias! 8-) Mark. -- Mark Baker. Ottawa, Ontario, CANADA.
      Message 2 of 24 , Apr 11, 2006
      • 0 Attachment
        On 4/11/06, Elias Sinderson <elias@...> wrote:
        > > DELETE move the resource
        > >
        > >
        > What? That's just crazy.

        I suspect Nic intended to say "*re*move". Nice over-reaction though, Elias! 8-)

        Mark.
        --
        Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
      • Elias Sinderson
        ... Ah, remove indeed... over reaction? Perhaps, but that s why I jokingly refer to it as my crusade... Sorry if it came off poorly! At any rate, I stand by my
        Message 3 of 24 , Apr 11, 2006
        • 0 Attachment
          Mark Baker wrote:

          >On 4/11/06, Elias Sinderson <elias@...> wrote:
          >
          >
          >>>DELETE move the resource
          >>>
          >>>
          >>What? That's just crazy.
          >>
          >>
          >I suspect Nic intended to say "*re*move". Nice over-reaction though, Elias! 8-)
          >
          Ah, remove indeed... over reaction? Perhaps, but that's why I jokingly
          refer to it as my crusade... Sorry if it came off poorly! At any rate, I
          stand by my statement re: REST is more than GET, PUT, POST and DELTE. ;-)

          Nic, can you confirm or deny that the above was a typo?


          Thanks,
          Elias
        • Nic
          ... Sorry. I didn t mean move I meant remove . I m affraid my attention was actually on wallance and grommit s wrong trousers. ... I strongly disagree that
          Message 4 of 24 , Apr 11, 2006
          • 0 Attachment
            Elias Sinderson <elias@...> writes:

            > Nic wrote:
            >
            >> To make a REST webservice simply build a normal webapp with different
            >> resources. Restrict yourself to the HTTP methods as the verbs for your
            >> webservice, eg:
            >>
            >> GET get the resource
            >> POST create a new resource
            >> PUT edit the resource
            >>
            >>
            > This is good advice, and the above seems to be what one would generally
            > expect, more or less. Depending on the application, POST may have
            > alternate semantics and, assuming the client knows where things are
            > supposed to go or owns the URI space (e.g. operations within a users own
            > account area), PUT may be used for resource creation.
            >
            >> DELETE move the resource
            >>
            >>
            > What? That's just crazy. How did DELETE suddenly become MOVE? Would you
            > then need to use POST for DELETE? Seems not so good to me, but if you
            > aren't willing to support WebDAV methods for namespace operations than
            > this might be acceptable, if slightly unorthodox.

            Sorry.

            I didn't mean "move" I meant "remove".

            I'm affraid my attention was actually on wallance and grommit's wrong
            trousers.



            > This has been, to some extent, a personal crusade of mine -- to get
            > people to realize that REST is more than GET, PUT, POST and DELETE.
            > There are other methods available whendeveloping REST applications
            > within the framework of the Web; MOVE, COPY and MKCOL for namespace
            > operations, PROPPATCH and PROPFIND for working with resource metadata,
            > LOCK and UNLOCK for managing access to resources, etc.

            I strongly disagree that this is the case. I don't believe WEBDAV
            methods are necessary or even advisable for REST based apps.



            Nic
          • Joe Gregorio
            ... Agreed. I m sure there are cases where other methods will be needed, but the PROP* methods in WebDAV aren t a really good example; properties could have
            Message 5 of 24 , Apr 11, 2006
            • 0 Attachment
              On 4/11/06, Nic <nferrier@...> wrote:
              > Elias Sinderson <elias@...> writes:
              >
              > > Nic wrote:
              > > This has been, to some extent, a personal crusade of mine -- to get
              > > people to realize that REST is more than GET, PUT, POST and DELETE.
              > > There are other methods available whendeveloping REST applications
              > > within the framework of the Web; MOVE, COPY and MKCOL for namespace
              > > operations, PROPPATCH and PROPFIND for working with resource metadata,
              > > LOCK and UNLOCK for managing access to resources, etc.
              >
              > I strongly disagree that this is the case. I don't believe WEBDAV
              > methods are necessary or even advisable for REST based apps.

              Agreed.

              I'm sure there are cases where other methods will be needed,
              but the PROP* methods in WebDAV aren't a really good
              example; properties could have been their own resources
              manipulated with GET/PUT/POST/DELETE. Similarly with LOCK and
              UNLOCK, the lock could have been made into a resource also manipulated
              via GET/PUT/POST/DELETE.

              -joe

              --
              Joe Gregorio http://bitworking.org
            • Elias Sinderson
              ... Thanks for the clarification -- those pesky trousers! :-) ... Ah, the slings and arrows, fantastic! :-) So, you are certainly entitled to your opinion,
              Message 6 of 24 , Apr 11, 2006
              • 0 Attachment
                Nic wrote:

                >Elias Sinderson <elias@...> writes:
                >
                >
                >>Nic wrote:
                >>
                >>
                >>>DELETE move the resource
                >>>
                >>>
                >>What? That's just crazy. How did DELETE suddenly become MOVE?
                >>
                >>
                >Sorry. I didn't mean "move" I meant "remove". I'm affraid my attention was actually on wallance and grommit's wrong trousers.
                >
                >
                Thanks for the clarification -- those pesky trousers! :-)

                >><Elias> This has been, to some extent, a personal crusade of mine -- to get people to realize that REST is more than GET, PUT, POST and DELETE. [...] </Elias>
                >>
                >>
                ><Nic> I strongly disagree that this is the case. I don't believe WEBDAV methods are necessary or even advisable for REST based apps. </Nic>
                >
                Ah, the slings and arrows, fantastic! :-) So, you are certainly
                entitled to your opinion, and others theirs. I'm well aware that
                crusades can be difficult... Let's take a closer look at this issue
                together then.

                First, I'll note that there is no mention in Fieldings' dissertation of
                which specific methods are necessary, sufficient or even desireable for
                a REST application to support. There is, however, the constraint that
                REST resources support a uniform interface. HTTP simply happens to be
                /an implementation/, albeit the most widely deployed and, some would
                argue, the best available. ;-) REST is no more defined by GET, PUT,
                POST and DELETE than it is by the FOO, BAR, BAZ and BLAH methods of some
                other implementation. To take your position to the extreme, someone may
                just as well state that REST is solely defined by GET and POST...

                IMHO, necessity has very little to do with the issue, otherwise one may
                just as well tunnel all of your application semantics through POST and
                be done with it. (Oh, wait, that's SOAP over HTTP!) It is not the
                /necessity/ of DELETE, for example, that makes it a good idea, it's
                simply that if everyone implemented their own DELETE via POST we would
                soon find ourselves back in fragmented API land. Clearly, the same can
                be said of PUT (and some do). Similarly, metadata properties associated
                with a resource may be set and read via POST, resources could be moved
                and copied about via POST and so on. The fact remains, however, that
                there are standardized protocol methods that have been defined for these
                common operations. Further, these methods have been defined within the
                HTTP framework as extensions to HTTP itself -- they are intended to play
                nicely together.

                In designing RESTful applications, I believe that one must remain
                cognizant of the implications associated with how application behaviors
                are realized through HTTP. Sure, you can tunnel anything you want
                through POST, even things that have been defined as other methods, but I
                think it undermines the 'interface genericity' constraint somewhat as
                you are no longer interacting with the resource you want to, e.g.,
                delete or move, but an arbiter who then does the delete or move for you.

                It is unclear to me why someone would advocate the use of DELETE (over
                POST as DELETE) but caution against the use of MOVE and am curious as to
                your statement regarding the advisability of using WebDAV (or other?)
                methods for REST applications. Could you elaborate more on this point? I
                won't discount the constraints that may be imposed by a given business,
                economic or political reality, but am for more interested in discussing
                the architectural and systems engineering constraints.


                Thanks,
                Elias
              • Nic
                ... Because DELETE is supported by nearlly *all* the available HTTP clients and MOVE is not. It is nonsensical to argue that a WEBDAV based web service would
                Message 7 of 24 , Apr 11, 2006
                • 0 Attachment
                  Elias Sinderson <elias@...> writes:

                  > It is unclear to me why someone would advocate the use of DELETE (over
                  > POST as DELETE) but caution against the use of MOVE

                  Because DELETE is supported by nearlly *all* the available HTTP
                  clients and MOVE is not. It is nonsensical to argue that a WEBDAV
                  based web service would be as widely available as an RFC2616 service.

                  It's easy for a client to use DELETE. It's not easy for a client to
                  use MOVE.


                  > and am curious as to
                  > your statement regarding the advisability of using WebDAV (or other?)
                  > methods for REST applications. Could you elaborate more on this point? I
                  > won't discount the constraints that may be imposed by a given business,
                  > economic or political reality, but am for more interested in discussing
                  > the architectural and systems engineering constraints.

                  Well, I think others have responded on the superflous nature of the
                  WebDAV methods.

                  But let me make a few other bullet points:

                  - REST is not just a widely agreed API, it is a _simple_ API
                  - What does WEBDAV add that I can't explain in terms of HTTP?
                  - there are risks in adding any method
                  - it's very hard to explain the simplicity of REST (this is worth a
                  thread in itself)
                  - it will be harder with people saying "actually it's not as simple as
                  those people over there are saying"

                  The last point is said in a kind of jokey spirit, please don't take it
                  too hard.


                  Nic
                • Roy T. Fielding
                  ... That is correct. My work distinguished between the REST architectural style and any particular instantiation of that style (URI, HTTP, etc.). This is
                  Message 8 of 24 , Apr 11, 2006
                  • 0 Attachment
                    On Apr 11, 2006, at 12:00 PM, Elias Sinderson wrote:
                    >> <Nic> I strongly disagree that this is the case. I don't believe
                    >> WEBDAV methods are necessary or even advisable for REST based
                    >> apps. </Nic>
                    >>
                    > Ah, the slings and arrows, fantastic! :-) So, you are certainly
                    > entitled to your opinion, and others theirs. I'm well aware that
                    > crusades can be difficult... Let's take a closer look at this issue
                    > together then.
                    >
                    > First, I'll note that there is no mention in Fieldings'
                    > dissertation of
                    > which specific methods are necessary, sufficient or even desireable
                    > for
                    > a REST application to support. There is, however, the constraint that
                    > REST resources support a uniform interface. HTTP simply happens to be
                    > /an implementation/, albeit the most widely deployed and, some would
                    > argue, the best available. ;-) REST is no more defined by GET, PUT,
                    > POST and DELETE than it is by the FOO, BAR, BAZ and BLAH methods of
                    > some
                    > other implementation. To take your position to the extreme, someone
                    > may
                    > just as well state that REST is solely defined by GET and POST...

                    That is correct. My work distinguished between the REST architectural
                    style and any particular instantiation of that style (URI, HTTP, etc.).
                    This is undoubtedly a pain in the ass for folks who just want an
                    acronym for good webarch design.

                    > IMHO, necessity has very little to do with the issue, otherwise one
                    > may
                    > just as well tunnel all of your application semantics through POST and
                    > be done with it. (Oh, wait, that's SOAP over HTTP!) It is not the
                    > /necessity/ of DELETE, for example, that makes it a good idea, it's
                    > simply that if everyone implemented their own DELETE via POST we would
                    > soon find ourselves back in fragmented API land. Clearly, the same can
                    > be said of PUT (and some do). Similarly, metadata properties
                    > associated
                    > with a resource may be set and read via POST, resources could be moved
                    > and copied about via POST and so on. The fact remains, however, that
                    > there are standardized protocol methods that have been defined for
                    > these
                    > common operations. Further, these methods have been defined within the
                    > HTTP framework as extensions to HTTP itself -- they are intended to
                    > play
                    > nicely together.

                    Sometimes. PROP* methods conflict with REST because they prevent
                    important resources from having URIs and effectively double the
                    number of methods for no good reason. Both Henrik and I argued
                    against those methods at the time. It really doesn't matter
                    how uniform they are because they break other aspects of the
                    overall model, leading to further complications in versioning
                    (WebDAV versioning is hopelessly complicated), access control
                    (WebDAV ACLs are completely wrong for HTTP), and just about every
                    other extension to WebDAV that has been proposed.

                    > In designing RESTful applications, I believe that one must remain
                    > cognizant of the implications associated with how application
                    > behaviors
                    > are realized through HTTP. Sure, you can tunnel anything you want
                    > through POST, even things that have been defined as other methods,
                    > but I
                    > think it undermines the 'interface genericity' constraint somewhat as
                    > you are no longer interacting with the resource you want to, e.g.,
                    > delete or move, but an arbiter who then does the delete or move for
                    > you.
                    >
                    > It is unclear to me why someone would advocate the use of DELETE (over
                    > POST as DELETE) but caution against the use of MOVE and am curious
                    > as to
                    > your statement regarding the advisability of using WebDAV (or other?)
                    > methods for REST applications. Could you elaborate more on this
                    > point? I
                    > won't discount the constraints that may be imposed by a given
                    > business,
                    > economic or political reality, but am for more interested in
                    > discussing
                    > the architectural and systems engineering constraints.

                    The problem with MOVE is that it is actually an operation on two
                    independent namespaces (the source collection and destination
                    collection). The user must have permission to remove from the
                    source collection and add to the destination collection, which
                    can be a bit of a problem if they are in different authentication
                    realms. COPY has a similar problem, but at least in that case
                    only one namespace is modified. I don't think either of them map
                    very well to HTTP.

                    Tease: Any method in waka can have 0|1|2|N-arguments.

                    ....Roy
                  • Julian Reschke
                    ... Interesting. Could you elaborate a bit? Which client or framework does allow you to use DELETE, but not MOVE? ... Best regards, Julian
                    Message 9 of 24 , Apr 11, 2006
                    • 0 Attachment
                      Nic wrote:
                      > Elias Sinderson <elias@...> writes:
                      >
                      >> It is unclear to me why someone would advocate the use of DELETE (over
                      >> POST as DELETE) but caution against the use of MOVE
                      >
                      > Because DELETE is supported by nearlly *all* the available HTTP
                      > clients and MOVE is not. It is nonsensical to argue that a WEBDAV
                      > based web service would be as widely available as an RFC2616 service.
                      >
                      > It's easy for a client to use DELETE. It's not easy for a client to
                      > use MOVE.
                      > ...


                      Interesting. Could you elaborate a bit? Which client or framework does
                      allow you to use DELETE, but not MOVE?

                      > ...

                      Best regards, Julian
                    • Julian Reschke
                      ... I do agree that it would be nice if each property of a resource had it s URI. It s certainly possible to implement meta data that way. As far as I
                      Message 10 of 24 , Apr 11, 2006
                      • 0 Attachment
                        Roy T. Fielding wrote:
                        > ...
                        > Sometimes. PROP* methods conflict with REST because they prevent
                        > important resources from having URIs and effectively double the
                        > number of methods for no good reason. Both Henrik and I argued
                        > against those methods at the time. It really doesn't matter
                        > how uniform they are because they break other aspects of the
                        > overall model, leading to further complications in versioning
                        > (WebDAV versioning is hopelessly complicated), access control
                        > (WebDAV ACLs are completely wrong for HTTP), and just about every
                        > other extension to WebDAV that has been proposed.

                        I do agree that it would be nice if each property of a resource had it's
                        URI. It's certainly possible to implement meta data that way. As far as
                        I understand the records of the WebDAV working group from pre-1999, that
                        approach was discussed but in the end discarded due to many *other*
                        problems it would have introduced, such as: how can I effectively obtain
                        the children + a specific meta data subset for one collection? That's
                        one of the most common operations a WebDAV client does, and if there's
                        no efficient way to do that, there's definitively a problem.

                        I'd really like to see the protocol details for such a design, so that
                        it can really be compared to what we have today.

                        As for the remainder, I'm really not sure what you're talking about
                        (more details, please). For instance, RFC3253 (Versioning) introduces
                        separate URIs for version histories and versions (basic versioning).


                        > ...
                        > The problem with MOVE is that it is actually an operation on two
                        > independent namespaces (the source collection and destination
                        > collection). The user must have permission to remove from the
                        > source collection and add to the destination collection, which
                        > can be a bit of a problem if they are in different authentication
                        > realms. COPY has a similar problem, but at least in that case
                        > only one namespace is modified. I don't think either of them map
                        > very well to HTTP.
                        > ...

                        That seems to be a problem with the concept of moving resources around,
                        not with the actual definition of the MOVE method, right?

                        > ...

                        Best regards, Julian
                      • Nic
                        ... AJAX. python s urllib Java s URL/URLConnection For starters. Nic
                        Message 11 of 24 , Apr 11, 2006
                        • 0 Attachment
                          Julian Reschke <julian.reschke@...> writes:

                          > Nic wrote:
                          >> Elias Sinderson <elias@...> writes:
                          >>
                          >>> It is unclear to me why someone would advocate the use of DELETE (over
                          >>> POST as DELETE) but caution against the use of MOVE
                          >>
                          >> Because DELETE is supported by nearlly *all* the available HTTP
                          >> clients and MOVE is not. It is nonsensical to argue that a WEBDAV
                          >> based web service would be as widely available as an RFC2616 service.
                          >>
                          >> It's easy for a client to use DELETE. It's not easy for a client to
                          >> use MOVE.
                          >> ...
                          >
                          >
                          > Interesting. Could you elaborate a bit? Which client or framework does
                          > allow you to use DELETE, but not MOVE?

                          AJAX.
                          python's urllib
                          Java's URL/URLConnection

                          For starters.


                          Nic
                        • Nic
                          ... Surely MOVE could NEVER be RESTfull. How could MOVE ever be about representational state transfer? Nic
                          Message 12 of 24 , Apr 11, 2006
                          • 0 Attachment
                            Julian Reschke <julian.reschke@...> writes:

                            > That seems to be a problem with the concept of moving resources around,
                            > not with the actual definition of the MOVE method, right?

                            Surely MOVE could NEVER be RESTfull.

                            How could MOVE ever be about representational state transfer?


                            Nic
                          • Roy T. Fielding
                            ... They are all in the archives Julian. WebDAV is history and my only interest in it is for legacy support. ... No, it is a problem with specifying multiple
                            Message 13 of 24 , Apr 11, 2006
                            • 0 Attachment
                              On Apr 11, 2006, at 12:57 PM, Julian Reschke wrote:

                              > As for the remainder, I'm really not sure what you're talking about
                              > (more details, please). For instance, RFC3253 (Versioning)
                              > introduces separate URIs for version histories and versions (basic
                              > versioning).

                              They are all in the archives Julian. WebDAV is history and my only
                              interest in it is for legacy support.

                              >> ...
                              >> The problem with MOVE is that it is actually an operation on two
                              >> independent namespaces (the source collection and destination
                              >> collection). The user must have permission to remove from the
                              >> source collection and add to the destination collection, which
                              >> can be a bit of a problem if they are in different authentication
                              >> realms. COPY has a similar problem, but at least in that case
                              >> only one namespace is modified. I don't think either of them map
                              >> very well to HTTP.
                              >> ...
                              >
                              > That seems to be a problem with the concept of moving resources
                              > around, not with the actual definition of the MOVE method, right?

                              No, it is a problem with specifying multiple arguments when both the
                              syntax and the access control mechanism assume there is only one.
                              It doesn't quite fit in the original HTTP syntax.

                              ....Roy
                            • Benjamin Carlyle
                              ... Others have already made most of the salient points on the WebDAV issue, however for my money the main one is this: WebDAV was designed as a distributed
                              Message 14 of 24 , Apr 11, 2006
                              • 0 Attachment
                                On Tue, 2006-04-11 at 09:09 -0700, Elias Sinderson wrote:
                                > This has been, to some extent, a personal crusade of mine -- to get
                                > people to realize that REST is more than GET, PUT, POST and DELETE.
                                > There are other methods available whendeveloping REST applications
                                > within the framework of the Web; MOVE, COPY and MKCOL for namespace
                                > operations, PROPPATCH and PROPFIND for working with resource metadata,
                                > LOCK and UNLOCK for managing access to resources, etc.

                                Others have already made most of the salient points on the WebDAV issue,
                                however for my money the main one is this: WebDAV was designed as a
                                distributed authoring protcol that works as part of or alongside the
                                web, however wikis do not use WebDAV. It turns out that WebDAV is not
                                required to do distributed authoring, and its complexity means that it
                                is not sufficient to do distributed authoring. In practice the web does
                                perfectly well without COPY, MOVE, and even LOCK. They might appear on
                                cursary analysis to be required, but we have plenty of existence proofs
                                on the web today that they are not. The WebDAV of today is little more
                                than an NFS alternative with little relationship to the web at large.

                                I am an advocate of not dogmatically sticking to the classic four
                                verbs[1][2][3]. I think there are cases where it is useful to try and
                                extend the verb set in order to add new features to HTTP. I am, however,
                                a believer in using the verbs we have in use today wherever they are
                                applicable. In the end, almost all new features will be able to collapse
                                down into the standard cut-and-paste verbs.

                                Benjamin
                                [1] http://soundadvice.id.au/blog/2005/08/27#httpFunctionCall
                                [2] http://soundadvice.id.au/blog/2005/08/30#arbitraryMethods
                                [3] http://soundadvice.id.au/blog/2006/04/03#loHiREST
                              • Julian Reschke
                                ... Works quite nice, at least in IE and Firefox. ... Dunno. ... That does DELETE, but not MOVE???? ... Best regards, Julian
                                Message 15 of 24 , Apr 11, 2006
                                • 0 Attachment
                                  Nic wrote:
                                  > Julian Reschke <julian.reschke@...> writes:
                                  >
                                  >> Nic wrote:
                                  >>> Elias Sinderson <elias@...> writes:
                                  >>>
                                  >>>> It is unclear to me why someone would advocate the use of DELETE (over
                                  >>>> POST as DELETE) but caution against the use of MOVE
                                  >>> Because DELETE is supported by nearlly *all* the available HTTP
                                  >>> clients and MOVE is not. It is nonsensical to argue that a WEBDAV
                                  >>> based web service would be as widely available as an RFC2616 service.
                                  >>>
                                  >>> It's easy for a client to use DELETE. It's not easy for a client to
                                  >>> use MOVE.
                                  >>> ...
                                  >>
                                  >> Interesting. Could you elaborate a bit? Which client or framework does
                                  >> allow you to use DELETE, but not MOVE?
                                  >
                                  > AJAX.

                                  Works quite nice, at least in IE and Firefox.

                                  > python's urllib

                                  Dunno.

                                  > Java's URL/URLConnection

                                  That does DELETE, but not MOVE????

                                  > For starters.

                                  Best regards, Julian
                                • Julian Reschke
                                  ... Well, in the last years I went through the archives several times, and never found a complete proposal that would actually cover those use cases that
                                  Message 16 of 24 , Apr 11, 2006
                                  • 0 Attachment
                                    Roy T. Fielding wrote:
                                    > On Apr 11, 2006, at 12:57 PM, Julian Reschke wrote:
                                    >
                                    >> As for the remainder, I'm really not sure what you're talking about
                                    >> (more details, please). For instance, RFC3253 (Versioning)
                                    >> introduces separate URIs for version histories and versions (basic
                                    >> versioning).
                                    >
                                    > They are all in the archives Julian. WebDAV is history and my only
                                    > interest in it is for legacy support.

                                    Well, in the last years I went through the archives several times, and
                                    never found a complete proposal that would actually cover those use
                                    cases that PROPFIND and PROPPATCH try to solve (and do solve, for that
                                    matter). So if anybody can provide a pointer, I'd be really be interested.

                                    >>> ...
                                    >>> The problem with MOVE is that it is actually an operation on two
                                    >>> independent namespaces (the source collection and destination
                                    >>> collection). The user must have permission to remove from the
                                    >>> source collection and add to the destination collection, which
                                    >>> can be a bit of a problem if they are in different authentication
                                    >>> realms. COPY has a similar problem, but at least in that case
                                    >>> only one namespace is modified. I don't think either of them map
                                    >>> very well to HTTP.
                                    >>> ...
                                    >> That seems to be a problem with the concept of moving resources
                                    >> around, not with the actual definition of the MOVE method, right?
                                    >
                                    > No, it is a problem with specifying multiple arguments when both the
                                    > syntax and the access control mechanism assume there is only one.
                                    > It doesn't quite fit in the original HTTP syntax.

                                    That's correct. So are you suggesting that there's a way to model a move
                                    operation without specifying two arguments that should have been used to
                                    define a MOVE-like method?

                                    Best regards, Julian
                                  • Julian Reschke
                                    ... The same applies to DELETE, OPTIONS or TRACE, right? Best regards, Julian
                                    Message 17 of 24 , Apr 11, 2006
                                    • 0 Attachment
                                      Nic wrote:
                                      > Julian Reschke <julian.reschke@...> writes:
                                      >
                                      >> That seems to be a problem with the concept of moving resources around,
                                      >> not with the actual definition of the MOVE method, right?
                                      >
                                      > Surely MOVE could NEVER be RESTfull.
                                      >
                                      > How could MOVE ever be about representational state transfer?

                                      The same applies to DELETE, OPTIONS or TRACE, right?

                                      Best regards, Julian
                                    • Nic
                                      ... TRACE maybe. But how many applications do you know involving TRACE? AFAIK DELETE has well known REST semantics. Whereas MOVE is an atomic back end
                                      Message 18 of 24 , Apr 12, 2006
                                      • 0 Attachment
                                        Julian Reschke <julian.reschke@...> writes:

                                        > Nic wrote:
                                        >> Julian Reschke <julian.reschke@...> writes:
                                        >>
                                        >>> That seems to be a problem with the concept of moving resources around,
                                        >>> not with the actual definition of the MOVE method, right?
                                        >>
                                        >> Surely MOVE could NEVER be RESTfull.
                                        >>
                                        >> How could MOVE ever be about representational state transfer?
                                        >
                                        > The same applies to DELETE, OPTIONS or TRACE, right?

                                        TRACE maybe. But how many applications do you know involving TRACE?

                                        AFAIK DELETE has well known REST semantics.

                                        Whereas MOVE is an atomic back end operation.


                                        Nic
                                      • Nic
                                        ... And proxies? And other intermediaries? And so on and so on.... I m not saying that DELETE is widespread... but it s more widespread than WEBDAV. Nic
                                        Message 19 of 24 , Apr 12, 2006
                                        • 0 Attachment
                                          Julian Reschke <julian.reschke@...> writes:

                                          > Nic wrote:
                                          >> Julian Reschke <julian.reschke@...> writes:
                                          >>
                                          >>> Nic wrote:
                                          >>>> Elias Sinderson <elias@...> writes:
                                          >>>>
                                          >>>>> It is unclear to me why someone would advocate the use of DELETE (over
                                          >>>>> POST as DELETE) but caution against the use of MOVE
                                          >>>> Because DELETE is supported by nearlly *all* the available HTTP
                                          >>>> clients and MOVE is not. It is nonsensical to argue that a WEBDAV
                                          >>>> based web service would be as widely available as an RFC2616 service.
                                          >>>>
                                          >>>> It's easy for a client to use DELETE. It's not easy for a client to
                                          >>>> use MOVE.
                                          >>>> ...
                                          >>>
                                          >>> Interesting. Could you elaborate a bit? Which client or framework does
                                          >>> allow you to use DELETE, but not MOVE?
                                          >>
                                          >> AJAX.
                                          >
                                          > Works quite nice, at least in IE and Firefox.
                                          >
                                          >> python's urllib
                                          >
                                          > Dunno.
                                          >
                                          >> Java's URL/URLConnection
                                          >
                                          > That does DELETE, but not MOVE????

                                          And proxies? And other intermediaries? And so on and so on....

                                          I'm not saying that DELETE is widespread... but it's more widespread
                                          than WEBDAV.


                                          Nic
                                        • Julian Reschke
                                          ... I m not sure what your point is. So now you re saying that there are intermediaries that do not support methods not in RFC2616. That may be true, and it
                                          Message 20 of 24 , Apr 12, 2006
                                          • 0 Attachment
                                            Nic wrote:
                                            > And proxies? And other intermediaries? And so on and so on....

                                            I'm not sure what your point is. So now you're saying that there are
                                            intermediaries that do not support methods not in RFC2616. That may be
                                            true, and it certainly was a few years ago.

                                            It seems that you're ignoring the fact that WebDAV indeed *is* widely
                                            deployed, and people are happily using it (Hotmail, OWA, Apple iDisk, MS
                                            Webfolders, ...). So yes, there may be deployment problems because of
                                            the new verbs, but as far as I can tell, they aren't significant as of 2006.

                                            > ...

                                            Best regards, Julian
                                          • Roy T. Fielding
                                            ... The only thing that recursive PROPFIND is used for within actual webdav applications is directory listings. Those are better implemented as a single
                                            Message 21 of 24 , Apr 12, 2006
                                            • 0 Attachment
                                              On Apr 11, 2006, at 4:15 PM, Julian Reschke wrote:

                                              > Well, in the last years I went through the archives several times, and
                                              > never found a complete proposal that would actually cover those use
                                              > cases that PROPFIND and PROPPATCH try to solve (and do solve, for that
                                              > matter). So if anybody can provide a pointer, I'd be really be
                                              > interested.

                                              The only thing that recursive PROPFIND is used for within actual
                                              webdav applications is directory listings. Those are better implemented
                                              as a single resource that is defined by the collection itself, and
                                              whose representation(s) are available at a distinct URI.

                                              The most recent reference you are looking for is

                                              http://xent.com/pipermail/fork/2001-August/003191.html

                                              with particular attention to the second-to-last paragraph.

                                              Most of the other discussion was at the Xerox PARC and UCI f2f
                                              meetings. WebDAV made certain choices and is limited to Save As
                                              dialogs because of them. WebDAV discussions are hopeless because
                                              the WebDAV specifications redefined the meaning of resource to be
                                              the same as file, thereby failing to handle the interesting cases
                                              of Web authoring in favor of duplicating FTP.

                                              >>> That seems to be a problem with the concept of moving resources
                                              >>> around, not with the actual definition of the MOVE method, right?
                                              >>
                                              >> No, it is a problem with specifying multiple arguments when both the
                                              >> syntax and the access control mechanism assume there is only one.
                                              >> It doesn't quite fit in the original HTTP syntax.
                                              >
                                              > That's correct. So are you suggesting that there's a way to model a
                                              > move
                                              > operation without specifying two arguments that should have been
                                              > used to
                                              > define a MOVE-like method?

                                              No. It is possible to do so by exchanging representations of the
                                              before and after hierarchy, but I am not saying it should have been
                                              done that way. I was only saying that WebDAV failed to consider the
                                              implications of how that change in method semantics impacts the rest
                                              of the HTTP model (particularly, access control and how to express
                                              partial failure conditions).

                                              WebDAV is history. The only interesting discussion is how much,
                                              if anything, should be recovered from it when a replacement is
                                              designed. Almost all of WebDAV's design rationales -- so-called
                                              performance issues -- are obsolete as soon as the message syntax
                                              is no longer MIME. What is the actual design rationale for locking
                                              (hint: it isn't the lost update problem)? What resource is it
                                              that WebDAV clients are actually looking for when they do recursive
                                              PROPFIND requests? Where should namespace operations be targeted?
                                              Those are interesting questions.

                                              ....Roy
                                            • Jerome Louvel
                                              ... Has there been any progress on WAKA since your last presentation? http://gbiv.com/protocols/waka/ I think it would be great to get this protocol
                                              Message 22 of 24 , Apr 13, 2006
                                              • 0 Attachment
                                                Roy T. Fielding wrote:
                                                > The problem with MOVE is that it is actually an operation on two
                                                > independent namespaces (the source collection and destination
                                                > collection). The user must have permission to remove from the
                                                > source collection and add to the destination collection, which
                                                > can be a bit of a problem if they are in different authentication
                                                > realms. COPY has a similar problem, but at least in that case
                                                > only one namespace is modified. I don't think either of them map
                                                > very well to HTTP.
                                                >
                                                > Tease: Any method in waka can have 0|1|2|N-arguments.

                                                Has there been any progress on WAKA since your last presentation?
                                                http://gbiv.com/protocols/waka/

                                                I think it would be great to get this protocol proposition moving
                                                forward so we could start experimenting all the REST ideas discussed in
                                                this list.

                                                --
                                                Jerome Louvel
                                                http://www.restlet.org
                                              Your message has been successfully submitted and would be delivered to recipients shortly.