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

Re: [rest-discuss] Bass-ackwards?

Expand Messages
  • Robert Sayre
    ... I was thinking about more about this, and seems like an error, or at least sloppy, to inentionally spec PUT this way, because the meaning of the client s
    Message 1 of 22 , May 15, 2007
    View Source
    • 0 Attachment
      On 5/15/07, Elliotte Harold <elharo@...> wrote:
      >
      > We've been through this in APP land recently without coming to
      > consensus. My continued belief (not shared by all) is that the specified
      > PUT request means state="off" and there is no temp value.

      I was thinking about more about this, and seems like an error, or at
      least sloppy, to inentionally spec PUT this way, because the meaning
      of the client's message is not clear. The MS stuff is really a patch
      format according to the docs. If the document

      <foo>
      <a>1</a>
      <b>2</b>
      <c>3</c>
      </foo>

      is retrieved from http://example.com/bar, it looks like you can update
      /b and /c in two ways.

      PUT /bar ...
      <foo>
      <a>10</a>
      <c>30</c>
      </foo>

      or

      PUT /bar/a ... 10
      PUT /bar/c ... 30

      There's a problem here, in that it becomes impossible to clearly
      request that an HTTP server save your patch somewhere, in case you
      don't want to apply it immediately. To ensure that you don't get bogus
      changes inserted in your patch, you need to wrap it, like

      <patch>
      <foo>
      <a>10</a>
      <c>30</c>
      </foo>
      </patch>

      and then the question becomes... why isn't the patch format like this
      in the first place, and sent using either PATCH or POST?
      --

      Robert Sayre

      "I would have written a shorter letter, but I did not have the time."
    • Elliotte Harold
      ... That;s an arguable point. Some people think it s OK for the origin server to do anything it wants with a PUT body and still return a 200 OK. Some people
      Message 2 of 22 , May 17, 2007
      View Source
      • 0 Attachment
        A. Pagaltzis wrote:

        > Obviously if the intermediary saw anything other than a 2xx, it
        > couldn’t cache the request body. But even if it did see a 2xx
        > response, the semantics of PUT (namely, that the origin server
        > may do anything it wants with the request body) would seem to
        > absolutely preclude caching by intermediaries.

        That;s an arguable point. Some people think it's OK for the origin
        server to do anything it wants with a PUT body and still return a 200
        OK. Some people think that's not acceptable. The semantics of PUT are
        not in consensus within the community.

        Given that some servers may change the body of the PUT because some
        developers believe that's OK, it is probably not safe for a cache to
        store a PUT body, whether that would be legal according to the spec or not.

        Perhaps cache-control headers in PUT responses could be used to clarify
        this? E.g. id the server is going to change the body it should send
        cache invalidating headers in the PUT response?

        --
        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/
      • Jon Hanna
        ... To my mind if a server understands a representation - rather than treating the entities as opaque and requiring a relatively agnostic storage in a
        Message 3 of 22 , May 17, 2007
        View Source
        • 0 Attachment
          Elliotte Harold wrote:
          > A. Pagaltzis wrote:
          >
          >> Obviously if the intermediary saw anything other than a 2xx, it
          >> couldn’t cache the request body. But even if it did see a 2xx
          >> response, the semantics of PUT (namely, that the origin server
          >> may do anything it wants with the request body) would seem to
          >> absolutely preclude caching by intermediaries.
          >
          > That;s an arguable point. Some people think it's OK for the origin
          > server to do anything it wants with a PUT body and still return a 200
          > OK. Some people think that's not acceptable. The semantics of PUT are
          > not in consensus within the community.

          To my mind if a server understands a representation - rather than
          treating the entities as opaque and requiring a relatively agnostic
          storage in a file-system - then it may act as interpretted.

          This can include updating other representations of the same resource so
          that all representations are synch'ed. This seems both a natural result
          of the fact that a single resource can have multiple representations
          (unless those multiple representations directly contradicting each other
          is seen as perfectly acceptable) and the only practical way of dealing
          with cases where the state of a resource is not internally modelled by
          "flat" storage of entities (I do not see it as practical for example to
          have to store the XML that was responsible for a change in a resource
          that can be altered by PUTting some XML to ensure that the same
          comments, namespace prefixes, encoding, and other
          implementation-dependant artefacts will be returned on GET).

          It could also to my mind - and here I'm no doubt going to be more
          controversial - mean an ammendment rather than a replace ONLY IF the
          entity received has something in it's syntax which means "Value for X
          unknown/unstated" in which case the server could take the value for X it
          already has and maintain it after the PUT.

          > Given that some servers may change the body of the PUT because some
          > developers believe that's OK, it is probably not safe for a cache to
          > store a PUT body, whether that would be legal according to the spec or not.
          >
          > Perhaps cache-control headers in PUT responses could be used to clarify
          > this? E.g. id the server is going to change the body it should send
          > cache invalidating headers in the PUT response?

          There's less ambiguity here:

          "If the request passes through a cache and the Request-URI identifies
          one or more currently cached entities, those entries SHOULD be treated
          as stale. Responses to this method are not cacheable." (RFC 2616 §9.6)

          Which tells us what cache's should do in this case. Notably it does
          indeed correspond with a situation where the server's reaction to a PUT
          is not to update the resource in such a way that a GET will return the
          same entity - the cache will merely clear it's records and not assume
          anything about what the server has done.
        Your message has been successfully submitted and would be delivered to recipients shortly.