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

application state vs shared state.

Expand Messages
  • Dan
    In (a follow-on comment to his own) blog post [1], Roy stated: Don t confuse application state (the state of the user s application of computing to a given
    Message 1 of 6 , Oct 6, 2011
      In (a follow-on comment to his own) blog post [1], Roy stated:

      "Don't confuse application state (the state of the user's application of computing to a given task) with resource state (the state of the world as exposed by a given service). They are not the same thing."

      To my naive way of thinking, this suggests that use cases (which represent an individual users journey through the system) should not be represented as use cases.

      In contrast, entities clearly do representing "the state of the world", and so would seem perfectly fine to be considered as resources. (OK, they might need wrapping up in DTOs or projections to allow client/server to evolve differently, but that's a different point).

      Anyway, my question is: can someone unpack Roy's statement for me? What is the difference between what Roy calls "application state" (which he says isn't a resource) vs use case state (which may here seem to consider is perfectly legit as a resource).

      thx
      Dan

      [1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-744
    • Will Hartung
      ... Resource state is I have FM Radios, they re blue, andI have 10 of them Application state is I have an FM Radio, toothbrush, box of crayons, and quart of
      Message 2 of 6 , Oct 6, 2011
        On Thu, Oct 6, 2011 at 4:00 PM, Dan <dan@...> wrote:
         

        In (a follow-on comment to his own) blog post [1], Roy stated:

        "Don't confuse application state (the state of the user's application of computing to a given task) with resource state (the state of the world as exposed by a given service). They are not the same thing."

        Anyway, my question is: can someone unpack Roy's statement for me? What is the difference between what Roy calls "application state" (which he says isn't a resource) vs use case state (which may here seem to consider is perfectly legit as a resource).

        Resource state is "I have FM Radios, they're blue, andI have 10 of them"

        Application state is "I have an FM Radio, toothbrush, box of crayons, and quart of penzoil in my shopping cart".

        The system (in this case) doesn't care or know about "shopping carts". It only cares about items and orders. Your application may be kind enough to accumulate stuff in to a cart, but when you place the order, the system takes an entire order (all of the items) all at once (and deal with any issues that the system may have with your request, such as out of stock or back orders ,or whatever).

        But all the picking, browsing, searching, last item seen, etc. Those are parts of the application, part of the user interface.

        Regards,

        Will Hartung
        (willh@...)

      • mike amundsen
        Dan: i ve worked on this idea (app state vs. resource state) a number of times and will offer this the follow as a way to start your own way of thinking about
        Message 3 of 6 , Oct 6, 2011
          Dan:

          i've worked on this idea (app state vs. resource state) a number of
          times and will offer this the follow as a way to start your own way of
          thinking about it.

          First (again) Fielding's comment:
          "Don’t confuse application state (the state of the user’s application
          of computing to a given task)
          with resource state (the state of the world as exposed by a given
          service). They are not the same thing."
          - Fielding, blog post 2008

          First-level reduction:
          "Don't confuse ... the state of the user's application ... with ...
          the state of ... a given service."

          A refinement via assumption:
          user's application === browser
          given service === server

          Yields:
          Don't confuse the state of the browser with the state of the server

          This is especially true if you keep in mind that the server likely is
          exposing a unique "state of the world" for each user interacting with
          that service.

          Just a thought...



          mca
          http://amundsen.com/blog/
          http://twitter.com@mamund
          http://mamund.com/foaf.rdf#me





          On Thu, Oct 6, 2011 at 19:00, Dan <dan@...> wrote:
          > In (a follow-on comment to his own) blog post [1], Roy stated:
          >
          > "Don't confuse application state (the state of the user's application of computing to a given task) with resource state (the state of the world as exposed by a given service). They are not the same thing."
          >
          > To my naive way of thinking, this suggests that use cases (which represent an individual users journey through the system) should not be represented as use cases.
          >
          > In contrast, entities clearly do representing "the state of the world", and so would seem perfectly fine to be considered as resources.  (OK, they might need wrapping up in DTOs or projections to allow client/server to evolve differently, but that's a different point).
          >
          > Anyway, my question is: can someone unpack Roy's statement for me?  What is the difference between what Roy calls "application state" (which he says isn't a resource) vs use case state (which may here seem to consider is perfectly legit as a resource).
          >
          > thx
          > Dan
          >
          > [1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-744
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
        • Mark Baker
          ... I don t consider Roy s description opaque, but perhaps that s just me. But consider a banking application; the balance of an account is resource state,
          Message 4 of 6 , Oct 6, 2011
            On Thu, Oct 6, 2011 at 7:00 PM, Dan <dan@...> wrote:
            > Anyway, my question is: can someone unpack Roy's statement for me?  What is the difference between what Roy calls "application state" (which he says isn't a resource) vs use case state (which may here seem to consider is perfectly legit as a resource).

            I don't consider Roy's description opaque, but perhaps that's just me.

            But consider a banking application; the balance of an account is
            resource state, while the fact that the browser is currently showing
            the balance (versus, say, showing the bill payment form) is
            application state.

            Mark.
          • bryan_w_taylor
            Application state is defined by a representation that is handed to a user agent. It represents a snapshot of the clients narrow view of the world as it
            Message 5 of 6 , Oct 7, 2011
              Application state is defined by a representation that is handed to a user agent. It represents a snapshot of the clients narrow view of the world as it navigates around. With each requests, a small subset of the overall server state is viewed and certain transitions to other application states are offered. For example, it might be a page with a list of 25 mailing list posts. It may have links labelled with relations like "next" and "previous" or a way to POST a new submission to be added to the collection. The current representation being processed reflects the server's communication about its resource state at a moment in time when the server answered a request for a resource in whatever media type.

              While you are staring at a list of items on the screen of your browser, someone else may have posted a new mail to the list. Or the site's owner may have redacted an email because it was spam. Or changed a configuration setting such as the default number of items shown on a page or a banner message or ad image. These are changes to resource state. They affect how the server might produce a representation for a future request.

              --- In rest-discuss@yahoogroups.com, "Dan" <dan@...> wrote:
              >
              > In (a follow-on comment to his own) blog post [1], Roy stated:
              >
              > "Don't confuse application state (the state of the user's application of computing to a given task) with resource state (the state of the world as exposed by a given service). They are not the same thing."
            • Ivan Žužak
              Here s an explanation by Roy: http://lists.w3.org/Archives/Public/www-tag/2010Oct/0100.html Ivan
              Message 6 of 6 , Oct 8, 2011
                Here's an explanation by Roy:

                Ivan

                On Fri, Oct 7, 2011 at 01:00, Dan <dan@...> wrote:
                 

                In (a follow-on comment to his own) blog post [1], Roy stated:

                "Don't confuse application state (the state of the user's application of computing to a given task) with resource state (the state of the world as exposed by a given service). They are not the same thing."

                To my naive way of thinking, this suggests that use cases (which represent an individual users journey through the system) should not be represented as use cases.

                In contrast, entities clearly do representing "the state of the world", and so would seem perfectly fine to be considered as resources. (OK, they might need wrapping up in DTOs or projections to allow client/server to evolve differently, but that's a different point).

                Anyway, my question is: can someone unpack Roy's statement for me? What is the difference between what Roy calls "application state" (which he says isn't a resource) vs use case state (which may here seem to consider is perfectly legit as a resource).

                thx
                Dan

                [1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-744


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