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

Restlet presentation slides

Expand Messages
  • Jérôme Louvel
    Hi all, Last week, Sean Landis made a very nice presentation about REST and the Restlet project at the Utah Java Users Group. The slides as well as the sample
    Message 1 of 22 , Mar 20, 2007
    • 0 Attachment
      Hi all,

      Last week, Sean Landis made a very nice presentation about REST and
      the Restlet project at the Utah Java Users Group. The slides as well
      as the sample code are publicly available on our Wiki:
      http://wiki.restlet.org/#Presentations

      Direct link to PowerPoint slides:
      http://restlet.tigris.org/files/documents/3375/36973/Restlet.pps

      Best regards,
      Jerome Louvel
      --
      http://www.restlet.org
    • Mike Dierken
      Minor note PUT = Create a resource Using create can be confusing - perhaps set the state of a resource is better. The reason create can be confusing is
      Message 2 of 22 , Mar 20, 2007
      • 0 Attachment
        Minor note
        PUT = Create a resource

        Using 'create' can be confusing - perhaps 'set the state' of a resource is
        better.
        The reason 'create' can be confusing is that folks may assume a PUT to a
        pre-existing resource would be an error, when it isn't an error to set the
        state of a pre-existing resource.

        > -----Original Message-----
        > From: rest-discuss@yahoogroups.com
        > [mailto:rest-discuss@yahoogroups.com] On Behalf Of Jérôme Louvel
        > Sent: Tuesday, March 20, 2007 4:19 AM
        > To: rest-discuss@yahoogroups.com
        > Subject: [rest-discuss] Restlet presentation slides
        >
        > Hi all,
        >
        > Last week, Sean Landis made a very nice presentation about
        > REST and the Restlet project at the Utah Java Users Group.
        > The slides as well as the sample code are publicly available
        > on our Wiki:
        > http://wiki.restlet.org/#Presentations
        >
        > Direct link to PowerPoint slides:
        > http://restlet.tigris.org/files/documents/3375/36973/Restlet.pps
        >
        > Best regards,
        > Jerome Louvel
        > --
        > http://www.restlet.org
        >
        >
        >
        > ------------------------ Yahoo! Groups Sponsor
        > --------------------~--> Check out the new improvements in
        > Yahoo! Groups email.
        > http://us.click.yahoo.com/4It09A/fOaOAA/yQLSAA/W6uqlB/TM
        > --------------------------------------------------------------
        > ------~->
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
      • Dave Pawson
        ... I d confuse that exactly the opposite way! It must exist to have a state to change? I found the slides refreshingly clear. regards -- Dave Pawson XSLT
        Message 3 of 22 , Mar 21, 2007
        • 0 Attachment
          > Minor note
          > PUT = Create a resource
          >
          > Using 'create' can be confusing - perhaps 'set the state' of a resource is
          > better.
          > The reason 'create' can be confusing is that folks may assume a PUT to a
          > pre-existing resource would be an error, when it isn't an error to set the
          > state of a pre-existing resource.

          I'd confuse that exactly the opposite way! It must exist to have a
          state to change?

          I found the slides refreshingly clear.

          regards
          --
          Dave Pawson
          XSLT XSL-FO FAQ.
          http://www.dpawson.co.uk
        • Alan Dean
          ... I think of PUT as set whole resource (which is obviously valid whether the resource pre-exists or not) and POST as either append to resource or append
          Message 4 of 22 , Mar 21, 2007
          • 0 Attachment
            On 20 Mar 2007 19:29:52 -0700, Mike Dierken <dierken@...> wrote:
            >
            > Minor note
            > PUT = Create a resource
            >
            > Using 'create' can be confusing - perhaps 'set the state' of a resource is
            > better.
            > The reason 'create' can be confusing is that folks may assume a PUT to a
            > pre-existing resource would be an error, when it isn't an error to set the
            > state of a pre-existing resource.

            I think of PUT as "set whole resource" (which is obviously valid
            whether the resource pre-exists or not) and POST as either "append to
            resource" or "append new child (aka subordinate resource) to resource"
            where the append may or may not be permitted, depending upon the
            server.

            So, yes, simply saying "create" could be confusing if the audience
            doesn't already hold a mental model of what RESTfulness is.

            Alan Dean
            http://thoughtpad.net/who/alan-dean/
          • Stefan Tilkov
            Slide 13 has the following: GET – retrieve a resource PUT – create a resource POST – update (create if necessary) a resource DELETE – delete a resource
            Message 5 of 22 , Mar 21, 2007
            • 0 Attachment
              Slide 13 has the following:

              GET – retrieve a resource
              PUT – create a resource
              POST – update (create if necessary) a resource
              DELETE – delete a resource

              I don't particularly like the CRUD analogy anyway, but if it's used
              at all, I believe PUT and POST should be swapped.

              Stefan
              --
              Stefan Tilkov, http://www.innoq.com/blog/st/



              On Mar 21, 2007, at 9:04 AM, Dave Pawson wrote:

              > > Minor note
              > > PUT = Create a resource
              > >
              > > Using 'create' can be confusing - perhaps 'set the state' of a
              > resource is
              > > better.
              > > The reason 'create' can be confusing is that folks may assume a
              > PUT to a
              > > pre-existing resource would be an error, when it isn't an error
              > to set the
              > > state of a pre-existing resource.
              >
              > I'd confuse that exactly the opposite way! It must exist to have a
              > state to change?
              >
              > I found the slides refreshingly clear.
              >
              > regards
              > --
              > Dave Pawson
              > XSLT XSL-FO FAQ.
              > http://www.dpawson.co.uk
              >
              >
            • Alan Dean
              ... Interestingly, I have been having a discussion with Steve Maine on a very similar subject after his blog entry Musings on PUT and POST here
              Message 6 of 22 , Mar 21, 2007
              • 0 Attachment
                On 3/21/07, Stefan Tilkov <stefan.tilkov@...> wrote:
                > Slide 13 has the following:
                >
                > GET – retrieve a resource
                > PUT – create a resource
                > POST – update (create if necessary) a resource
                > DELETE – delete a resource
                >
                > I don't particularly like the CRUD analogy anyway, but if it's used
                > at all, I believe PUT and POST should be swapped.

                Interestingly, I have been having a discussion with Steve Maine on a
                very similar subject after his blog entry "Musings on PUT and POST"
                here http://hyperthink.net/blog/2007/03/15/Musings+On+PUT+And+POST.aspx

                He regards himself as a "POST purist" and feels that POST should be
                used for creation, not PUT.

                APP takes the same stance too, see
                http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-14.html#post-to-create

                I have to say that I don't see it that way. Here is an excerpt of my
                conversation with Steve:

                [quote]

                I am going to agree with one aspect what you are saying Steve - namely
                that the SQL analogy is a red herring.

                However, I am going to disagree with the thrust of the statement that
                "reducing PUT to bitblt() is a pretty limiting view of HTTP."

                (This disagreement assumes that I have understood what you are trying
                to say, of course).

                As far as I am concerned, an HTTP PUT is a "full representation create
                / overwrite". This is based upon RFC2616, which states that "The PUT
                method requests that the enclosed entity be stored under the supplied
                Request-URI." and explicitly that "If the Request-URI refers to an
                already existing resource, the enclosed entity SHOULD be considered as
                a modified version of the one residing on the origin server."

                Please see http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6

                I believe that this is not a "partial representation operation", but a
                "whole representation operation". What separates HTTP PUT from SQL
                INSERT / UPDATE is that the Content-Type of the representation can be
                dynamic, if the server chooses. For example, a server may accept a
                representation of type text/xml or application/xml. Or maybe a
                specific xml type, such as application/atom+xml. This is
                uncontroversial, but it may also choose to accept an entirely
                different type and internally handle the necessary transformation to
                the desired type.

                Moving onto HTTP POST. RFC2616 states that "The POST method is used to
                request that the origin server accept the entity enclosed in the
                request as a new subordinate of the resource identified by the
                Request-URI in the Request-Line." For me, the key word there is
                'subordinate'. This means that, unlike PUT, POST is a "partial
                representation operation".

                Please see http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5

                Note that both PUT and POST can redirect the user-agent after the operation:

                PUT = "If the server desires that the request be applied to a
                different URI, it MUST send a 301 (Moved Permanently) response; the
                user agent MAY then make its own decision regarding whether or not to
                redirect the request."

                POST = "the 303 (See Other) response can be used to direct the user
                agent to retrieve a cacheable resource."

                [end-quote]

                Alan Dean
                http://thoughtpad.net/who/alan-dean/
              • Alexander Johannesen
                ... I tend to agree; PUT can be used that way. I think it boils down to ; - if you know an identified resource, use PUT for creation and full update - if you
                Message 7 of 22 , Mar 21, 2007
                • 0 Attachment
                  On 3/21/07, Alan Dean <alan.dean@...> wrote:
                  > He regards himself as a "POST purist" and feels that POST should be
                  > used for creation, not PUT.

                  I tend to agree; PUT can be used that way. I think it boils down to ;

                  - if you know an identified resource, use PUT for creation and full update
                  - if you only know its "container" or don't know the created resources
                  identity (real or virtual), use POST for creation

                  > APP takes the same stance too, see
                  > http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-14.html#post-to-create

                  Yeah, there's been a flurry of activity on the APP mailing-list of
                  late. I think a lot of the miscommunication in this area comes down to
                  wheter your resource id is known or unknown. I tend to think of POST
                  as when I need to ask questions (when I don't know the URI of the
                  resource in question), while with the REST I "know" what I'm doing
                  (specific URI's). The typical example is ;

                  Already knows the user_id
                  --------------------------------------
                  /user/{user_id}
                  GET /user/1234 --> 404
                  PUT /user/1234 ?data --> 200
                  GET /user/1234 --> 200

                  Don't know what user_id to pass in
                  --------------------------------------------------
                  /user
                  GET /user --> 200 + list representation
                  POST /user ?data --> 200 + user representation (with "user_id=1234")
                  PUT /user/1234 ?data --> 200


                  Alex
                  --
                  ---------------------------------------------------------------------------
                  Project Wrangler, SOA, Information Alchymist, UX, RESTafarian, Topic Maps
                  ------------------------------------------ http://shelter.nu/blog/ --------
                • Jon Hanna
                  ... GET - Retrieve information about resource PUT - Update (create if necessary) a resource DELETE - Delete a resource POST - Have a resource process another
                  Message 8 of 22 , Mar 21, 2007
                  • 0 Attachment
                    Stefan Tilkov wrote:
                    > Slide 13 has the following:
                    >
                    > GET – retrieve a resource
                    > PUT – create a resource
                    > POST – update (create if necessary) a resource
                    > DELETE – delete a resource
                    >
                    > I don't particularly like the CRUD analogy anyway, but if it's used
                    > at all, I believe PUT and POST should be swapped.

                    GET - Retrieve information about resource
                    PUT - Update (create if necessary) a resource
                    DELETE - Delete a resource
                    POST - Have a resource process another (possibly null) resource and
                    retrieve either the results of that, or information about a resource
                    that was updated or created as a result. This can include duplicating
                    the functionality of the three other verbs, though unless there is a
                    good reason for doing this it is probably indicative of poor design.

                    Not as snappy as forcing an analogy to CRUD, I'll admit.
                  • Jon Hanna
                    ... Though it s not that far away from CRUDE.
                    Message 9 of 22 , Mar 21, 2007
                    • 0 Attachment
                      Jon Hanna wrote:
                      > Not as snappy as forcing an analogy to CRUD, I'll admit.

                      Though it's not that far away from CRUDE.
                    • Stefan Tilkov
                      ... +1. Exactly my view (and as far as I can tell, the majority RESTian opinion). Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/
                      Message 10 of 22 , Mar 21, 2007
                      • 0 Attachment
                        On Mar 21, 2007, at 11:46 AM, Jon Hanna wrote:

                        > GET - Retrieve information about resource
                        > PUT - Update (create if necessary) a resource
                        > DELETE - Delete a resource
                        > POST - Have a resource process another (possibly null) resource and
                        > retrieve either the results of that, or information about a resource
                        > that was updated or created as a result. This can include duplicating
                        > the functionality of the three other verbs, though unless there is a
                        > good reason for doing this it is probably indicative of poor design.

                        +1. Exactly my view (and as far as I can tell, the majority RESTian
                        opinion).

                        Stefan
                        --
                        Stefan Tilkov, http://www.innoq.com/blog/st/
                      • Chris Burdess
                        ... Perhaps snappier: GET - Retrieve representation of resource PUT - Update (create if necessary) a resource with the given representation DELETE - Delete a
                        Message 11 of 22 , Mar 21, 2007
                        • 0 Attachment
                          Jon Hanna wrote:
                          > Stefan Tilkov wrote:
                          >> Slide 13 has the following:
                          >>
                          >> GET – retrieve a resource
                          >> PUT – create a resource
                          >> POST – update (create if necessary) a resource
                          >> DELETE – delete a resource
                          >>
                          >> I don't particularly like the CRUD analogy anyway, but if it's used
                          >> at all, I believe PUT and POST should be swapped.
                          >
                          > GET - Retrieve information about resource
                          > PUT - Update (create if necessary) a resource
                          > DELETE - Delete a resource
                          > POST - Have a resource process another (possibly null) resource and
                          > retrieve either the results of that, or information about a resource
                          > that was updated or created as a result. This can include duplicating
                          > the functionality of the three other verbs, though unless there is a
                          > good reason for doing this it is probably indicative of poor design.
                          >
                          > Not as snappy as forcing an analogy to CRUD, I'll admit.

                          Perhaps snappier:

                          GET - Retrieve representation of resource
                          PUT - Update (create if necessary) a resource with the given
                          representation
                          DELETE - Delete a resource
                          POST - Do something, possibly based on the given representation
                        • Jan Algermissen
                          Hi, maybe this is of interest: http://www.markbaker.ca/2001/09/draft-baker-http-resource-state- model-01.txt ...not directly related but mentioned far too
                          Message 12 of 22 , Mar 21, 2007
                          • 0 Attachment
                            Hi,

                            maybe this is of interest:

                            http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-
                            model-01.txt

                            ...not directly related but mentioned far too seldom, IMO.

                            Jan



                            On 21.03.2007, at 10:56, Stefan Tilkov wrote:

                            > Slide 13 has the following:
                            >
                            > GET – retrieve a resource
                            > PUT – create a resource
                            > POST – update (create if necessary) a resource
                            > DELETE – delete a resource
                            >
                            > I don't particularly like the CRUD analogy anyway, but if it's used
                            > at all, I believe PUT and POST should be swapped.
                            >
                            > Stefan
                            > --
                            > Stefan Tilkov, http://www.innoq.com/blog/st/
                            >
                            >
                            >
                            > On Mar 21, 2007, at 9:04 AM, Dave Pawson wrote:
                            >
                            >>> Minor note
                            >>> PUT = Create a resource
                            >>>
                            >>> Using 'create' can be confusing - perhaps 'set the state' of a
                            >> resource is
                            >>> better.
                            >>> The reason 'create' can be confusing is that folks may assume a
                            >> PUT to a
                            >>> pre-existing resource would be an error, when it isn't an error
                            >> to set the
                            >>> state of a pre-existing resource.
                            >>
                            >> I'd confuse that exactly the opposite way! It must exist to have a
                            >> state to change?
                            >>
                            >> I found the slides refreshingly clear.
                            >>
                            >> regards
                            >> --
                            >> Dave Pawson
                            >> XSLT XSL-FO FAQ.
                            >> http://www.dpawson.co.uk
                            >>
                            >>
                            >
                            >
                            >
                            >
                            > Yahoo! Groups Links
                            >
                            >
                            >
                          • Keith Gaughan
                            ... This is all down to server policy. If a server doesn t want a client to be able to create arbitrary resources without first going through, it can complain
                            Message 13 of 22 , Mar 21, 2007
                            • 0 Attachment
                              Alan Dean wrote:

                              > On 3/21/07, Stefan Tilkov <stefan.tilkov@...> wrote:
                              >> Slide 13 has the following:
                              >>
                              >> GET – retrieve a resource
                              >> PUT – create a resource
                              >> POST – update (create if necessary) a resource
                              >> DELETE – delete a resource
                              >>
                              >> I don't particularly like the CRUD analogy anyway, but if it's used
                              >> at all, I believe PUT and POST should be swapped.
                              >
                              > Interestingly, I have been having a discussion with Steve Maine on a
                              > very similar subject after his blog entry "Musings on PUT and POST"
                              > here http://hyperthink.net/blog/2007/03/15/Musings+On+PUT+And+POST.aspx
                              >
                              > He regards himself as a "POST purist" and feels that POST should be
                              > used for creation, not PUT.
                              >
                              > APP takes the same stance too, see
                              > http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-14.html#post-to-create
                              >
                              > I have to say that I don't see it that way. Here is an excerpt of my
                              > conversation with Steve:
                              >
                              > [quote]
                              >
                              > I am going to agree with one aspect what you are saying Steve - namely
                              > that the SQL analogy is a red herring.
                              >
                              > However, I am going to disagree with the thrust of the statement that
                              > "reducing PUT to bitblt() is a pretty limiting view of HTTP."

                              This is all down to server policy. If a server doesn't want a client to be
                              able to create arbitrary resources without first going through, it can
                              complain vehemently that the request is Forbidden along with an explanation
                              of why. That said, if it makes sense for the application running on the
                              server to allow clients to create resources with arbitrary URIs, all's well.

                              Purity is for schmucks. Unless there's a good reason why PUT shouldn't be
                              allowed create resources, the application should accept it.

                              K.
                            • Jon Hanna
                              ... Funny, I consider allowing PUT to be the purer form. Just goes to show how subjective purity is. A lesson for our modern pluralistic society :D
                              Message 14 of 22 , Mar 21, 2007
                              • 0 Attachment
                                Keith Gaughan wrote:
                                > Purity is for schmucks. Unless there's a good reason why PUT shouldn't be
                                > allowed create resources, the application should accept it.


                                Funny, I consider allowing PUT to be the purer form.

                                Just goes to show how subjective "purity" is. A lesson for our modern
                                pluralistic society :D
                              • Keith Gaughan
                                ... I d originally written PUT/POST purity is for schmucks , but thought it wasn t needed. I don t really think either is more pure myself: both have
                                Message 15 of 22 , Mar 21, 2007
                                • 0 Attachment
                                  Jon Hanna wrote:
                                  > Keith Gaughan wrote:
                                  >> Purity is for schmucks. Unless there's a good reason why PUT shouldn't be
                                  >> allowed create resources, the application should accept it.
                                  >
                                  > Funny, I consider allowing PUT to be the purer form.

                                  I'd originally written "PUT/POST purity is for schmucks", but thought it
                                  wasn't needed. I don't really think either is more "pure" myself: both have
                                  advantages and disadvantages depending on the application and constraints to
                                  be satisfied.

                                  K.
                                • Mike Dierken
                                  ... to change? But PUT isn t change the state - it s set the state. This means a non-existing resource now comes into existence. Another wrinkle with PUT
                                  Message 16 of 22 , Mar 21, 2007
                                  • 0 Attachment
                                    >
                                    > I'd confuse that exactly the opposite way! It must exist to have a state
                                    to change?
                                    But PUT isn't "change" the state - it's "set" the state. This means a
                                    'non-existing' resource now comes into existence.
                                    Another wrinkle with PUT is that for the URI, the client is the decider. And
                                    as we all know, a decider is just a tool.

                                    >
                                    > I found the slides refreshingly clear.
                                    I agree that the slides are helpful, this is just a minor point.
                                  • Elliotte Harold
                                    ... That s wrong. The message still isn t getting out so one more time: When creating a new resource use A. POST if the server chooses the URL B. PUT if the
                                    Message 17 of 22 , Mar 25, 2007
                                    • 0 Attachment
                                      Alan Dean wrote:

                                      > He regards himself as a "POST purist" and feels that POST should be
                                      > used for creation, not PUT.
                                      >

                                      That's wrong. The message still isn't getting out so one more time:

                                      When creating a new resource use

                                      A. POST if the server chooses the URL
                                      B. PUT if the client chooses the URL

                                      It is not as simple as "All creates must be done through POST" or "All
                                      creates must be done through PUT". SQL CRUD does not map onto REST in a
                                      1-1 fashion. See

                                      http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/

                                      --
                                      Elliotte Rusty Harold elharo@...
                                      Java I/O 2nd Edition Just Published!
                                      http://www.cafeaulait.org/books/javaio2/
                                      http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
                                    • Alan Dean
                                      ... I agree that the CRUD / SQL analogy is incomplete and a mismatch (bear in mind that I was referring to someone else s position in my quote). I personally
                                      Message 18 of 22 , Mar 25, 2007
                                      • 0 Attachment
                                        On 3/25/07, Elliotte Harold <elharo@...> wrote:
                                        > Alan Dean wrote:
                                        >
                                        > > He regards himself as a "POST purist" and feels that POST should be
                                        > > used for creation, not PUT.
                                        > >
                                        >
                                        > That's wrong. The message still isn't getting out so one more time:
                                        >
                                        > When creating a new resource use
                                        >
                                        > A. POST if the server chooses the URL
                                        > B. PUT if the client chooses the URL
                                        >
                                        > It is not as simple as "All creates must be done through POST" or "All
                                        > creates must be done through PUT". SQL CRUD does not map onto REST in a
                                        > 1-1 fashion.

                                        I agree that the CRUD / SQL analogy is incomplete and a mismatch (bear
                                        in mind that I was referring to someone else's position in my quote).

                                        I personally think in these terms:

                                        "When creating a whole resource, use PUT onto the target URL (ie the
                                        user-agent chooses the URL) and when creating a subordinate resource
                                        (aka append) use POST onto the intermediate URL (ie the server chooses
                                        the target URL)."

                                        Unfortunately, the Atom PP does not observe this pattern (at least, it
                                        doesn't as far as I can see) and I fear that this will lead to a
                                        division between 'RESTful' and 'REST-like' implementations that can
                                        only confuse the jobbing developer (just look at RSS1.0 (RDF) -vs-
                                        RSS2.0.

                                        Regards,
                                        Alan Dean
                                        http://thoughtpad.net/who/alan.dean/
                                      • Elliotte Harold
                                        ... There are some minor glitches in APP s RESTfulness, but I don;t think this is one of them. APP simply does not allow the client to choose the final URL for
                                        Message 19 of 22 , Mar 25, 2007
                                        • 0 Attachment
                                          Alan Dean wrote:

                                          > Unfortunately, the Atom PP does not observe this pattern (at least, it
                                          > doesn't as far as I can see) and I fear that this will lead to a
                                          > division between 'RESTful' and 'REST-like' implementations that can
                                          > only confuse the jobbing developer (just look at RSS1.0 (RDF) -vs-
                                          > RSS2.0.
                                          >

                                          There are some minor glitches in APP's RESTfulness, but I don;t think
                                          this is one of them. APP simply does not allow the client to choose the
                                          final URL for a new entry, ever. Consequently it never uses PUT to
                                          create a new entry. All entries have their initial URL assigned by the
                                          server.

                                          --
                                          Elliotte Rusty Harold elharo@...
                                          Java I/O 2nd Edition Just Published!
                                          http://www.cafeaulait.org/books/javaio2/
                                          http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
                                        • Brendan Taylor
                                          ... Just to clarify, it doesn t say that clients *can t* do that (or that servers can t allow them to), it s just not part of the core protocol.
                                          Message 20 of 22 , Mar 25, 2007
                                          • 0 Attachment
                                            On Sun, Mar 25, 2007 at 05:58:30PM -0400, Elliotte Harold wrote:
                                            > Alan Dean wrote:
                                            >
                                            > > Unfortunately, the Atom PP does not observe this pattern (at least, it
                                            > > doesn't as far as I can see) and I fear that this will lead to a
                                            > > division between 'RESTful' and 'REST-like' implementations that can
                                            > > only confuse the jobbing developer (just look at RSS1.0 (RDF) -vs-
                                            > > RSS2.0.
                                            > >
                                            >
                                            > There are some minor glitches in APP's RESTfulness, but I don;t think
                                            > this is one of them. APP simply does not allow the client to choose the
                                            > final URL for a new entry, ever.

                                            Just to clarify, it doesn't say that clients *can't* do that (or that
                                            servers can't allow them to), it's just not part of the core protocol.
                                          • Dave Pawson
                                            ... Perhaps that would make a good signature line for this list? Its becoming a perma thread. regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk
                                            Message 21 of 22 , Mar 25, 2007
                                            • 0 Attachment
                                              On 25 Mar 2007 13:36:18 -0700, Elliotte Harold <elharo@...> wrote:

                                              > That's wrong. The message still isn't getting out so one more time:
                                              >
                                              > When creating a new resource use
                                              >
                                              > A. POST if the server chooses the URL
                                              > B. PUT if the client chooses the URL

                                              Perhaps that would make a good signature line for this list?
                                              Its becoming a perma thread.

                                              regards

                                              --
                                              Dave Pawson
                                              XSLT XSL-FO FAQ.
                                              http://www.dpawson.co.uk
                                            • Stefan Tilkov
                                              ... That s just one, but not the only distinction, but as you write this is your personal view ... fine with me. ... This seems to create a problem where there
                                              Message 22 of 22 , Mar 26, 2007
                                              • 0 Attachment
                                                On Mar 25, 2007, at 10:51 PM, Alan Dean wrote:

                                                > I personally think in these terms:
                                                >
                                                > "When creating a whole resource, use PUT onto the target URL (ie the
                                                > user-agent chooses the URL) and when creating a subordinate resource
                                                > (aka append) use POST onto the intermediate URL (ie the server chooses
                                                > the target URL)."
                                                >

                                                That's just one, but not the only distinction, but as you write this
                                                is your personal view ... fine with me.

                                                > Unfortunately, the Atom PP does not observe this pattern (at least, it
                                                > doesn't as far as I can see) and I fear that this will lead to a
                                                > division between 'RESTful' and 'REST-like' implementations that can
                                                > only confuse the jobbing developer (just look at RSS1.0 (RDF) -vs-
                                                > RSS2.0.

                                                This seems to create a problem where there really is none. APP
                                                doesn't follow *your personal view*, but that doesn't mean it's
                                                unRESTful. Creating new resources via POST is perfectly fine,
                                                creating them via PUT is fine perfectly OK as well.

                                                PUT and POST are defined in RFC 2616. Having just re-read this again,
                                                I believe it strongly support Elliotte's POV.

                                                Stefan
                                                --
                                                Stefan Tilkov, http://www.innoq.com/blog/st/
                                              Your message has been successfully submitted and would be delivered to recipients shortly.