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

Re: [rest-discuss] POST/PUT to the same URI?

Expand Messages
  • Vincent D Murphy
    ... i haven t found a situation where it has made sense so far. it s a phenomenon i have observed in practice; i ve been meaning to ask rest-discuss but
    Message 1 of 7 , Dec 1, 2002
    • 0 Attachment
      Seairth Jacobs wrote:
      > Can anyone think of a reason (and possibly example) why you would use PUT
      > and POST on the same URI? Does such a thing even make sense?

      i haven't found a situation where it has made sense so far. it's a
      phenomenon i have observed in practice; i've been meaning to ask
      rest-discuss but hadn't got around to it.

      i think this is because most of the time when you would want to POST to
      a resource that you can already PUT to (e.g. /accounts/[id]), you are
      probably better off POSTing to a 'sub-resource' which is a collection
      instead (e.g. /accounts/[id]/withdrawals). (cf. my post from yesterday.)

      i have used this fact to implement a browser workaround or hack.
      Because browsers can't send PUT, e.g. as the method of a form submit, I
      'pre-process' the request at the server so that the POST is changed to a
      PUT. i then continue with processing as normal. this means I can use
      the same code for browsers and machine clients (modulo differences
      between representations, but i'm working on seperating that concern
      cleanly as well, and joe gregorio has already done a nice job with
      RESTlog). it also means that i can support PUT operations using HTML
      forms, which is important for my app.

      when i saw REST first i wondered, "but how the hell can REST work when
      browsers don't send PUT"? (using client-side XMLHttpRequest-ish objects
      doesn't count, IMO.) but it seems to be mostly a non-issue because you
      can effectively overload the semantics of POST to include PUT for broken
      user agents, depending on the URI in question.
    • Paul Prescod
      ... Let s say a URI represents a log for a chat session. PUT would overwrite the log and start again. POST would add some text to the bottom. Paul Prescod
      Message 2 of 7 , Dec 1, 2002
      • 0 Attachment
        Seairth Jacobs wrote:

        > Can anyone think of a reason (and possibly example) why you would use PUT
        > and POST on the same URI? Does such a thing even make sense?

        Let's say a URI represents a log for a chat session. PUT would overwrite
        the log and start again. POST would add some text to the bottom.

        Paul Prescod
      • Julian Reschke
        ... I can image an authorable server that lets you create POST-accepting-resources using PUT (for instance, followed by a PROPPATCH setting some
        Message 3 of 7 , Dec 1, 2002
        • 0 Attachment
          > From: Seairth Jacobs [mailto:seairth@...]
          > Sent: Sunday, December 01, 2002 2:50 AM
          > To: rest-discuss
          > Subject: [rest-discuss] POST/PUT to the same URI?
          >
          >
          > Can anyone think of a reason (and possibly example) why you would use PUT
          > and POST on the same URI? Does such a thing even make sense?

          I can image an authorable server that lets you create
          POST-accepting-resources using PUT (for instance, followed by a PROPPATCH
          setting some server-internal live properties that make the already existing
          "plain" resource an acceptor for POSTs).

          Julian

          --
          <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
        • Philip Eskelin
          ... Here is another example: one user POSTs a representation of an empty container resource named b to the container resource at /a, then POSTs
          Message 4 of 7 , Dec 2, 2002
          • 0 Attachment
            Paul Prescod wrote:
            > Seairth Jacobs wrote:
            >
            > > Can anyone think of a reason (and possibly
            > > example) why you would use PUT and POST on the
            > > same URI? Does such a thing even make sense?
            >
            > Let's say a URI represents a log for a chat session.
            > PUT would overwrite the log and start again. POST
            > would add some text to the bottom.

            Here is another example: one user POSTs a
            representation of an empty container resource named
            'b' to the container resource at /a, then POSTs
            representations of new resources named 'c' and 'd' to
            /a/b.
            1. POST to /a representation of b
            2. POST to /a/b representation of c
            3. POST to /a/b representation of d

            Another user might take care of the whole thing in one
            PUT request by sending a representation of a container
            resource named b, with its subordinates c and d
            already POSTed to it, into the container resource at
            /a.
            1. POST to b representation of c
            2. POST to b representation of d
            3. PUT to /a/b representation of b

            This shows that POST and PUT can happen to the same
            URI. The first user POSTed representations of c and d
            to /a/b. Yet in the second case b was PUT to /a/b
            with c and d already POSTed to it. In both cases new
            resources will exist at /a/b, /a/b/c and /a/b/d.

            Philip

            __________________________________________________
            Do you Yahoo!?
            Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
            http://mailplus.yahoo.com
          • Mathews, Walden
            ... There s something a little strange going on here. How can the b of the PUT (a representation) have had things POSTed to it? POST is defined as a
            Message 5 of 7 , Dec 2, 2002
            • 0 Attachment
              > This shows that POST and PUT can happen to the same
              > URI. The first user POSTed representations of c and d
              > to /a/b. Yet in the second case b was PUT to /a/b
              > with c and d already POSTed to it. In both cases new
              > resources will exist at /a/b, /a/b/c and /a/b/d.
              >
              > Philip
              >

              There's something a little strange going on here. How can
              the 'b' of the PUT (a representation) have had things POSTed
              to it? POST is defined as a resource method, not a way to
              compose representations. Do I miss the boat?

              Walden
            • Philip Eskelin
              ... Thanks for the question. For the second example you re asking about, I assumed the requestor created a resource with subordinates c and d, then a
              Message 6 of 7 , Dec 2, 2002
              • 0 Attachment
                Walden Mathews wrote:
                > > This shows that POST and PUT can happen to the
                > > same URI. The first user POSTed representations
                > > of c and d to /a/b. Yet in the second case b was
                > > PUT to /a/b with c and d already POSTed to it.
                > > In both cases new resources will exist at
                > > /a/b, /a/b/c and /a/b/d.
                >
                > There's something a little strange going on here.
                > How can the 'b' of the PUT (a representation) have
                > had things POSTed to it? POST is defined as a
                > resource method, not a way to compose
                > representations. Do I miss the boat?

                Thanks for the question. For the second example
                you're asking about, I assumed the requestor created a
                resource with subordinates c and d, then a
                representation of the whole thing was transferred to
                /a/b via PUT. But there's nothing stopping you from
                only constructing representations of b containing
                representations of c and d on the fly and transferring
                that instead.

                The difference between the two approaches is that you
                can either transfer representations taken from
                existing resources, or construct and transfer your own
                representations (e.g., telnet to the node and
                literally type out the PUT request and its XML)
                without relying on an existing (non-vacuous) resource.

                I've coded my toolkit project under this philosophy.
                Please let me know if there is a flaw in my thinking.

                Thanks,
                Philip

                __________________________________________________
                Do you Yahoo!?
                Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
                http://mailplus.yahoo.com
              Your message has been successfully submitted and would be delivered to recipients shortly.