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

Re: [rest-discuss] RESTful ordering and order-rejection

Expand Messages
  • Bob Haugen
    On Fri, Oct 30, 2009 at 6:01 PM, Jan Algermissen ... That s tricky, in the general sense. The business protocol here (above the application protocol) is called
    Message 1 of 18 , Oct 31, 2009
    • 0 Attachment
      On Fri, Oct 30, 2009 at 6:01 PM, Jan Algermissen
      <algermissen1971@...> wrote:
      > suppose the following media types do exist:
      >
      > - application/procurement-order for orders
      > - application/procurement-orderrejection for order rejections
      >
      > also suppose the client knows there is a resource at /order-processor
      > that accepts orders in application/procurement-order media type.
      >
      > What if the client submits an order and the server wants to reject
      > the order (maybe because the requested items are permanently out
      > of stock)? What return code would teh server use and does it make
      > sense to send the order rejection document as the body of the
      > (error-)response?

      That's tricky, in the general sense.

      The business protocol here (above the application protocol) is called
      Offer-Acceptance.

      So what the client submits is (business-technically) an Offer To Buy.
      The response could be acceptance or rejection or maybe a
      counter-offer. If the seller accepts, buyer and seller have a
      contract.

      There is a logical distinction between the offer and the response: in
      UBL, for example, the offer is just called Order and the response is
      called OrderResponse. They are different documents, and I think
      deserve to be different resources in a RESTful app. See
      http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html

      The interaction could be asynchronous. In other words, the HTTP
      response to the initial request could just be an acknowledgement, and
      the response to the offer to buy could come later. Or in the case of
      a counter-offer (for example, the seller could only partially fulfill
      the order), the buyer and seller might exchange several documents.

      So the answer to the question about the order rejection document is
      "it depends". Sometimes the seller might be able to respond
      immediately (as the HTTP response), sometimes not. At any rate, you
      might want to think of the both order and response as resources.
    • Jan Algermissen
      ... I am trying to rule out the abve approach by deriving from REST s constraints. Here is my thinking: I assume (because I am not able yet to derive that from
      Message 2 of 18 , Nov 1, 2009
      • 0 Attachment
        On Oct 31, 2009, at 12:01 AM, Jan Algermissen wrote:

        > Hi,
        >
        > suppose the following media types do exist:
        >
        > - application/procurement-order for orders
        > - application/procurement-orderrejection for order rejections
        >
        > also suppose the client knows there is a resource at /order-processor
        > that accepts orders in application/procurement-order media type.
        >
        > What if the client submits an order and the server wants to reject
        > the order (maybe because the requested items are permanently out
        > of stock)? What return code would the server use and does it make
        > sense to send the order rejection document as the body of the
        > (error-)response?

        I am trying to rule out the abve approach by deriving from REST's
        constraints.
        Here is my thinking:

        I assume (because I am not able yet to derive that from the REST
        constraints)
        that there is an implicit constraint in REST that demands all
        application data
        to be stored on the server.

        To put this in other words: a client must be able to perform any of
        the next
        possible transitions in an application soley based on the responses
        previously
        received. The client-server collaboration must not be designed in a
        way that
        requires a client to keep track of its own requests.

        Applied to my question above I think that a RESTful solution demands
        that the
        server creates application data as the basis for subsequent
        interactions and
        then instructs the client how to procede through the application. (This
        implies a solution where the order is created on the server and marked
        as
        'pending' to provide the application data. The client would then alter
        the
        order (the application data) to 'fix' the (item-out-of-stock-)problem.

        The solution proposed in my original posting on the other hand would
        require the client to record it's own order and apply the suggested
        change to it
        before repeating the original request.

        (Aside: is maintaining application data on both, client and server a
        property of
        messaging styles?)

        Generally, I have for some time now wondered what could be used as a
        guiding
        principle for answering the question when to create a resource on the
        server?
        (*Why* create a resource instead of just sending an answer document
        like you
        would do in synchronous messaging).

        When the resource is seen as application data, the answer would be
        that resources
        must be created when otherwise application data would have to be
        recorded on the
        client side (which we do not want according to my above reasoning).

        I am not really satisfied with the 'flow' of this argumentation yet -
        comments/criticism
        would be very welcome.

        Jan








        >
        > Example:
        >
        >
        > ->
        > POST /order=processor
        > Content-Type: application/procurement-order
        >
        > <the order XML goes here>
        >
        > 409 Confilct
        > Content-Type: application/procurement-orderrejection
        >
        > <xml of order rejection document goes here, maybe
        > telling the client how to fix the problem (e.g.
        > suggesting similar goods that are in stock)>
        >
        >
        > Does that make sense? And if not - how else to do it?
        >
        > Hmm, an alternative would be to create an order request resource and
        > not just an order resource and make the rejection part of the
        > representation of the order request:
        >
        > POST /order-processor
        > Content-Type: application/procurement-order
        >
        > 201 Created
        > Location /order-processor/order-requests
        > Content-Type: application/order-request
        >
        > <XML representing the state of the order-request, which at the
        > moment is
        > 'rejected'>
        >
        >
        > A client could then PUT/PATCH the order to fix the problem according
        > to
        > suggestions made in the order-request response.
        >
        >
        > Does that sound better?
        >
        > Jan
        >
        >
        >
        >
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >

        --------------------------------------
        Jan Algermissen

        Mail: algermissen@...
        Blog: http://algermissen.blogspot.com/
        Home: http://www.jalgermissen.com
        --------------------------------------
      • Sebastien Lambla
        Application state is the state of the application, that spans both the client and the server. There is no constraint preventing state residing on the client,
        Message 3 of 18 , Nov 2, 2009
        • 0 Attachment
          Application state is the state of the application, that spans both the client and the server. There is no constraint preventing state residing on the client, otherwise you couldn't have a local cache in your browser.
           
          S
           
          > To: rest-discuss@yahoogroups.com
          > From: algermissen1971@...
          > Date: Sun, 1 Nov 2009 21:17:11 +0100
          > Subject: Re: [rest-discuss] 'No application data on client' constraint? was: RESTful ordering and order-rejection
          >
          >
          > On Oct 31, 2009, at 12:01 AM, Jan Algermissen wrote:
          >
          > > Hi,
          > >
          > > suppose the following media types do exist:
          > >
          > > - application/procurement-order for orders
          > > - application/procurement-orderrejection for order rejections
          > >
          > > also suppose the client knows there is a resource at /order-processor
          > > that accepts orders in application/procurement-order media type.
          > >
          > > What if the client submits an order and the server wants to reject
          > > the order (maybe because the requested items are permanently out
          > > of stock)? What return code would the server use and does it make
          > > sense to send the order rejection document as the body of the
          > > (error-)response?
          >
          > I am trying to rule out the abve approach by deriving from REST's
          > constraints.
          > Here is my thinking:
          >
          > I assume (because I am not able yet to derive that from the REST
          > constraints)
          > that there is an implicit constraint in REST that demands all
          > application data
          > to be stored on the server.
          >
          > To put this in other words: a client must be able to perform any of
          > the next
          > possible transitions in an application soley based on the responses
          > previously
          > received. The client-server collaboration must not be designed in a
          > way that
          > requires a client to keep track of its own requests.
          >
          > Applied to my question above I think that a RESTful solution demands
          > that the
          > server creates application data as the basis for subsequent
          > interactions and
          > then instructs the client how to procede through the application. (This
          > implies a solution where the order is created on the server and marked
          > as
          > 'pending' to provide the application data. The client would then alter
          > the
          > order (the application data) to 'fix' the (item-out-of-stock-)problem.
          >
          > The solution proposed in my original posting on the other hand would
          > require the client to record it's own order and apply the suggested
          > change to it
          > before repeating the original request.
          >
          > (Aside: is maintaining application data on both, client and server a
          > property of
          > messaging styles?)
          >
          > Generally, I have for some time now wondered what could be used as a
          > guiding
          > principle for answering the question when to create a resource on the
          > server?
          > (*Why* create a resource instead of just sending an answer document
          > like you
          > would do in synchronous messaging).
          >
          > When the resource is seen as application data, the answer would be
          > that resources
          > must be created when otherwise application data would have to be
          > recorded on the
          > client side (which we do not want according to my above reasoning).
          >
          > I am not really satisfied with the 'flow' of this argumentation yet -
          > comments/criticism
          > would be very welcome.
          >
          > Jan
          >
          >
          >
          >
          >
          >
          >
          >
          > >
          > > Example:
          > >
          > >
          > > ->
          > > POST /order=processor
          > > Content-Type: application/procurement-order
          > >
          > > <the order XML goes here>
          > >
          > > 409 Confilct
          > > Content-Type: application/procurement-orderrejection
          > >
          > > <xml of order rejection document goes here, maybe
          > > telling the client how to fix the problem (e.g.
          > > suggesting similar goods that are in stock)>
          > >
          > >
          > > Does that make sense? And if not - how else to do it?
          > >
          > > Hmm, an alternative would be to create an order request resource and
          > > not just an order resource and make the rejection part of the
          > > representation of the order request:
          > >
          > > POST /order-processor
          > > Content-Type: application/procurement-order
          > >
          > > 201 Created
          > > Location /order-processor/order-requests
          > > Content-Type: application/order-request
          > >
          > > <XML representing the state of the order-request, which at the
          > > moment is
          > > 'rejected'>
          > >
          > >
          > > A client could then PUT/PATCH the order to fix the problem according
          > > to
          > > suggestions made in the order-request response.
          > >
          > >
          > > Does that sound better?
          > >
          > > Jan
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > > ------------------------------------
          > >
          > > Yahoo! Groups Links
          > >
          > >
          > >
          >
          > --------------------------------------
          > Jan Algermissen
          >
          > Mail: algermissen@...
          > Blog: http://algermissen.blogspot.com/
          > Home: http://www.jalgermissen.com
          > --------------------------------------
          >
          >
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          > <*> To visit your group on the web, go to:
          > http://groups.yahoo.com/group/rest-discuss/
          >
          > <*> Your email settings:
          > Individual Email | Traditional
          >
          > <*> To change settings online go to:
          > http://groups.yahoo.com/group/rest-discuss/join
          > (Yahoo! ID required)
          >
          > <*> To change settings via email:
          > mailto:rest-discuss-digest@yahoogroups.com
          > mailto:rest-discuss-fullfeatured@yahoogroups.com
          >
          > <*> 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/
          >


          Chat to your friends for free on selected mobiles. Learn more.
        • Jan Algermissen
          ... A request in a local cache is not what I mean by application data. Suppose a service were designed in a way that it would require the client to store data
          Message 4 of 18 , Nov 2, 2009
          • 0 Attachment
            On Nov 2, 2009, at 9:43 PM, Sebastien Lambla wrote:

            >
            >
            > Application state is the state of the application, that spans both
            > the client and the server. There is no constraint preventing state
            > residing on the client, otherwise you couldn't have a local cache in
            > your browser.

            A request in a local cache is not what I mean by application data.
            Suppose a service were designed in a way that it would require the
            client to store data besides URIs in order to make the next request.
            IOW, to continue its interaction with the service on another machine,
            it would not only need to take the appropriate URIs with it (e.g. send
            by mail) but also other data elements.

            I think that would be a violation of REST - I just cannot derive it
            from the other constraints.

            My hunch is that in a RESTful system

            a) all application state (aka session state) is on the client
            b) all application data resides on the server (as resource state)

            The question that drives me is what the significance of resource state
            is (what is its meaning/purpose in a given design? What are the design
            conditions that lead to the creation of new resource state? Etc.) I am
            trying to get away from the "you could do this and you could do that
            but you also could do it that way" kinds of answers to practical REST
            design questions.

            Jan


            >
            > S
            >
            > > To: rest-discuss@yahoogroups.com
            > > From: algermissen1971@...
            > > Date: Sun, 1 Nov 2009 21:17:11 +0100
            > > Subject: Re: [rest-discuss] 'No application data on client'
            > constraint? was: RESTful ordering and order-rejection
            > >
            > >
            > > On Oct 31, 2009, at 12:01 AM, Jan Algermissen wrote:
            > >
            > > > Hi,
            > > >
            > > > suppose the following media types do exist:
            > > >
            > > > - application/procurement-order for orders
            > > > - application/procurement-orderrejection for order rejections
            > > >
            > > > also suppose the client knows there is a resource at /order-
            > processor
            > > > that accepts orders in application/procurement-order media type.
            > > >
            > > > What if the client submits an order and the server wants to reject
            > > > the order (maybe because the requested items are permanently out
            > > > of stock)? What return code would the server use and does it make
            > > > sense to send the order rejection document as the body of the
            > > > (error-)response?
            > >
            > > I am trying to rule out the abve approach by deriving from REST's
            > > constraints.
            > > Here is my thinking:
            > >
            > > I assume (because I am not able yet to derive that from the REST
            > > constraints)
            > > that there is an implicit constraint in REST that demands all
            > > application data
            > > to be stored on the server.
            > >
            > > To put this in other words: a client must be able to perform any of
            > > the next
            > > possible transitions in an application soley based on the responses
            > > previously
            > > received. The client-server collaboration must not be designed in a
            > > way that
            > > requires a client to keep track of its own requests.
            > >
            > > Applied to my question above I think that a RESTful solution demands
            > > that the
            > > server creates application data as the basis for subsequent
            > > interactions and
            > > then instructs the client how to procede through the application.
            > (This
            > > implies a solution where the order is created on the server and
            > marked
            > > as
            > > 'pending' to provide the application data. The client would then
            > alter
            > > the
            > > order (the application data) to 'fix' the (item-out-of-
            > stock-)problem.
            > >
            > > The solution proposed in my original posting on the other hand would
            > > require the client to record it's own order and apply the suggested
            > > change to it
            > > before repeating the original request.
            > >
            > > (Aside: is maintaining application data on both, client and server a
            > > property of
            > > messaging styles?)
            > >
            > > Generally, I have for some time now wondered what could be used as a
            > > guiding
            > > principle for answering the question when to create a resource on
            > the
            > > server?
            > > (*Why* create a resource instead of just sending an answer document
            > > like you
            > > would do in synchronous messaging).
            > >
            > > When the resource is seen as application data, the answer would be
            > > that resources
            > > must be created when otherwise application data would have to be
            > > recorded on the
            > > client side (which we do not want according to my above reasoning).
            > >
            > > I am not really satisfied with the 'flow' of this argumentation
            > yet -
            > > comments/criticism
            > > would be very welcome.
            > >
            > > Jan
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            > > >
            > > > Example:
            > > >
            > > >
            > > > ->
            > > > POST /order=processor
            > > > Content-Type: application/procurement-order
            > > >
            > > > <the order XML goes here>
            > > >
            > > > 409 Confilct
            > > > Content-Type: application/procurement-orderrejection
            > > >
            > > > <xml of order rejection document goes here, maybe
            > > > telling the client how to fix the problem (e.g.
            > > > suggesting similar goods that are in stock)>
            > > >
            > > >
            > > > Does that make sense? And if not - how else to do it?
            > > >
            > > > Hmm, an alternative would be to create an order request resource
            > and
            > > > not just an order resource and make the rejection part of the
            > > > representation of the order request:
            > > >
            > > > POST /order-processor
            > > > Content-Type: application/procurement-order
            > > >
            > > > 201 Created
            > > > Location /order-processor/order-requests
            > > > Content-Type: application/order-request
            > > >
            > > > <XML representing the state of the order-request, which at the
            > > > moment is
            > > > 'rejected'>
            > > >
            > > >
            > > > A client could then PUT/PATCH the order to fix the problem
            > according
            > > > to
            > > > suggestions made in the order-request response.
            > > >
            > > >
            > > > Does that sound better?
            > > >
            > > > Jan
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > > ------------------------------------
            > > >
            > > > Yahoo! Groups Links
            > > >
            > > >
            > > >
            > >
            > > --------------------------------------
            > > Jan Algermissen
            > >
            > > Mail: algermissen@...
            > > Blog: http://algermissen.blogspot.com/
            > > Home: http://www.jalgermissen.com
            > > --------------------------------------
            > >
            > >
            > >
            > >
            > >
            > > ------------------------------------
            > >
            > > Yahoo! Groups Links
            > >
            > >
            > >
            >
            > Chat to your friends for free on selected mobiles. Learn more.
            >
            >

            --------------------------------------
            Jan Algermissen

            Mail: algermissen@...
            Blog: http://algermissen.blogspot.com/
            Home: http://www.jalgermissen.com
            --------------------------------------
          • Nick Gall
            On Mon, Nov 2, 2009 at 4:16 PM, Jan Algermissen ... I think I see what you are driving at with your distinction between session state
            Message 5 of 18 , Nov 2, 2009
            • 0 Attachment
              On Mon, Nov 2, 2009 at 4:16 PM, Jan Algermissen <algermissen1971@...> wrote:
              >
              > On Nov 2, 2009, at 9:43 PM, Sebastien Lambla wrote:
              >
              >>
              >>
              >> Application state is the state of the application, that spans both
              >> the client and the server. There is no constraint preventing state
              >> residing on the client, otherwise you couldn't have a local cache in
              >> your browser.
              >
              > A request in a local cache is not what I mean by application data.
              > Suppose a service were designed in a way that it would require the
              > client to store data besides URIs in order to make the next request.
              > IOW, to continue its interaction with the service on another machine,
              > it would not only need to take the appropriate URIs with it (e.g. send
              > by mail) but also other data elements.
              >
              > I think that would be a violation of REST - I just cannot derive it
              > from the other constraints.
              >
              > My hunch is that in a RESTful system
              >
              > a) all application state (aka session state) is on the client
              > b) all application data resides on the server (as resource state)
              >
              > The question that drives me is what the significance of resource state
              > is (what is its meaning/purpose in a given design? What are the design
              > conditions that lead to the creation of new resource state? Etc.) I am
              > trying to get away from the "you could do this and you could do that
              > but you also could do it that way" kinds of answers to practical REST
              > design questions.

              I think I see what you are driving at with your distinction between session state vs resource state, but I don't think the distinction is so clean in REST. Here's a relevant passage from Roy's thesis (5.3.3):

              The application state is controlled and stored by the user agent and can be composed of representations from multiple servers. In addition to freeing the server from the scalability problems of storing state, this allows the user to directly manipulate the state (e.g., a Web browser's history), anticipate changes to that state (e.g., link maps and prefetching of representations), and jump from one application to another (e.g., bookmarks and URI-entry dialogs). [emphasis added]

              So at least a copy of the resource state (in the form or a representation of that resource) is intended to be stored and manipulated on the client side. For example, I believe this 5.3.3 paragraph endorses the following scenario:
              1. client receives a representation of the works of art in a museum exhibit as list of art works (name of work, name of artist) from a museum service on some museum server
              2. the client extracts the name of an artist (a string) from the list and submits it to Wikipedia on a different set of servers
              3. It takes the representation from Wikipedia and formats it into a popup for the user's UI visualization of the museum exhibit
              In this scenario the client "jumps from one application (museum service) to another (Wikipedia)", submitting representation data it received from the first service to the second service. Your description above seems to prohibit such a scenario ("to continue its interaction with the service on another machine, it would not only need to take the appropriate URIs with it ... but also other data elements").

              It appears that REST endorses the use of "application data" stored on the client, at least in the case where such data was at some point in the past received by the client as part of a representation of a server-based resource.

              -- Nick

            • Jan Algermissen
              ... But in your scenario, the client could allways, just be use of the one initial URI, pick up the interaction. And this is (IMHO) exactly the significance of
              Message 6 of 18 , Nov 2, 2009
              • 0 Attachment
                On Nov 2, 2009, at 10:52 PM, Nick Gall wrote:

                >
                >
                > On Mon, Nov 2, 2009 at 4:16 PM, Jan Algermissen <algermissen1971@...
                > > wrote:
                >
                > > My hunch is that in a RESTful system
                > >
                > > a) all application state (aka session state) is on the client
                > > b) all application data resides on the server (as resource state)
                > >
                > > The question that drives me is what the significance of resource
                > state
                > > is (what is its meaning/purpose in a given design? What are the
                > design
                > > conditions that lead to the creation of new resource state? Etc.)
                > I am
                > > trying to get away from the "you could do this and you could do that
                > > but you also could do it that way" kinds of answers to practical
                > REST
                > > design questions.
                >
                > I think I see what you are driving at with your distinction between
                > session state vs resource state, but I don't think the distinction
                > is so clean in REST. Here's a relevant passage from Roy's thesis
                > (5.3.3):
                >
                > The application state is controlled and stored by the user agent and
                > can be composed of representations from multiple servers. In
                > addition to freeing the server from the scalability problems of
                > storing state, this allows the user to directly manipulate the state
                > (e.g., a Web browser's history), anticipate changes to that state
                > (e.g., link maps and prefetching of representations), and jump from
                > one application to another (e.g., bookmarks and URI-entry dialogs).
                > [emphasis added]
                >
                > So at least a copy of the resource state (in the form or a
                > representation of that resource) is intended to be stored and
                > manipulated on the client side. For example, I believe this 5.3.3
                > paragraph endorses the following scenario:
                > • client receives a representation of the works of art in a museum
                > exhibit as list of art works (name of work, name of artist) from a
                > museum service on some museum server
                > • the client extracts the name of an artist (a string) from the
                > list and submits it to Wikipedia on a different set of servers
                > • It takes the representation from Wikipedia and formats it into a
                > popup for the user's UI visualization of the museum exhibit
                > In this scenario the client "jumps from one application (museum
                > service) to another (Wikipedia)", submitting representation data it
                > received from the first service to the second service. Your
                > description above seems to prohibit such a scenario ("to continue
                > its interaction with the service on another machine, it would not
                > only need to take the appropriate URIs with it ... but also other
                > data elements").
                >

                But in your scenario, the client could allways, just be use of the one
                initial URI, pick up the interaction. And this is (IMHO) exactly the
                significance of storing the application data as resource state - so
                that the client can pick it up again. If the data was not stored in
                the server it would have to be stored on the client and the ability
                would be lost to pick up the conversation just on the basis of the URI.

                Jan



                > It appears that REST endorses the use of "application data" stored
                > on the client, at least in the case where such data was at some
                > point in the past received by the client as part of a representation
                > of a server-based resource.
                >
                > -- Nick
                >
                >
                >
                >

                --------------------------------------
                Jan Algermissen

                Mail: algermissen@...
                Blog: http://algermissen.blogspot.com/
                Home: http://www.jalgermissen.com
                --------------------------------------
              • mike amundsen
                Jan: I am trying to get away from the you could do this and you could do that but you also could do it that way kinds of answers to practical REST
                Message 7 of 18 , Nov 2, 2009
                • 0 Attachment
                  Jan:

                  <snip>
                  I am trying to get away from the "you could do this and you could do
                  that but you also could do it that way" kinds of answers to practical
                  REST design questions.
                  </snip>

                  Why do you want to get away from this?

                  mca
                  http://amundsen.com/blog/




                  On Mon, Nov 2, 2009 at 17:09, Jan Algermissen <algermissen1971@...> wrote:
                  >
                  > On Nov 2, 2009, at 10:52 PM, Nick Gall wrote:
                  >
                  >>
                  >>
                  >> On Mon, Nov 2, 2009 at 4:16 PM, Jan Algermissen <algermissen1971@...
                  >> > wrote:
                  >>
                  >> > My hunch is that in a RESTful system
                  >> >
                  >> > a) all application state (aka session state) is on the client
                  >> > b) all application data resides on the server (as resource state)
                  >> >
                  >> > The question that drives me is what the significance of resource
                  >> state
                  >> > is (what is its meaning/purpose in a given design? What are the
                  >> design
                  >> > conditions that lead to the creation of new resource state? Etc.)
                  >> I am
                  >> > trying to get away from the "you could do this and you could do that
                  >> > but you also could do it that way" kinds of answers to practical
                  >> REST
                  >> > design questions.
                  >>
                  >> I think I see what you are driving at with your distinction between
                  >> session state vs resource state, but I don't think the distinction
                  >> is so clean in REST. Here's a relevant passage from Roy's thesis
                  >> (5.3.3):
                  >>
                  >> The application state is controlled and stored by the user agent and
                  >> can be composed of representations from multiple servers. In
                  >> addition to freeing the server from the scalability problems of
                  >> storing state, this allows the user to directly manipulate the state
                  >> (e.g., a Web browser's history), anticipate changes to that state
                  >> (e.g., link maps and prefetching of representations), and jump from
                  >> one application to another (e.g., bookmarks and URI-entry dialogs).
                  >> [emphasis added]
                  >>
                  >> So at least a copy of the resource state (in the form or a
                  >> representation of that resource) is intended to be stored and
                  >> manipulated on the client side. For example, I believe this 5.3.3
                  >> paragraph endorses the following scenario:
                  >>       • client receives a representation of the works of art in a museum
                  >> exhibit as list of art works (name of work, name of artist) from a
                  >> museum service on some museum server
                  >>       • the client extracts the name of an artist (a string) from the
                  >> list and submits it to Wikipedia on a different set of servers
                  >>       • It takes the representation from Wikipedia and formats it into a
                  >> popup for the user's UI visualization of the museum exhibit
                  >> In this scenario the client "jumps from one application (museum
                  >> service) to another (Wikipedia)", submitting representation data it
                  >> received from the first service to the second service. Your
                  >> description above seems to prohibit such a scenario ("to continue
                  >> its interaction with the service on another machine, it would not
                  >> only need to take the appropriate URIs with it ... but also other
                  >> data elements").
                  >>
                  >
                  > But in your scenario, the client could allways, just be use of the one
                  > initial URI, pick up the interaction. And this is (IMHO) exactly the
                  > significance of storing the application data as resource state - so
                  > that the client can pick it up again. If the data was not stored in
                  > the server it would have to be stored on the client and the ability
                  > would be lost to pick up the conversation just on the basis of the URI.
                  >
                  > Jan
                  >
                  >
                  >
                  >> It appears that REST endorses the use of "application data" stored
                  >> on the client, at least in the case where such data was at some
                  >> point in the past received by the client as part of a representation
                  >> of a server-based resource.
                  >>
                  >> -- Nick
                  >>
                  >>
                  >>
                  >>
                  >
                  > --------------------------------------
                  > Jan Algermissen
                  >
                  > Mail: algermissen@...
                  > Blog: http://algermissen.blogspot.com/
                  > Home: http://www.jalgermissen.com
                  > --------------------------------------
                  >
                  >
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                • Jan Algermissen
                  ... Because it does not exactly sell good if you cannot back up advice you give by principles. One of the things I admire about the Software Architecture
                  Message 8 of 18 , Nov 2, 2009
                  • 0 Attachment
                    On Nov 3, 2009, at 12:13 AM, mike amundsen wrote:

                    > Jan:
                    >
                    > <snip>
                    > I am trying to get away from the "you could do this and you could do
                    > that but you also could do it that way" kinds of answers to practical
                    > REST design questions.
                    > </snip>
                    >
                    > Why do you want to get away from this?

                    Because it does not exactly sell good if you cannot back up advice you
                    give by principles. One of the things I admire about the Software
                    Architecture notion laid out by Perry/Wolf, Garlan/Shaw and Roy [1] is
                    that it creates a foundation for backing up architectural design
                    decisions by principles. And I just get this feeling of hand waving
                    when it comes to answering questions about 'how do I do X'. I don't
                    mind that there are many solutions (otherwise there would not be any
                    room for design) but (at least) I often cannot articulate a clear
                    reasoning why and when to prefer one over the other.

                    Take the example problem I posted. What is better for order-rejection-
                    with-suggested-modification? To send 409 and e.g. a UBL-like order-
                    response document (like you would in the non computerized business
                    world) or to create an order resource anyhow, set the status to
                    pending and then let the client update the order until it can be
                    accepted?

                    (I had a hunch that the latter is better than the former because it
                    maintains application data on the server only)

                    Likewise, several return codes have been suggested (409, 422 for
                    example). It makes no sense to have different returns codes specified
                    when a group like this one cannot provide a spot-on 'yeah, it is that
                    one and only that one' response.

                    And even if there is a single best answer - how do you get
                    interoperability if it is so easy for different people to have
                    different opinions about it?

                    Jan


                    [1] Excuses for the names missing here



                    >
                    > mca
                    > http://amundsen.com/blog/
                    >
                    >
                    >
                    >
                    > On Mon, Nov 2, 2009 at 17:09, Jan Algermissen
                    > <algermissen1971@...> wrote:
                    >>
                    >> On Nov 2, 2009, at 10:52 PM, Nick Gall wrote:
                    >>
                    >>>
                    >>>
                    >>> On Mon, Nov 2, 2009 at 4:16 PM, Jan Algermissen <algermissen1971@...
                    >>>> wrote:
                    >>>
                    >>>> My hunch is that in a RESTful system
                    >>>>
                    >>>> a) all application state (aka session state) is on the client
                    >>>> b) all application data resides on the server (as resource state)
                    >>>>
                    >>>> The question that drives me is what the significance of resource
                    >>> state
                    >>>> is (what is its meaning/purpose in a given design? What are the
                    >>> design
                    >>>> conditions that lead to the creation of new resource state? Etc.)
                    >>> I am
                    >>>> trying to get away from the "you could do this and you could do
                    >>>> that
                    >>>> but you also could do it that way" kinds of answers to practical
                    >>> REST
                    >>>> design questions.
                    >>>
                    >>> I think I see what you are driving at with your distinction between
                    >>> session state vs resource state, but I don't think the distinction
                    >>> is so clean in REST. Here's a relevant passage from Roy's thesis
                    >>> (5.3.3):
                    >>>
                    >>> The application state is controlled and stored by the user agent and
                    >>> can be composed of representations from multiple servers. In
                    >>> addition to freeing the server from the scalability problems of
                    >>> storing state, this allows the user to directly manipulate the state
                    >>> (e.g., a Web browser's history), anticipate changes to that state
                    >>> (e.g., link maps and prefetching of representations), and jump from
                    >>> one application to another (e.g., bookmarks and URI-entry dialogs).
                    >>> [emphasis added]
                    >>>
                    >>> So at least a copy of the resource state (in the form or a
                    >>> representation of that resource) is intended to be stored and
                    >>> manipulated on the client side. For example, I believe this 5.3.3
                    >>> paragraph endorses the following scenario:
                    >>> • client receives a representation of the works of art in a
                    >>> museum
                    >>> exhibit as list of art works (name of work, name of artist) from a
                    >>> museum service on some museum server
                    >>> • the client extracts the name of an artist (a string) from
                    >>> the
                    >>> list and submits it to Wikipedia on a different set of servers
                    >>> • It takes the representation from Wikipedia and formats it
                    >>> into a
                    >>> popup for the user's UI visualization of the museum exhibit
                    >>> In this scenario the client "jumps from one application (museum
                    >>> service) to another (Wikipedia)", submitting representation data it
                    >>> received from the first service to the second service. Your
                    >>> description above seems to prohibit such a scenario ("to continue
                    >>> its interaction with the service on another machine, it would not
                    >>> only need to take the appropriate URIs with it ... but also other
                    >>> data elements").
                    >>>
                    >>
                    >> But in your scenario, the client could allways, just be use of the
                    >> one
                    >> initial URI, pick up the interaction. And this is (IMHO) exactly the
                    >> significance of storing the application data as resource state - so
                    >> that the client can pick it up again. If the data was not stored in
                    >> the server it would have to be stored on the client and the ability
                    >> would be lost to pick up the conversation just on the basis of the
                    >> URI.
                    >>
                    >> Jan
                    >>
                    >>
                    >>
                    >>> It appears that REST endorses the use of "application data" stored
                    >>> on the client, at least in the case where such data was at some
                    >>> point in the past received by the client as part of a representation
                    >>> of a server-based resource.
                    >>>
                    >>> -- Nick
                    >>>
                    >>>
                    >>>
                    >>>
                    >>
                    >> --------------------------------------
                    >> Jan Algermissen
                    >>
                    >> Mail: algermissen@...
                    >> Blog: http://algermissen.blogspot.com/
                    >> Home: http://www.jalgermissen.com
                    >> --------------------------------------
                    >>
                    >>
                    >>
                    >>
                    >>
                    >> ------------------------------------
                    >>
                    >> Yahoo! Groups Links
                    >>
                    >>
                    >>
                    >>
                    >
                    >
                    > ------------------------------------
                    >
                    > Yahoo! Groups Links
                    >
                    >
                    >

                    --------------------------------------
                    Jan Algermissen

                    Mail: algermissen@...
                    Blog: http://algermissen.blogspot.com/
                    Home: http://www.jalgermissen.com
                    --------------------------------------
                  • António Mota
                    2009/11/2 Jan Algermissen ... That makes some sense to me, although my hunch would be more like a) all application state is on the
                    Message 9 of 18 , Nov 3, 2009
                    • 0 Attachment
                      2009/11/2 Jan Algermissen <algermissen1971@...>
                      >
                      > My hunch is that in a RESTful system
                      >
                      > a) all application state (aka session state) is on the client
                      > b) all application data resides on the server (as resource state)
                      >

                      That makes some sense to me, although my hunch would be more like

                      a) all application state is on the client as a representation of the
                      last accessed resource(s) state(s)
                      b) all application data resides on the server, a combination of
                      which, at some point in time of the application life-cycle, represents
                      a particular resource state

                      But then again, if a client can manipulate the data that in some point
                      in time of the application life-cycle was transferred from a resource,
                      then it can change or add that data, so before that data is submitted
                      back to the server, there is *some* application data that does not
                      resides on the server...
                    • mike amundsen
                      Jan: As a quick follow-up on the notion of the getting away from... issue: Since HTTP is a testable spec, and REST is most commonly discussed in regards to
                      Message 10 of 18 , Nov 3, 2009
                      • 0 Attachment
                        Jan:

                        As a quick follow-up on the notion of the "getting away from..." issue:

                        Since HTTP is a testable spec, and REST is most commonly discussed in
                        regards to HTTP, it is a short leap to consider REST-fulness to also
                        be testable; to expect there to be a "right way" to implement REST
                        over HTTP just as there is a correct way to implement the HTTP
                        application protocol. But this is not a reasonable goal. In fact, it
                        can be a hurdle to building workable applications using the style.

                        mca
                        http://amundsen.com/blog/




                        On Mon, Nov 2, 2009 at 18:51, Jan Algermissen <algermissen1971@...> wrote:
                        >
                        > On Nov 3, 2009, at 12:13 AM, mike amundsen wrote:
                        >
                        >> Jan:
                        >>
                        >> <snip>
                        >> I am trying to get away from the "you could do this and you could do
                        >> that but you also could do it that way" kinds of answers to practical
                        >> REST design questions.
                        >> </snip>
                        >>
                        >> Why do you want to get away from this?
                        >
                        > Because it does not exactly sell good if you cannot back up advice you give
                        > by principles. One of the things I admire about the Software Architecture
                        > notion laid out by Perry/Wolf, Garlan/Shaw and Roy [1] is that it creates a
                        > foundation for backing up architectural design decisions by principles. And
                        > I just get this feeling of hand waving when it comes to answering questions
                        > about 'how do I do X'. I don't mind that there are many solutions (otherwise
                        > there would not be any room for design) but (at least) I often cannot
                        > articulate a clear reasoning why and when to prefer one over the other.
                        >
                        > Take the example problem I posted. What is better for
                        > order-rejection-with-suggested-modification? To send 409 and e.g. a UBL-like
                        > order-response document (like you would in the non computerized business
                        > world) or to create an order resource anyhow, set the status to pending and
                        > then let the client update the order until it can be accepted?
                        >
                        > (I had a hunch that the latter is better than the former because it
                        > maintains application data on the server only)
                        >
                        > Likewise, several return codes have been suggested (409, 422 for example).
                        > It makes no sense to have different returns codes specified when a group
                        > like this one cannot provide a spot-on 'yeah, it is that one and only that
                        > one' response.
                        >
                        > And even if there is a single best answer - how do you get interoperability
                        > if it is so easy for different people to have different opinions about it?
                        >
                        > Jan
                        >
                        >
                        > [1] Excuses for the names missing here
                        >
                        >
                        >
                        >>
                        >> mca
                        >> http://amundsen.com/blog/
                        >>
                        >>
                        >>
                        >>
                        >> On Mon, Nov 2, 2009 at 17:09, Jan Algermissen <algermissen1971@...>
                        >> wrote:
                        >>>
                        >>> On Nov 2, 2009, at 10:52 PM, Nick Gall wrote:
                        >>>
                        >>>>
                        >>>>
                        >>>> On Mon, Nov 2, 2009 at 4:16 PM, Jan Algermissen <algermissen1971@...
                        >>>>>
                        >>>>> wrote:
                        >>>>
                        >>>>> My hunch is that in a RESTful system
                        >>>>>
                        >>>>> a) all application state (aka session state) is on the client
                        >>>>> b) all application data resides on the server (as resource state)
                        >>>>>
                        >>>>> The question that drives me is what the significance of resource
                        >>>>
                        >>>> state
                        >>>>>
                        >>>>> is (what is its meaning/purpose in a given design? What are the
                        >>>>
                        >>>> design
                        >>>>>
                        >>>>> conditions that lead to the creation of new resource state? Etc.)
                        >>>>
                        >>>> I am
                        >>>>>
                        >>>>> trying to get away from the "you could do this and you could do that
                        >>>>> but you also could do it that way" kinds of answers to practical
                        >>>>
                        >>>> REST
                        >>>>>
                        >>>>> design questions.
                        >>>>
                        >>>> I think I see what you are driving at with your distinction between
                        >>>> session state vs resource state, but I don't think the distinction
                        >>>> is so clean in REST. Here's a relevant passage from Roy's thesis
                        >>>> (5.3.3):
                        >>>>
                        >>>> The application state is controlled and stored by the user agent and
                        >>>> can be composed of representations from multiple servers. In
                        >>>> addition to freeing the server from the scalability problems of
                        >>>> storing state, this allows the user to directly manipulate the state
                        >>>> (e.g., a Web browser's history), anticipate changes to that state
                        >>>> (e.g., link maps and prefetching of representations), and jump from
                        >>>> one application to another (e.g., bookmarks and URI-entry dialogs).
                        >>>> [emphasis added]
                        >>>>
                        >>>> So at least a copy of the resource state (in the form or a
                        >>>> representation of that resource) is intended to be stored and
                        >>>> manipulated on the client side. For example, I believe this 5.3.3
                        >>>> paragraph endorses the following scenario:
                        >>>>      • client receives a representation of the works of art in a museum
                        >>>> exhibit as list of art works (name of work, name of artist) from a
                        >>>> museum service on some museum server
                        >>>>      • the client extracts the name of an artist (a string) from the
                        >>>> list and submits it to Wikipedia on a different set of servers
                        >>>>      • It takes the representation from Wikipedia and formats it into a
                        >>>> popup for the user's UI visualization of the museum exhibit
                        >>>> In this scenario the client "jumps from one application (museum
                        >>>> service) to another (Wikipedia)", submitting representation data it
                        >>>> received from the first service to the second service. Your
                        >>>> description above seems to prohibit such a scenario ("to continue
                        >>>> its interaction with the service on another machine, it would not
                        >>>> only need to take the appropriate URIs with it ... but also other
                        >>>> data elements").
                        >>>>
                        >>>
                        >>> But in your scenario, the client could allways, just be use of the one
                        >>> initial URI, pick up the interaction. And this is (IMHO) exactly the
                        >>> significance of storing the application data as resource state - so
                        >>> that the client can pick it up again. If the data was not stored in
                        >>> the server it would have to be stored on the client and the ability
                        >>> would be lost to pick up the conversation just on the basis of the URI.
                        >>>
                        >>> Jan
                        >>>
                        >>>
                        >>>
                        >>>> It appears that REST endorses the use of "application data" stored
                        >>>> on the client, at least in the case where such data was at some
                        >>>> point in the past received by the client as part of a representation
                        >>>> of a server-based resource.
                        >>>>
                        >>>> -- Nick
                        >>>>
                        >>>>
                        >>>>
                        >>>>
                        >>>
                        >>> --------------------------------------
                        >>> Jan Algermissen
                        >>>
                        >>> Mail: algermissen@...
                        >>> Blog: http://algermissen.blogspot.com/
                        >>> Home: http://www.jalgermissen.com
                        >>> --------------------------------------
                        >>>
                        >>>
                        >>>
                        >>>
                        >>>
                        >>> ------------------------------------
                        >>>
                        >>> Yahoo! Groups Links
                        >>>
                        >>>
                        >>>
                        >>>
                        >>
                        >>
                        >> ------------------------------------
                        >>
                        >> Yahoo! Groups Links
                        >>
                        >>
                        >>
                        >
                        > --------------------------------------
                        > Jan Algermissen
                        >
                        > Mail: algermissen@...
                        > Blog: http://algermissen.blogspot.com/
                        > Home: http://www.jalgermissen.com
                        > --------------------------------------
                        >
                        >
                        >
                        >
                      • wahbedahbe
                        ... Well I don t think it is necessarily the case that the response to every request *replaces* the application state on the client. That is, a response can be
                        Message 11 of 18 , Nov 3, 2009
                        • 0 Attachment
                          --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
                          >
                          >
                          > On Oct 31, 2009, at 12:01 AM, Jan Algermissen wrote:
                          >
                          > > Hi,
                          > >
                          > > suppose the following media types do exist:
                          > >
                          > > - application/procurement-order for orders
                          > > - application/procurement-orderrejection for order rejections
                          > >
                          > > also suppose the client knows there is a resource at /order-processor
                          > > that accepts orders in application/procurement-order media type.
                          > >
                          > > What if the client submits an order and the server wants to reject
                          > > the order (maybe because the requested items are permanently out
                          > > of stock)? What return code would the server use and does it make
                          > > sense to send the order rejection document as the body of the
                          > > (error-)response?
                          >
                          > I am trying to rule out the abve approach by deriving from REST's
                          > constraints.
                          > Here is my thinking:
                          >
                          > I assume (because I am not able yet to derive that from the REST
                          > constraints)
                          > that there is an implicit constraint in REST that demands all
                          > application data
                          > to be stored on the server.
                          >
                          > To put this in other words: a client must be able to perform any of
                          > the next
                          > possible transitions in an application soley based on the responses
                          > previously
                          > received. The client-server collaboration must not be designed in a
                          > way that
                          > requires a client to keep track of its own requests.
                          >

                          Well I don't think it is necessarily the case that the response to every request *replaces* the application state on the client. That is, a response can be use to *add to* or otherwise modify the client state. This is certainly the case for ancillary resources like images in a web page. But I think it is also valid to do this after already reaching a steady state. For example, this is what is often happening in an Ajax application. An HTTP request can retrieve new data that changes the client state but the overall client state is defined by a combination of data retrieved from multiple requests. This does present the problem of not having a single URI to represent the current state of the application but many Ajax apps are using URI fragments to deal with this. As far as I can tell, this is "ok".

                          > Applied to my question above I think that a RESTful solution demands
                          > that the
                          > server creates application data as the basis for subsequent
                          > interactions and
                          > then instructs the client how to procede through the application. (This
                          > implies a solution where the order is created on the server and marked
                          > as
                          > 'pending' to provide the application data. The client would then alter
                          > the
                          > order (the application data) to 'fix' the (item-out-of-stock-)problem.
                          >

                          Well I don't think it is unRESTful for a server to respond to a POST with a 200 OK rather than a 201 Created or a 303 See Other. This does create a "transient" state that the client can't return to (via a bookmark) or communicate by sharing the URI. It is common practice to avoid doing this, but if the state truly is transient then maybe it's the right thing? Anyways, I don't believe that REST requires that there are no transient states, which I think is what you are getting at. I can't say that I have any references to back this up though -- I'm more going on the fact that I've never seen authoritative sources say otherwise.

                          Regards,

                          Andrew
                        • Jan Algermissen
                          ... But my question is related to resource design and hypermedia design, not about how to implement HTTP. If we view linking to be part of the resource design
                          Message 12 of 18 , Nov 4, 2009
                          • 0 Attachment
                            On Nov 4, 2009, at 3:20 AM, mike amundsen wrote:

                            > Jan:
                            >
                            > As a quick follow-up on the notion of the "getting away from..."
                            > issue:
                            >
                            > Since HTTP is a testable spec, and REST is most commonly discussed in
                            > regards to HTTP, it is a short leap to consider REST-fulness to also
                            > be testable; to expect there to be a "right way" to implement REST
                            > over HTTP just as there is a correct way to implement the HTTP
                            > application protocol.

                            But my question is related to resource design and hypermedia design, not
                            about how to implement HTTP.

                            If we view linking to be part of the resource design and hypermedia
                            to just be a means of serializing resource state and resource
                            relationships (linking) than my question is really only about
                            resource design.

                            So, IOW, I am looking for principles that apply to the partitioning
                            of the application data (resource model) and to the design of the
                            relationships between the application data partitions.

                            Probably it makes sense to ask if the application data partitioning
                            may extend to the client? Is it 'valid' to put application data on
                            the client that is not also maintained on the server? I think that
                            is likely to be the essence of the original question.

                            Jan



                            > But this is not a reasonable goal. In fact, it
                            > can be a hurdle to building workable applications using the style.
                            >
                            > mca
                            > http://amundsen.com/blog/
                            >
                            >
                            >
                            >
                            > On Mon, Nov 2, 2009 at 18:51, Jan Algermissen
                            > <algermissen1971@...> wrote:
                            >>
                            >> On Nov 3, 2009, at 12:13 AM, mike amundsen wrote:
                            >>
                            >>> Jan:
                            >>>
                            >>> <snip>
                            >>> I am trying to get away from the "you could do this and you could do
                            >>> that but you also could do it that way" kinds of answers to
                            >>> practical
                            >>> REST design questions.
                            >>> </snip>
                            >>>
                            >>> Why do you want to get away from this?
                            >>
                            >> Because it does not exactly sell good if you cannot back up advice
                            >> you give
                            >> by principles. One of the things I admire about the Software
                            >> Architecture
                            >> notion laid out by Perry/Wolf, Garlan/Shaw and Roy [1] is that it
                            >> creates a
                            >> foundation for backing up architectural design decisions by
                            >> principles. And
                            >> I just get this feeling of hand waving when it comes to answering
                            >> questions
                            >> about 'how do I do X'. I don't mind that there are many solutions
                            >> (otherwise
                            >> there would not be any room for design) but (at least) I often cannot
                            >> articulate a clear reasoning why and when to prefer one over the
                            >> other.
                            >>
                            >> Take the example problem I posted. What is better for
                            >> order-rejection-with-suggested-modification? To send 409 and e.g. a
                            >> UBL-like
                            >> order-response document (like you would in the non computerized
                            >> business
                            >> world) or to create an order resource anyhow, set the status to
                            >> pending and
                            >> then let the client update the order until it can be accepted?
                            >>
                            >> (I had a hunch that the latter is better than the former because it
                            >> maintains application data on the server only)
                            >>
                            >> Likewise, several return codes have been suggested (409, 422 for
                            >> example).
                            >> It makes no sense to have different returns codes specified when a
                            >> group
                            >> like this one cannot provide a spot-on 'yeah, it is that one and
                            >> only that
                            >> one' response.
                            >>
                            >> And even if there is a single best answer - how do you get
                            >> interoperability
                            >> if it is so easy for different people to have different opinions
                            >> about it?
                            >>
                            >> Jan
                            >>
                            >>
                            >> [1] Excuses for the names missing here
                            >>
                            >>
                            >>
                            >>>
                            >>> mca
                            >>> http://amundsen.com/blog/
                            >>>
                            >>>
                            >>>
                            >>>
                            >>> On Mon, Nov 2, 2009 at 17:09, Jan Algermissen <algermissen1971@...
                            >>> >
                            >>> wrote:
                            >>>>
                            >>>> On Nov 2, 2009, at 10:52 PM, Nick Gall wrote:
                            >>>>
                            >>>>>
                            >>>>>
                            >>>>> On Mon, Nov 2, 2009 at 4:16 PM, Jan Algermissen <algermissen1971@...
                            >>>>>>
                            >>>>>> wrote:
                            >>>>>
                            >>>>>> My hunch is that in a RESTful system
                            >>>>>>
                            >>>>>> a) all application state (aka session state) is on the client
                            >>>>>> b) all application data resides on the server (as resource state)
                            >>>>>>
                            >>>>>> The question that drives me is what the significance of resource
                            >>>>>
                            >>>>> state
                            >>>>>>
                            >>>>>> is (what is its meaning/purpose in a given design? What are the
                            >>>>>
                            >>>>> design
                            >>>>>>
                            >>>>>> conditions that lead to the creation of new resource state? Etc.)
                            >>>>>
                            >>>>> I am
                            >>>>>>
                            >>>>>> trying to get away from the "you could do this and you could do
                            >>>>>> that
                            >>>>>> but you also could do it that way" kinds of answers to practical
                            >>>>>
                            >>>>> REST
                            >>>>>>
                            >>>>>> design questions.
                            >>>>>
                            >>>>> I think I see what you are driving at with your distinction
                            >>>>> between
                            >>>>> session state vs resource state, but I don't think the distinction
                            >>>>> is so clean in REST. Here's a relevant passage from Roy's thesis
                            >>>>> (5.3.3):
                            >>>>>
                            >>>>> The application state is controlled and stored by the user agent
                            >>>>> and
                            >>>>> can be composed of representations from multiple servers. In
                            >>>>> addition to freeing the server from the scalability problems of
                            >>>>> storing state, this allows the user to directly manipulate the
                            >>>>> state
                            >>>>> (e.g., a Web browser's history), anticipate changes to that state
                            >>>>> (e.g., link maps and prefetching of representations), and jump
                            >>>>> from
                            >>>>> one application to another (e.g., bookmarks and URI-entry
                            >>>>> dialogs).
                            >>>>> [emphasis added]
                            >>>>>
                            >>>>> So at least a copy of the resource state (in the form or a
                            >>>>> representation of that resource) is intended to be stored and
                            >>>>> manipulated on the client side. For example, I believe this 5.3.3
                            >>>>> paragraph endorses the following scenario:
                            >>>>> • client receives a representation of the works of art in a
                            >>>>> museum
                            >>>>> exhibit as list of art works (name of work, name of artist) from a
                            >>>>> museum service on some museum server
                            >>>>> • the client extracts the name of an artist (a string) from
                            >>>>> the
                            >>>>> list and submits it to Wikipedia on a different set of servers
                            >>>>> • It takes the representation from Wikipedia and formats it
                            >>>>> into a
                            >>>>> popup for the user's UI visualization of the museum exhibit
                            >>>>> In this scenario the client "jumps from one application (museum
                            >>>>> service) to another (Wikipedia)", submitting representation data
                            >>>>> it
                            >>>>> received from the first service to the second service. Your
                            >>>>> description above seems to prohibit such a scenario ("to continue
                            >>>>> its interaction with the service on another machine, it would not
                            >>>>> only need to take the appropriate URIs with it ... but also other
                            >>>>> data elements").
                            >>>>>
                            >>>>
                            >>>> But in your scenario, the client could allways, just be use of
                            >>>> the one
                            >>>> initial URI, pick up the interaction. And this is (IMHO) exactly
                            >>>> the
                            >>>> significance of storing the application data as resource state - so
                            >>>> that the client can pick it up again. If the data was not stored in
                            >>>> the server it would have to be stored on the client and the ability
                            >>>> would be lost to pick up the conversation just on the basis of
                            >>>> the URI.
                            >>>>
                            >>>> Jan
                            >>>>
                            >>>>
                            >>>>
                            >>>>> It appears that REST endorses the use of "application data" stored
                            >>>>> on the client, at least in the case where such data was at some
                            >>>>> point in the past received by the client as part of a
                            >>>>> representation
                            >>>>> of a server-based resource.
                            >>>>>
                            >>>>> -- Nick
                            >>>>>
                            >>>>>
                            >>>>>
                            >>>>>
                            >>>>
                            >>>> --------------------------------------
                            >>>> Jan Algermissen
                            >>>>
                            >>>> Mail: algermissen@...
                            >>>> Blog: http://algermissen.blogspot.com/
                            >>>> Home: http://www.jalgermissen.com
                            >>>> --------------------------------------
                            >>>>
                            >>>>
                            >>>>
                            >>>>
                            >>>>
                            >>>> ------------------------------------
                            >>>>
                            >>>> Yahoo! Groups Links
                            >>>>
                            >>>>
                            >>>>
                            >>>>
                            >>>
                            >>>
                            >>> ------------------------------------
                            >>>
                            >>> Yahoo! Groups Links
                            >>>
                            >>>
                            >>>
                            >>
                            >> --------------------------------------
                            >> Jan Algermissen
                            >>
                            >> Mail: algermissen@...
                            >> Blog: http://algermissen.blogspot.com/
                            >> Home: http://www.jalgermissen.com
                            >> --------------------------------------
                            >>
                            >>
                            >>
                            >>
                            >
                            >
                            > ------------------------------------
                            >
                            > Yahoo! Groups Links
                            >
                            >
                            >

                            --------------------------------------
                            Jan Algermissen

                            Mail: algermissen@...
                            Blog: http://algermissen.blogspot.com/
                            Home: http://www.jalgermissen.com
                            --------------------------------------
                          • Jan Algermissen
                            ... No, certainly not. I hope I did not create the impression I mean that. The client builds up application state as it proceeds through the applications state
                            Message 13 of 18 , Nov 4, 2009
                            • 0 Attachment
                              On Nov 4, 2009, at 6:00 AM, wahbedahbe wrote:

                              >
                              >
                              > --- In rest-discuss@yahoogroups.com, Jan Algermissen
                              > <algermissen1971@...> wrote:
                              >>
                              >>
                              >> On Oct 31, 2009, at 12:01 AM, Jan Algermissen wrote:
                              >>
                              >>> Hi,
                              >>>
                              >>> suppose the following media types do exist:
                              >>>
                              >>> - application/procurement-order for orders
                              >>> - application/procurement-orderrejection for order rejections
                              >>>
                              >>> also suppose the client knows there is a resource at /order-
                              >>> processor
                              >>> that accepts orders in application/procurement-order media type.
                              >>>
                              >>> What if the client submits an order and the server wants to reject
                              >>> the order (maybe because the requested items are permanently out
                              >>> of stock)? What return code would the server use and does it make
                              >>> sense to send the order rejection document as the body of the
                              >>> (error-)response?
                              >>
                              >> I am trying to rule out the abve approach by deriving from REST's
                              >> constraints.
                              >> Here is my thinking:
                              >>
                              >> I assume (because I am not able yet to derive that from the REST
                              >> constraints)
                              >> that there is an implicit constraint in REST that demands all
                              >> application data
                              >> to be stored on the server.
                              >>
                              >> To put this in other words: a client must be able to perform any of
                              >> the next
                              >> possible transitions in an application soley based on the responses
                              >> previously
                              >> received. The client-server collaboration must not be designed in a
                              >> way that
                              >> requires a client to keep track of its own requests.
                              >>
                              >
                              > Well I don't think it is necessarily the case that the response to
                              > every request *replaces* the application state on the client.

                              No, certainly not. I hope I did not create the impression I mean that.
                              The client builds up application state as it proceeds through the
                              applications state machine.


                              > That is, a response can be use to *add to* or otherwise modify the
                              > client state. This is certainly the case for ancillary resources
                              > like images in a web page. But I think it is also valid to do this
                              > after already reaching a steady state. For example, this is what is
                              > often happening in an Ajax application. An HTTP request can retrieve
                              > new data that changes the client state but the overall client state
                              > is defined by a combination of data retrieved from multiple
                              > requests. This does present the problem of not having a single URI
                              > to represent the current state of the application but many Ajax apps
                              > are using URI fragments to deal with this. As far as I can tell,
                              > this is "ok".

                              I am not so sure - as far as bookmarking and the history goes, AJAX is
                              a mess and developers have to use tricks to make bookmarking and
                              history work. Reminds me of HTML frames...

                              >
                              >> Applied to my question above I think that a RESTful solution demands
                              >> that the
                              >> server creates application data as the basis for subsequent
                              >> interactions and
                              >> then instructs the client how to procede through the application.
                              >> (This
                              >> implies a solution where the order is created on the server and
                              >> marked
                              >> as
                              >> 'pending' to provide the application data. The client would then
                              >> alter
                              >> the
                              >> order (the application data) to 'fix' the (item-out-of-
                              >> stock-)problem.
                              >>
                              >
                              > Well I don't think it is unRESTful for a server to respond to a POST
                              > with a 200 OK rather than a 201 Created or a 303 See Other. This
                              > does create a "transient" state that the client can't return to (via
                              > a bookmark) or communicate by sharing the URI.

                              Interesting thought. It is the same though for 201 nd 303 responses, or?

                              > It is common practice to avoid doing this,

                              Hmm - is it? If the POST is simply a submission without any state
                              being changed or created on the server - that's fine.

                              > but if the state truly is transient then maybe it's the right thing?
                              > Anyways, I don't believe that REST requires that there are no
                              > transient states, which I think is what you are getting at.

                              Hmm, could be. Do you have a reference on the notion of 'transient
                              state'?

                              Jan


                              > I can't say that I have any references to back this up though -- I'm
                              > more going on the fact that I've never seen authoritative sources
                              > say otherwise.
                              >
                              > Regards,
                              >
                              > Andrew
                              >
                              >
                              >
                              >
                              >
                              > ------------------------------------
                              >
                              > Yahoo! Groups Links
                              >
                              >
                              >

                              --------------------------------------
                              Jan Algermissen

                              Mail: algermissen@...
                              Blog: http://algermissen.blogspot.com/
                              Home: http://www.jalgermissen.com
                              --------------------------------------
                            • Sam Johnston
                              Jan, I ve had some success using HTTP s own CRLF delimeter as this partition; that is to say, leaving the entity-body 8-bit clean for native representations
                              Message 14 of 18 , Nov 4, 2009
                              • 0 Attachment
                                Jan,

                                I've had some success using HTTP's own CRLF delimeter as this
                                partition; that is to say, leaving the entity-body "8-bit clean" for
                                native representations in various formats and confining the meta-model
                                (links, categories, attributes) to the HTTP headers.

                                See OCCI core spec and HTTP interface at occi-wg.org where I'm also
                                defining an XHTML rendering for a consolidated human & programmable
                                web interface (semweb w microformats/RDFa etc).

                                Sent from my iPhone

                                On 04/11/2009, at 9:17, Jan Algermissen <algermissen1971@...> wrote:

                                >
                                > On Nov 4, 2009, at 3:20 AM, mike amundsen wrote:
                                >
                                >> Jan:
                                >>
                                >> As a quick follow-up on the notion of the "getting away from..."
                                >> issue:
                                >>
                                >> Since HTTP is a testable spec, and REST is most commonly discussed in
                                >> regards to HTTP, it is a short leap to consider REST-fulness to also
                                >> be testable; to expect there to be a "right way" to implement REST
                                >> over HTTP just as there is a correct way to implement the HTTP
                                >> application protocol.
                                >
                                > But my question is related to resource design and hypermedia design,
                                > not
                                > about how to implement HTTP.
                                >
                                > If we view linking to be part of the resource design and hypermedia
                                > to just be a means of serializing resource state and resource
                                > relationships (linking) than my question is really only about
                                > resource design.
                                >
                                > So, IOW, I am looking for principles that apply to the partitioning
                                > of the application data (resource model) and to the design of the
                                > relationships between the application data partitions.
                                >
                                > Probably it makes sense to ask if the application data partitioning
                                > may extend to the client? Is it 'valid' to put application data on
                                > the client that is not also maintained on the server? I think that
                                > is likely to be the essence of the original question.
                                >
                                > Jan
                                >
                                >
                                >
                                >> But this is not a reasonable goal. In fact, it
                                >> can be a hurdle to building workable applications using the style.
                                >>
                                >> mca
                                >> http://amundsen.com/blog/
                                >>
                                >>
                                >>
                                >>
                                >> On Mon, Nov 2, 2009 at 18:51, Jan Algermissen
                                >> <algermissen1971@...> wrote:
                                >>>
                                >>> On Nov 3, 2009, at 12:13 AM, mike amundsen wrote:
                                >>>
                                >>>> Jan:
                                >>>>
                                >>>> <snip>
                                >>>> I am trying to get away from the "you could do this and you could
                                >>>> do
                                >>>> that but you also could do it that way" kinds of answers to
                                >>>> practical
                                >>>> REST design questions.
                                >>>> </snip>
                                >>>>
                                >>>> Why do you want to get away from this?
                                >>>
                                >>> Because it does not exactly sell good if you cannot back up advice
                                >>> you give
                                >>> by principles. One of the things I admire about the Software
                                >>> Architecture
                                >>> notion laid out by Perry/Wolf, Garlan/Shaw and Roy [1] is that it
                                >>> creates a
                                >>> foundation for backing up architectural design decisions by
                                >>> principles. And
                                >>> I just get this feeling of hand waving when it comes to answering
                                >>> questions
                                >>> about 'how do I do X'. I don't mind that there are many solutions
                                >>> (otherwise
                                >>> there would not be any room for design) but (at least) I often
                                >>> cannot
                                >>> articulate a clear reasoning why and when to prefer one over the
                                >>> other.
                                >>>
                                >>> Take the example problem I posted. What is better for
                                >>> order-rejection-with-suggested-modification? To send 409 and e.g. a
                                >>> UBL-like
                                >>> order-response document (like you would in the non computerized
                                >>> business
                                >>> world) or to create an order resource anyhow, set the status to
                                >>> pending and
                                >>> then let the client update the order until it can be accepted?
                                >>>
                                >>> (I had a hunch that the latter is better than the former because it
                                >>> maintains application data on the server only)
                                >>>
                                >>> Likewise, several return codes have been suggested (409, 422 for
                                >>> example).
                                >>> It makes no sense to have different returns codes specified when a
                                >>> group
                                >>> like this one cannot provide a spot-on 'yeah, it is that one and
                                >>> only that
                                >>> one' response.
                                >>>
                                >>> And even if there is a single best answer - how do you get
                                >>> interoperability
                                >>> if it is so easy for different people to have different opinions
                                >>> about it?
                                >>>
                                >>> Jan
                                >>>
                                >>>
                                >>> [1] Excuses for the names missing here
                                >>>
                                >>>
                                >>>
                                >>>>
                                >>>> mca
                                >>>> http://amundsen.com/blog/
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>> On Mon, Nov 2, 2009 at 17:09, Jan Algermissen <algermissen1971@...
                                >>>>>
                                >>>> wrote:
                                >>>>>
                                >>>>> On Nov 2, 2009, at 10:52 PM, Nick Gall wrote:
                                >>>>>
                                >>>>>>
                                >>>>>>
                                >>>>>> On Mon, Nov 2, 2009 at 4:16 PM, Jan Algermissen <algermissen1971@...
                                >>>>>>>
                                >>>>>>> wrote:
                                >>>>>>
                                >>>>>>> My hunch is that in a RESTful system
                                >>>>>>>
                                >>>>>>> a) all application state (aka session state) is on the client
                                >>>>>>> b) all application data resides on the server (as resource
                                >>>>>>> state)
                                >>>>>>>
                                >>>>>>> The question that drives me is what the significance of resource
                                >>>>>>
                                >>>>>> state
                                >>>>>>>
                                >>>>>>> is (what is its meaning/purpose in a given design? What are the
                                >>>>>>
                                >>>>>> design
                                >>>>>>>
                                >>>>>>> conditions that lead to the creation of new resource state?
                                >>>>>>> Etc.)
                                >>>>>>
                                >>>>>> I am
                                >>>>>>>
                                >>>>>>> trying to get away from the "you could do this and you could do
                                >>>>>>> that
                                >>>>>>> but you also could do it that way" kinds of answers to practical
                                >>>>>>
                                >>>>>> REST
                                >>>>>>>
                                >>>>>>> design questions.
                                >>>>>>
                                >>>>>> I think I see what you are driving at with your distinction
                                >>>>>> between
                                >>>>>> session state vs resource state, but I don't think the
                                >>>>>> distinction
                                >>>>>> is so clean in REST. Here's a relevant passage from Roy's thesis
                                >>>>>> (5.3.3):
                                >>>>>>
                                >>>>>> The application state is controlled and stored by the user agent
                                >>>>>> and
                                >>>>>> can be composed of representations from multiple servers. In
                                >>>>>> addition to freeing the server from the scalability problems of
                                >>>>>> storing state, this allows the user to directly manipulate the
                                >>>>>> state
                                >>>>>> (e.g., a Web browser's history), anticipate changes to that state
                                >>>>>> (e.g., link maps and prefetching of representations), and jump
                                >>>>>> from
                                >>>>>> one application to another (e.g., bookmarks and URI-entry
                                >>>>>> dialogs).
                                >>>>>> [emphasis added]
                                >>>>>>
                                >>>>>> So at least a copy of the resource state (in the form or a
                                >>>>>> representation of that resource) is intended to be stored and
                                >>>>>> manipulated on the client side. For example, I believe this 5.3.3
                                >>>>>> paragraph endorses the following scenario:
                                >>>>>> • client receives a representation of the works of art in a
                                >>>>>> museum
                                >>>>>> exhibit as list of art works (name of work, name of artist)
                                >>>>>> from a
                                >>>>>> museum service on some museum server
                                >>>>>> • the client extracts the name of an artist (a string) from
                                >>>>>> the
                                >>>>>> list and submits it to Wikipedia on a different set of servers
                                >>>>>> • It takes the representation from Wikipedia and formats it
                                >>>>>> into a
                                >>>>>> popup for the user's UI visualization of the museum exhibit
                                >>>>>> In this scenario the client "jumps from one application (museum
                                >>>>>> service) to another (Wikipedia)", submitting representation data
                                >>>>>> it
                                >>>>>> received from the first service to the second service. Your
                                >>>>>> description above seems to prohibit such a scenario ("to continue
                                >>>>>> its interaction with the service on another machine, it would not
                                >>>>>> only need to take the appropriate URIs with it ... but also other
                                >>>>>> data elements").
                                >>>>>>
                                >>>>>
                                >>>>> But in your scenario, the client could allways, just be use of
                                >>>>> the one
                                >>>>> initial URI, pick up the interaction. And this is (IMHO) exactly
                                >>>>> the
                                >>>>> significance of storing the application data as resource state -
                                >>>>> so
                                >>>>> that the client can pick it up again. If the data was not stored
                                >>>>> in
                                >>>>> the server it would have to be stored on the client and the
                                >>>>> ability
                                >>>>> would be lost to pick up the conversation just on the basis of
                                >>>>> the URI.
                                >>>>>
                                >>>>> Jan
                                >>>>>
                                >>>>>
                                >>>>>
                                >>>>>> It appears that REST endorses the use of "application data"
                                >>>>>> stored
                                >>>>>> on the client, at least in the case where such data was at some
                                >>>>>> point in the past received by the client as part of a
                                >>>>>> representation
                                >>>>>> of a server-based resource.
                                >>>>>>
                                >>>>>> -- Nick
                                >>>>>>
                                >>>>>>
                                >>>>>>
                                >>>>>>
                                >>>>>
                                >>>>> --------------------------------------
                                >>>>> Jan Algermissen
                                >>>>>
                                >>>>> Mail: algermissen@...
                                >>>>> Blog: http://algermissen.blogspot.com/
                                >>>>> Home: http://www.jalgermissen.com
                                >>>>> --------------------------------------
                                >>>>>
                                >>>>>
                                >>>>>
                                >>>>>
                                >>>>>
                                >>>>> ------------------------------------
                                >>>>>
                                >>>>> Yahoo! Groups Links
                                >>>>>
                                >>>>>
                                >>>>>
                                >>>>>
                                >>>>
                                >>>>
                                >>>> ------------------------------------
                                >>>>
                                >>>> Yahoo! Groups Links
                                >>>>
                                >>>>
                                >>>>
                                >>>
                                >>> --------------------------------------
                                >>> Jan Algermissen
                                >>>
                                >>> Mail: algermissen@...
                                >>> Blog: http://algermissen.blogspot.com/
                                >>> Home: http://www.jalgermissen.com
                                >>> --------------------------------------
                                >>>
                                >>>
                                >>>
                                >>>
                                >>
                                >>
                                >> ------------------------------------
                                >>
                                >> Yahoo! Groups Links
                                >>
                                >>
                                >>
                                >
                                > --------------------------------------
                                > Jan Algermissen
                                >
                                > Mail: algermissen@...
                                > Blog: http://algermissen.blogspot.com/
                                > Home: http://www.jalgermissen.com
                                > --------------------------------------
                                >
                                >
                                >
                                >
                                >
                                > ------------------------------------
                                >
                                > Yahoo! Groups Links
                                >
                                >
                                >
                              Your message has been successfully submitted and would be delivered to recipients shortly.