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

PUT question

Expand Messages
  • Seairth Jacobs
    I am still unclear on something about PUT. Suppose I PUT the following: Value Now, suppose that an immediate GET returns:
    Message 1 of 10 , Dec 12, 2003
    • 0 Attachment
      I am still unclear on something about PUT. Suppose I PUT the following:


      <elem1>
      <elem2>Value</elem2>
      </elem1>

      Now, suppose that an immediate GET returns:

      <elem1>
      <elem2>Value</elem2>
      <elem3>Value2</elem3>
      </elem1>

      One additional constraint is that the client that did the PUT only
      understands/processes <elem1> and <elem2>, ignoring all others. As a
      result, the client's behavior for the PUT version and the GET version is
      exactly the same. Is this RESTful? Half of me says "yes" because the
      client doesn't see any difference between the two representations, and
      the other half says "no" because it isn't exactly the same (as a
      generalized xml document, ignoring byte-wise comparison).

      Thoughts?

      Seairth
    • Walden Mathews
      Seairth, A good way to answer this might be to list the constraints from the REST architecture which you feel may have been violated, with citations from the
      Message 2 of 10 , Dec 12, 2003
      • 0 Attachment
        Seairth,

        A good way to answer this might be to list the constraints from
        the REST architecture which you feel may have been violated,
        with citations from the architecture document itself [1]. Have you
        tried that?

        Thanks,
        Walden

        [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

        ----- Original Message -----
        From: "Seairth Jacobs" <seairth@...>
        To: "rest-discuss" <rest-discuss@yahoogroups.com>
        Sent: Friday, December 12, 2003 8:27 AM
        Subject: [rest-discuss] PUT question


        : I am still unclear on something about PUT. Suppose I PUT the following:
        :
        :
        : <elem1>
        : <elem2>Value</elem2>
        : </elem1>
        :
        : Now, suppose that an immediate GET returns:
        :
        : <elem1>
        : <elem2>Value</elem2>
        : <elem3>Value2</elem3>
        : </elem1>
        :
        : One additional constraint is that the client that did the PUT only
        : understands/processes <elem1> and <elem2>, ignoring all others. As a
        : result, the client's behavior for the PUT version and the GET version is
        : exactly the same. Is this RESTful? Half of me says "yes" because the
        : client doesn't see any difference between the two representations, and
        : the other half says "no" because it isn't exactly the same (as a
        : generalized xml document, ignoring byte-wise comparison).
        :
        : Thoughts?
        :
        : Seairth
        :
        :
        :
        : To unsubscribe from this group, send an email to:
        : rest-discuss-unsubscribe@yahoogroups.com
        :
        :
        :
        : Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        :
        :
        :
        : __________ NOD32 1.577 (20031211) Information __________
        :
        : This message was checked by NOD32 Antivirus System.
        : http://www.nod32.com
        :
        :
      • Mark Baker
        ... There s no guarantee, in general, that a PUT followed by a GET, even immediately , will return the same content. The content crossed a trust boundary;
        Message 3 of 10 , Dec 12, 2003
        • 0 Attachment
          On Fri, Dec 12, 2003 at 08:27:15AM -0500, Seairth Jacobs wrote:
          > I am still unclear on something about PUT. Suppose I PUT the following:
          >
          >
          > <elem1>
          > <elem2>Value</elem2>
          > </elem1>
          >
          > Now, suppose that an immediate GET returns:
          >
          > <elem1>
          > <elem2>Value</elem2>
          > <elem3>Value2</elem3>
          > </elem1>
          >
          > One additional constraint is that the client that did the PUT only
          > understands/processes <elem1> and <elem2>, ignoring all others. As a
          > result, the client's behavior for the PUT version and the GET version is
          > exactly the same. Is this RESTful? Half of me says "yes" because the
          > client doesn't see any difference between the two representations, and
          > the other half says "no" because it isn't exactly the same (as a
          > generalized xml document, ignoring byte-wise comparison).

          There's no guarantee, in general, that a PUT followed by a GET, even
          "immediately", will return the same content. The content crossed a
          trust boundary; anything goes. If you want an expectation of that sort,
          it should be declared in the message (similar to SOAPAction).

          It's possible there could be some self-descriptive problems with the
          data format - I can't tell - but since this is a response and not a
          request, that doesn't matter anyhow, I think.

          Mark.
        • Seairth Jacobs
          There is not yet an architecture. Actually, what brought this question up was the work going on with Atom [1], particularly with the API [2]. When editing an
          Message 4 of 10 , Dec 13, 2003
          • 0 Attachment
            There is not yet an architecture.  Actually, what brought this question up was the work going on with Atom [1], particularly with the API [2].  When editing an Atom entry, the client will PUT an entry document of some form or another.  However, the set of elements that may be appropriate to edit do not necessarily match the set of elements that would be returned in a GET.  Examples:

            1) There is a <modified> element that contains the modification timestamp.  It seems most appropriate for the server to set this value, not the client.
            2) As is currently hinted at in the API, the server could generate the <summary> element from the <content> element.  However, it could be just as possible for the client to submit the <summary> itself.

            Now, of these examples, only the first falls within my question.  The second example potentially relates to my question if the client does not provide the <summary>.

            On the other hand, I suppose the whole thing could be avoided as follows:  require to the client to PUT the entire document, including the fields that do not change (e.g. created, issued, etc.) .  The server makes sure that the values in the new version are the same as in the current version, or else flags the new version as conflicting.  In this case, the server must rely on the client giving accurate update timestamps, an updated summary, etc.  In other words, the server only validates the data, but does not update it.  The disadvantage here is that the client must understand the entire document.  It would not be possible for a server to add functionality (via namespaced elements) that the client could safely ignore because, depending on the extension, the server may think there's a conflict.

            *sigh* I dunno.  This approach doesn't quite feel right either.  Part of me feels that the actual use(s) of PUT is much more limited than a generic replace function, and part of me feels that the resource model is where the real problem is because I cannot use a simple PUT on it.

            Seairth

            [1] http://www.intertwingly.net/wiki/pie/
            [2] http://bitworking.org/projects/atom/draft-gregorio-09.html#Edit

            "Walden Mathews" wrote:
            Seairth,
            
            A good way to answer this might be to list the constraints from
            the REST architecture which you feel may have been violated,
            with citations from the architecture document itself [1].  Have you
            tried that?
            
            Thanks,
            Walden
            
            [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
            
            ----- Original Message ----- 
            From: "Seairth Jacobs" <seairth@...>
            To: "rest-discuss" <rest-discuss@yahoogroups.com>
            Sent: Friday, December 12, 2003 8:27 AM
            Subject: [rest-discuss] PUT question
            
            
            : I am still unclear on something about PUT.  Suppose I PUT the following:
            :
            :
            : <elem1>
            :     <elem2>Value</elem2>
            : </elem1>
            :
            : Now, suppose that an immediate GET returns:
            :
            : <elem1>
            :     <elem2>Value</elem2>
            :     <elem3>Value2</elem3>
            : </elem1>
            :
            : One additional constraint is that the client that did the PUT only
            : understands/processes <elem1> and <elem2>, ignoring all others.  As a
            : result, the client's behavior for the PUT version and the GET version is
            : exactly the same.  Is this RESTful?  Half of me says "yes" because the
            : client doesn't see any difference between the two representations, and
            : the other half says "no" because it isn't exactly the same (as a
            : generalized xml document, ignoring byte-wise comparison).
            :
            : Thoughts?
            :
            : Seairth
              
          • Seairth Jacobs
            ... Just how useful does PUT end up being if the end result is anything goes ? Suppose instead that you do a PUT, and get back in the response to that PUT
            Message 5 of 10 , Dec 13, 2003
            • 0 Attachment
              "Mark Baker" wrote:
              On Fri, Dec 12, 2003 at 08:27:15AM -0500, Seairth Jacobs wrote:
                
              I am still unclear on something about PUT.  Suppose I PUT the following:
              
              
              <elem1>
                  <elem2>Value</elem2>
              </elem1>
              
              Now, suppose that an immediate GET returns:
              
              <elem1>
                  <elem2>Value</elem2>
                  <elem3>Value2</elem3>
              </elem1>
              
              One additional constraint is that the client that did the PUT only 
              understands/processes <elem1> and <elem2>, ignoring all others.  As a 
              result, the client's behavior for the PUT version and the GET version is 
              exactly the same.  Is this RESTful?  Half of me says "yes" because the 
              client doesn't see any difference between the two representations, and 
              the other half says "no" because it isn't exactly the same (as a 
              generalized xml document, ignoring byte-wise comparison).
                  
              There's no guarantee, in general, that a PUT followed by a GET, even
              "immediately", will return the same content.  The content crossed a
              trust boundary; anything goes.  If you want an expectation of that sort,
              it should be declared in the message (similar to SOAPAction).
                
              Just how useful does PUT end up being if the end result is "anything goes"?  Suppose instead that you do a PUT, and get back in the response to that PUT the second xml document (the one retrieved with a GET).  I would hope that the client caches the response, not the request.  Is this obvious, or is this wrong?

              Seairth

            • Jan Algermissen
              ... [...] ... I think you can simply compare this behavior to the database world: if you INSERT a row into a table and do a subsequent SELECT there is nothing
              Message 6 of 10 , Dec 13, 2003
              • 0 Attachment
                > Seairth Jacobs wrote:
                >
                > "Mark Baker" wrote:
                [...]
                > > There's no guarantee, in general, that a PUT followed by a GET, even
                > > "immediately", will return the same content. The content crossed a
                > > trust boundary; anything goes. If you want an expectation of that sort,
                > > it should be declared in the message (similar to SOAPAction).
                > >
                > >
                > Just how useful does PUT end up being if the end result is "anything goes"?

                I think you can simply compare this behavior to the database world: if you
                INSERT a row into a table and do a subsequent SELECT there is nothing inherent
                in the concepts of databases that assures that you get back what you inserted.

                Only if you make sure that you wrap your interactions inside a single transaction
                you can reliably make this assumption.

                Within a RESTful system, you'd need a transaction-resource to handle this, though
                I do not have this idea in my bones. Will give this some thoughts (help welcome).

                Jan


                --
                Jan Algermissen http://www.topicmapping.com
                Consultant & Programmer http://www.gooseworks.org
              • Seairth Jacobs
                ... Well, the simplest way would be returning an entity in the response. I am beginning to think this is the part I have been overlooking with PUT, or at
                Message 7 of 10 , Dec 13, 2003
                • 0 Attachment
                  "Jan Algermissen" wrote:
                  Seairth Jacobs wrote:
                  
                  Just how useful does PUT end up being if the end result is "anything goes"? 
                      
                  I think you can simply compare this behavior to the database world: if you
                  INSERT  a row into a table and do a subsequent SELECT there is nothing inherent
                  in the concepts of databases that assures that you get back what you inserted.
                  
                  Only if you make sure that you wrap your interactions inside a single transaction
                  you can reliably make this assumption.
                  
                  Within a RESTful system, you'd need a transaction-resource to handle this, though
                  I do not have this idea in my bones. Will give this some thoughts (help welcome).
                    
                  Well, the simplest way would be returning an entity in the response.  I am beginning to think this is the part I have been overlooking with PUT, or at least not giving enough importance.  It's the response entity that matters, not the request entity.  I'm not yet sure how to put that in clearer terms.  I'll get back on this one...

                  Seairth
                • Chuck Hinson
                  ... I don t understand what you mean by this. I understood that PUT was used to set the state of a resource, and that the desired state of the resource was
                  Message 8 of 10 , Dec 13, 2003
                  • 0 Attachment
                    Mark Baker wrote:
                    >
                    > There's no guarantee, in general, that a PUT followed by a GET, even
                    > "immediately", will return the same content. The content crossed a
                    > trust boundary; anything goes.

                    I don't understand what you mean by this.

                    I understood that PUT was used to set the state of a resource, and that
                    the desired state of the resource was expressed by the representation in
                    the body of the PUT.

                    Why does crossing a trust boundary change that?

                    --Chuck
                  • Mark Baker
                    ... I should have been clearer, sorry. By anything goes I just mean that the content doesn t have to be bit-for-bit identical (though that seems to be
                    Message 9 of 10 , Dec 13, 2003
                    • 0 Attachment
                      On Sat, Dec 13, 2003 at 03:34:53PM -0500, Seairth Jacobs wrote:
                      > >There's no guarantee, in general, that a PUT followed by a GET, even
                      > >"immediately", will return the same content. The content crossed a
                      > >trust boundary; anything goes. If you want an expectation of that sort,
                      > >it should be declared in the message (similar to SOAPAction).
                      > >
                      > >
                      > Just how useful does PUT end up being if the end result is "anything
                      > goes"?

                      I should have been clearer, sorry. By "anything goes" I just mean that
                      the content doesn't have to be bit-for-bit identical (though that seems
                      to be common practice), but it has to be consistent with the state
                      reflected in the request.

                      e.g. you may PUT "on" to a URI identifying a lightbulb, but a GET may
                      return a JPG of a lightbulb in the on state ... at least when you ignore
                      the possibility that the state changed between the PUT and the GET.

                      Mark.
                      --
                      Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                    • Roy T. Fielding
                      ... A better way to think about it is that the request expresses the intent of the client but the server is responsible for mapping that back into the state of
                      Message 10 of 10 , Dec 13, 2003
                      • 0 Attachment
                        > Just how useful does PUT end up being if the end result is "anything
                        > goes"? 

                        A better way to think about it is that the request expresses the intent
                        of the client but the server is responsible for mapping that back into
                        the state of the resource (the client is not supposed to have a clue as
                        to how the resource is implemented, and usually doesn't even know what
                        defines it as a resource). Most of the time it just ends up being the
                        same as a flat file store, but the flexibility is there when you need it
                        because it allows the server to evolve independent of the clients.

                        We don't need to require that the server do something sensible, since
                        whatever it does should be in the best interests of the resource.

                        This is also why the Web does not support write-back caching.

                        ....Roy
                      Your message has been successfully submitted and would be delivered to recipients shortly.