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

design vs runtime in representations

Expand Messages
  • Stuart Charlton
    An idea that s been needling in my head for a while, just want to float it out there. This likely has been discussed before and I ve just missed the thread.
    Message 1 of 9 , Feb 22 9:03 PM
    • 0 Attachment
      An idea that's been needling in my head for a while, just want to float it out
      there. This likely has been discussed before and I've just missed the thread.


      Suppose the following

      1. you have a media type that describes how to interact with other resources.

      2. you have resource http://MetaA that describes how to interact with a
      hyperlinked resource, http://RealA.

      3. MetaA's representation has defined a very long cache TTL (say, 3 months)

      4. A user agent that GETs the representation MetaA, caches the representation
      of MetaA, and prompts User 1 to manipulate MetaA's representation to configure
      integration of the user agent's overall application to representations that may
      be transferred to/from RealA

      5. This same user agent is leveraged by User 2 over many months to interact with
      RealA given the cached MetaA.

      6. If MetaA's representation changes, the User 1 is notified by the user agent
      (via some undefined mechanism) to change its configuration so that User 2 can
      continue to interact with RealA.

      Steps 1 - 3 are "design time", steps 4-5 are "runtime" in the traditional sense
      of the term;
      User 1 is a developer (or technical user)
      User 2 is an automaton (i.e. client code of some sort)
      Both MetaA and RealA's representations are part of the application state (aka.
      its hypermedia workspace), but the origin server(s) have set different
      expectations on how long they can be cached (MetaA for a long time, RealA for a
      short time).


      Or, if you're more concrete minded, imagine:
      - You write a scraping application that caches an HTML form to a stock quote
      service, which a developer then uses to generate URIs to GET a stock quote
      price. The application is smart enough to periodically GET the HTML form and
      can detect changes, but would require developer intervention in some cases, such
      as if the required bound form field names changed.

      My question:

      How is this not RESTful? (in the sense of it not being respectful of the
      constraints of the style and thus sacrificing some beneficial properties like
      scalability, evolvability, etc.)

      My proposition:

      1. If this is not RESTful, we'll have to talk.

      2. If this is RESTful, we need to be really careful when we say there's no
      "design time" in RESTful systems.

      I think the clearer statement is that "static code generation" (e.g. client
      stubs) is discouraged in properly RESTful systems, since it tends towards
      sucktacular rigidity in the user agent.


      Cheers
      Stu
    • Stuart Charlton
      gah, a typo Steps 1 - 3 are design time , steps 4-5 are runtime in the traditional sense of the term; should read Steps 1 - 4 are design time , steps
      Message 2 of 9 , Feb 22 9:06 PM
      • 0 Attachment
        gah, a typo

        "Steps 1 - 3 are "design time", steps 4-5 are "runtime" in the traditional sense 
        of the term;"

        should read

        "Steps 1 - 4 are "design time", steps 5-6 are "runtime" in the traditional sense 
        of the term;"



        From: Stuart Charlton <stuartcharlton@...>
        To: rest-discuss@yahoogroups.com
        Sent: Tue, February 22, 2011 10:03:47 PM
        Subject: [rest-discuss] design vs runtime in representations

         

        An idea that's been needling in my head for a while, just want to float it out
        there. This likely has been discussed before and I've just missed the thread.

        Suppose the following

        1. you have a media type that describes how to interact with other resources.

        2. you have resource http://MetaA that describes how to interact with a
        hyperlinked resource, http://RealA.

        3. MetaA's representation has defined a very long cache TTL (say, 3 months)

        4. A user agent that GETs the representation MetaA, caches the representation
        of MetaA, and prompts User 1 to manipulate MetaA's representation to configure
        integration of the user agent's overall application to representations that may
        be transferred to/from RealA

        5. This same user agent is leveraged by User 2 over many months to interact with
        RealA given the cached MetaA.

        6. If MetaA's representation changes, the User 1 is notified by the user agent
        (via some undefined mechanism) to change its configuration so that User 2 can
        continue to interact with RealA.

        Steps 1 - 3 are "design time", steps 4-5 are "runtime" in the traditional sense
        of the term;
        User 1 is a developer (or technical user)
        User 2 is an automaton (i.e. client code of some sort)
        Both MetaA and RealA's representations are part of the application state (aka.
        its hypermedia workspace), but the origin server(s) have set different
        expectations on how long they can be cached (MetaA for a long time, RealA for a
        short time).

        Or, if you're more concrete minded, imagine:
        - You write a scraping application that caches an HTML form to a stock quote
        service, which a developer then uses to generate URIs to GET a stock quote
        price. The application is smart enough to periodically GET the HTML form and
        can detect changes, but would require developer intervention in some cases, such
        as if the required bound form field names changed.

        My question:

        How is this not RESTful? (in the sense of it not being respectful of the
        constraints of the style and thus sacrificing some beneficial properties like
        scalability, evolvability, etc.)

        My proposition:

        1. If this is not RESTful, we'll have to talk.

        2. If this is RESTful, we need to be really careful when we say there's no
        "design time" in RESTful systems.

        I think the clearer statement is that "static code generation" (e.g. client
        stubs) is discouraged in properly RESTful systems, since it tends towards
        sucktacular rigidity in the user agent.

        Cheers
        Stu


      • wahbedahbe
        ... ... Stu, The amount of runtime flexibility depends on the hypermedia controls that are available. For example, if there were no links or forms in
        Message 3 of 9 , Feb 23 7:49 AM
        • 0 Attachment
          --- In rest-discuss@yahoogroups.com, Stuart Charlton <stuartcharlton@...> wrote:
          >
          > gah, a typo
          >
          > "Steps 1 - 3 are "design time", steps 4-5 are "runtime" in the traditional
          > sense
          > of the term;"
          >
          > should read
          >
          > "Steps 1 - 4 are "design time", steps 5-6 are "runtime" in the traditional
          > sense of the term;"
          >
          > ________________________________
          > From: Stuart Charlton <stuartcharlton@...>
          > To: rest-discuss@yahoogroups.com
          > Sent: Tue, February 22, 2011 10:03:47 PM
          > Subject: [rest-discuss] design vs runtime in representations
          >

          <snip>

          > My question:
          >
          > How is this not RESTful? (in the sense of it not being respectful of the
          > constraints of the style and thus sacrificing some beneficial properties like
          > scalability, evolvability, etc.)
          >
          > My proposition:
          >
          > 1. If this is not RESTful, we'll have to talk.
          >
          > 2. If this is RESTful, we need to be really careful when we say there's no
          > "design time" in RESTful systems.
          >
          > I think the clearer statement is that "static code generation" (e.g. client
          > stubs) is discouraged in properly RESTful systems, since it tends towards
          > sucktacular rigidity in the user agent.
          >
          > Cheers
          > Stu
          >

          Stu,

          The amount of runtime flexibility depends on the hypermedia controls that are available. For example, if there were no links or forms in HTML, then the browser (or the user) would be bound to the interface specifics of every service out there.

          A hypermedia control is only partially a data construct. A control is instantiated as the result of client processing of the data. If a client does not (or cannot) interpret <form> as a control then you lose the runtime flexibility that that control provides.

          A developer can make up for that by interpreting the control themselves and coding the knowledge in the client, but then as you say, they are turning a runtime binding into a design-time binding.

          HTML and it's controls are primarily designed for browsers presenting information to humans. It has some features like <link> and rel that target alternate, machine-driven clients but the language is not powerful enough to provide equivalent machine controls for every human control expressible in the language.

          I believe that it is possible to build machine controls that provide much more run time flexibility than is afforded machines by HTML. I always point to CCXML as an example of this. I suspect, however, that the more powerful machine controls are, the more they must target specific types of machines. I think the whole area needs more investigation though.

          In short, I don't think it's a question of RESTful vs. not RESTful. I think you are simply noting that the degree of runtime flexibility afforded to the system is a function of both the hypermedia format *and* the client.

          Regards,

          Andrew
        • Mike Kelly
          On Wed, Feb 23, 2011 at 5:03 AM, Stuart Charlton ... Do you mean RESTful applications consumed by automated clients? If so, +1 I think it s a key consideration
          Message 4 of 9 , Feb 23 8:11 AM
          • 0 Attachment
            On Wed, Feb 23, 2011 at 5:03 AM, Stuart Charlton
            <stuartcharlton@...> wrote:
            >
            > 2. If this is RESTful, we need to be really careful when we say there's no
            > "design time" in RESTful systems.
            >

            Do you mean RESTful applications consumed by automated clients? If so, +1

            I think it's a key consideration when designing media types,
            specifically their hypermedia controls, that are aimed at these sorts
            of automated clients. Media types that over-provision mechanisms for
            run-time dynamism may give servers false confidence in terms of what
            sorts of changes they can enact.

            Cheers,
            Mike
          • Stuart Charlton
            Comments inline ... Yes that s what I meant. ... Right; the media type itself needs to provide guidance on expectations of how it will be used. For example, I
            Message 5 of 9 , Feb 23 12:59 PM
            • 0 Attachment
              Comments inline

              --- On Wed, 2/23/11, Mike Kelly <mike@...> wrote:

              > > 2. If this is RESTful, we need to be really careful
              > when we say there's no
              > > "design time" in RESTful systems.
              > >
              >
              > Do you mean RESTful applications consumed by automated
              > clients? If so, +1

              Yes that's what I meant.

              > I think it's a key consideration when designing media
              > types,
              > specifically their hypermedia controls, that are aimed at
              > these sorts
              > of automated clients. Media types that over-provision
              > mechanisms for
              > run-time dynamism may give servers false confidence in
              > terms of what
              > sorts of changes they can enact.

              Right; the media type itself needs to provide guidance on expectations of how it will be used.

              For example, I think media types for automated consumption really should refer to something like RFC 5829 for dealing with versioning, with a clear delineation of elements that can/should change & be dealt with at runtime, vs. elements that may require more lead time and thus a "successor-version" link would help some user agents out.

              Stu
            • mike amundsen
              Stu: the idea of using RFC 5829 is interesting. on a similar track, iv e been toying w/ using the RFC 2119 words (MUST, MAY, etc.) as a way to decorate
              Message 6 of 9 , Feb 23 1:53 PM
              • 0 Attachment
                Stu:

                the idea of using RFC 5829 is interesting.

                on a similar track, iv'e been toying w/ using the RFC 2119 words
                (MUST, MAY, etc.) as a way to decorate hypermedia elements in a
                "profile" that is consumable by agents. in theory (LOL) agents could
                compare their own "design-time profile" (indicating what that agent
                currently supports) with the "run-time profile" provided in the
                response (@profile in the document, profile param in media type, Link
                header, etc.). Mismatches could be handled by the agent as "stop",
                "warn", "ignore", etc.

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


                #RESTFest 2010
                http://rest-fest.googlecode.com




                On Wed, Feb 23, 2011 at 15:59, Stuart Charlton <stuartcharlton@...> wrote:
                >
                > Comments inline
                >
                > --- On Wed, 2/23/11, Mike Kelly <mike@...> wrote:
                >
                >> > 2. If this is RESTful, we need to be really careful
                >> when we say there's no
                >> > "design time" in RESTful systems.
                >> >
                >>
                >> Do you mean RESTful applications consumed by automated
                >> clients? If so, +1
                >
                > Yes that's what I meant.
                >
                >> I think it's a key consideration when designing media
                >> types,
                >> specifically their hypermedia controls, that are aimed at
                >> these sorts
                >> of automated clients. Media types that over-provision
                >> mechanisms for
                >> run-time dynamism may give servers false confidence in
                >> terms of what
                >> sorts of changes they can enact.
                >
                > Right; the media type itself needs to provide guidance on expectations of how it will be used.
                >
                > For example, I think media types for automated consumption really should refer to something like RFC 5829 for dealing with versioning, with a clear delineation of elements that can/should change & be dealt with at runtime, vs. elements that may require more lead time and thus a "successor-version" link would help some user agents out.
                >
                > Stu
                >
                >
                >
                >
                >
                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
              • Stuart Charlton
                comments inline ... Yes, I agree. ... Well, the question is, should domain-specific data be tightly coupled to a generic media type or not. Let s assume a
                Message 7 of 9 , Feb 23 6:10 PM
                • 0 Attachment
                  comments inline

                  --- On Wed, 2/23/11, wahbedahbe <andrew.wahbe@...> wrote:


                  > The amount of runtime flexibility depends on the hypermedia controls that are available. For example, if there
                  > were no links or forms in HTML, then the browser (or the user) would be bound to the interface specifics of
                  > every service out there.

                  Yes, I agree.

                  > A developer can make up for that by interpreting the control themselves and coding the knowledge in the
                  > client, but then as you say, they are turning a runtime binding into a design-time binding.

                  Well, the question is, should domain-specific data be tightly coupled to a generic media type or not.

                  Let's assume a generic media type, like a <form>. A representation may have an <input name="quoteSymbol"> that a user agent could bind against to its application. However, we're always going to have disagreement in data: between representations from different origin servers, between the representation and the user agent's application - not everyone will use the same data definitions, symbols, etc. The best we can hope for is standardized bits & pieces of highly common data, perhaps some highly common industry consortium data (e.g. ISO 20022 or EDI), and a straightforward way to handle the rest of the differences.

                  This straightforward way of handling differences tends to imply a combination of:
                  1. an explicit data model in the media type,
                  2. data transformation advice (e.g. linking to an XSLT),
                  3. deeper semantic description from another representation (e.g. SKOS, OWL, etc.),
                  4. or a user has to manipulate the representation to conform to client application expectations.

                  The latter case we might call a mashup developer today.

                  > I believe that it is possible to build machine controls that provide much more run time flexibility than is
                  > afforded machines by HTML. I always point to CCXML as an example of this. I suspect, however, that the more
                  > powerful machine controls are, the more they must target specific types of machines. I think the whole area
                  > needs more investigation though.

                  SCXML (and CCXML by extension), has an interesting take on this and may have a practical solution for future media types, though I wish SCXML had richer support for HTTP interactions. It partly gets around the data problem by describing an explicit data model and mappings to ECMAscript & XPath.

                  But even still, if we had an application that was concerned with integration, we would need some kind of configuration in the user agent to bridge the gap between the data (and events / state transitions!) in the representation and my internal application data. This configuration would occur AFTER we had retrieved the SCXML document. We could build some clever semantic extensions to ease this burden, but practically speaking, it can only go so far.

                  This is why I brought up the need for a design time / run time separation between retrieving the representation describing an unsafe operation (e.g. a stock quote order form), or a process (e.g. an SCXML to order stocks), and the actual endpoints that will be repeatedly invoked at runtime (e.g. a live stock quote).

                  We can't get completely away from the divergence of semantics in data & actions, though I bet we could close the gap from today's situation by quite a lot.

                  Cheers
                  Stu
                • Stuart Charlton
                  comments inline ... Yeah, I mean why not, right? I know it was designed for content management, but representations that include forms really could use
                  Message 8 of 9 , Feb 23 6:17 PM
                  • 0 Attachment
                    comments inline

                    --- On Wed, 2/23/11, mike amundsen <mamund@...> wrote:

                    > the idea of using RFC 5829 is interesting.

                    Yeah, I mean why not, right? I know it was designed for content management, but representations that include forms really could use versioning like this too, so that rigid user agents can have time to adapt. They could bind against a specific version, whereas a more adaptive user agent could always bind against latest-version.

                    > on a similar track, iv'e been toying w/ using the RFC 2119
                    > words
                    > (MUST, MAY, etc.) as a way to decorate hypermedia elements
                    > in a
                    > "profile" that is consumable by agents. in theory (LOL)
                    > agents could
                    > compare their own "design-time profile" (indicating what
                    > that agent
                    > currently supports) with the "run-time profile" provided in
                    > the
                    > response (@profile in the document, profile param in media
                    > type, Link
                    > header, etc.).  Mismatches could be handled by the
                    > agent as "stop",
                    > "warn", "ignore", etc.


                    Cool, reminds me of Telnet option negotiation: http://www.faqs.org/rfcs/rfc1143.html

                    Cheers
                    Stu
                  • mike amundsen
                    ... ha! forgot about those. thanks. mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me #RESTFest 2010
                    Message 9 of 9 , Feb 23 6:38 PM
                    • 0 Attachment
                      > Cool, reminds me of Telnet option negotiation: http://www.faqs.org/rfcs/rfc1143.html

                      ha! forgot about those.

                      thanks.

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


                      #RESTFest 2010
                      http://rest-fest.googlecode.com




                      On Wed, Feb 23, 2011 at 21:17, Stuart Charlton <stuartcharlton@...> wrote:
                      > comments inline
                      >
                      > --- On Wed, 2/23/11, mike amundsen <mamund@...> wrote:
                      >
                      >> the idea of using RFC 5829 is interesting.
                      >
                      > Yeah, I mean why not, right?   I know it was designed for content management, but representations that include forms really could use versioning like this too, so that rigid user agents can have time to adapt.  They could bind against a specific version, whereas a more adaptive user agent could always bind against latest-version.
                      >
                      >> on a similar track, iv'e been toying w/ using the RFC 2119
                      >> words
                      >> (MUST, MAY, etc.) as a way to decorate hypermedia elements
                      >> in a
                      >> "profile" that is consumable by agents. in theory (LOL)
                      >> agents could
                      >> compare their own "design-time profile" (indicating what
                      >> that agent
                      >> currently supports) with the "run-time profile" provided in
                      >> the
                      >> response (@profile in the document, profile param in media
                      >> type, Link
                      >> header, etc.).  Mismatches could be handled by the
                      >> agent as "stop",
                      >> "warn", "ignore", etc.
                      >
                      >
                      > Cool, reminds me of Telnet option negotiation: http://www.faqs.org/rfcs/rfc1143.html
                      >
                      > Cheers
                      > Stu
                      >
                      >
                      >
                      >
                      >
                      >
                      > ------------------------------------
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.