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

Impedance Mismatch

Expand Messages
  • Greg Young
    Let s assume for a moment that the following supposition is true: At their heart many systems that we develop are behavior not data centric. REST is
    Message 1 of 19 , Jun 3, 2009
    • 0 Attachment
      Let's assume for a moment that the following supposition is true: At
      their heart many systems that we develop are behavior not data
      centric.

      REST is essentially a data centric interchange. We can in various ways
      build behavioral interfaces as data representations. Seb gave good
      examples using his rel links, another good example would be modelling
      a resource as a state machine. These solutions do however offer a
      rather large impedance mismatch with that of our behavioral system
      (often times creating a large language gap as an example).

      When does this impedance mismatch become appropriate to take on?

      Greg

      --
      It is the mark of an educated mind to be able to entertain a thought
      without accepting it.
    • Solomon Duskis
      I don t think that REST is a data-centric interchange at its core philosophy. IMHO, the data-centricity is how we as a community have erroneously been using
      Message 2 of 19 , Jun 3, 2009
      • 0 Attachment
        I don't think that REST is "a data-centric interchange" at its core philosophy.  IMHO, the data-centricity is how we as a community have erroneously been using the term REST.  I think that it's important to challenge this impedance mismatch now :).  I think that this is one of the points that Roy Fielding was trying to make half a year ago: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

        -Solomon

        On Wed, Jun 3, 2009 at 10:01 AM, Greg Young <gregoryyoung1@...> wrote:


        Let's assume for a moment that the following supposition is true: At
        their heart many systems that we develop are behavior not data
        centric.

        REST is essentially a data centric interchange. We can in various ways
        build behavioral interfaces as data representations. Seb gave good
        examples using his rel links, another good example would be modelling
        a resource as a state machine. These solutions do however offer a
        rather large impedance mismatch with that of our behavioral system
        (often times creating a large language gap as an example).

        When does this impedance mismatch become appropriate to take on?

        Greg

        --
        It is the mark of an educated mind to be able to entertain a thought
        without accepting it.


      • Sebastien Lambla
        Greg, Before I attempt a response to this, I have to clarify a point. Links are the server instructing the client which state transitions are available, and
        Message 3 of 19 , Jun 3, 2009
        • 0 Attachment
          Greg,

          Before I attempt a response to this, I have to clarify a point.

          Links are the server instructing the client which state transitions are
          available, and the client knows how to manage those state transitions
          because the semantics of those are carried out of band. Hence
          rel=change-of-address and rel=replace-address carry different meanings that
          help the client decide which state transition to apply.

          So while partial state is exchanged back and forth between clients and
          servers, such an exchange is not context-free. While the interface is
          generic, and the state descriptive, the trigger of the state change (the
          navigation) is completely dependent on the current context in which the link
          was given.

          I'm very much unsure if the interchange is data centric, I would say it is
          an exchange of data that is driven by links that are qualified in intent and
          relationship.

          In other words, I'm unsure what the difference is between a command
          available contextually to a client called ImMovingCommand and an address
          resource that gets sent to a link for which the relationship is communicated
          OOB as an address change.

          I'm pretty sure I'm missing the very big boat there, so any help to clarify
          would be very much appreciated.

          Seb


          -----Original Message-----
          From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
          Behalf Of Greg Young
          Sent: 03 June 2009 15:02
          To: Rest List
          Subject: [rest-discuss] Impedance Mismatch

          Let's assume for a moment that the following supposition is true: At
          their heart many systems that we develop are behavior not data
          centric.

          REST is essentially a data centric interchange. We can in various ways
          build behavioral interfaces as data representations. Seb gave good
          examples using his rel links, another good example would be modelling
          a resource as a state machine. These solutions do however offer a
          rather large impedance mismatch with that of our behavioral system
          (often times creating a large language gap as an example).

          When does this impedance mismatch become appropriate to take on?

          Greg

          --
          It is the mark of an educated mind to be able to entertain a thought
          without accepting it.


          ------------------------------------

          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/



          View your Twitter and Flickr updates from one place - Learn more!
        • johnzabroski
          ... So, the first step is to recognize this is not at all a REST question. Put it to you this way, at what point does it make more sense to write things
          Message 4 of 19 , Jun 3, 2009
          • 0 Attachment
            --- In rest-discuss@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
            >
            > Let's assume for a moment that the following supposition is true: At
            > their heart many systems that we develop are behavior not data
            > centric.
            >
            > REST is essentially a data centric interchange. We can in various ways
            > build behavioral interfaces as data representations. Seb gave good
            > examples using his rel links, another good example would be modelling
            > a resource as a state machine. These solutions do however offer a
            > rather large impedance mismatch with that of our behavioral system
            > (often times creating a large language gap as an example).
            >
            > When does this impedance mismatch become appropriate to take on?
            >
            > Greg

            So, the first step is to recognize this is not at all a REST question. Put it to you this way, at what point does it make more sense to write things declaratively than imperatively?

            With declarative, you are saying "be"; with imperative, you are saying "do".

            This is a pretty huge consequence. In order to be, you need to answer what. In order to do, you need to answer how. If you can make the leap from do to be, then <s>do</s> be it. For one, I think you can reason about reliability of your systems much easier if everything is declarative. Most software problems are related to poorly configured software, in part because we often don't know what our settings do, or we can't easily understand how our production environments differ from development environments.

            For me, the value of a declarative system is that my CEO can query and drill-down into any aspect of my system's design. There are no blackboxes; just mathematical reasoning.

            I also think "modeling a resource as a state machine" is an oversimplification. There are many ways to implement a state machine, not all of them correct from a decoupling standpoint. Moreover, modeling programs as Finite State Automata is not easy, however once done correctly the end result is highly robust software that correctly reuses itself. You can very easily stick guards everywhere in your state machine and then say, "Look at this state machine I built", and "mommy might stick it on the fridge", but you've just littered your architecture with termites eager to decay every arch.

            A state machine without guards is effectively a declarative solution, by the way. Provided, of course, that the state machines it cooperates with are designed the same way. Pat Helland actually has a CIDR paper that sort of addresses such a theme: Can we really continue building reliable components out of unreliable ones? He uses a quick sand metaphor, and doesn't deal directly with object state machines, but the lesson applies regardless.
          • Greg Young
            ... I am not sure I want to touch this one with a 30 foot pole but ... Do CEO s need access to *any* aspect of the system or those with business value? More
            Message 5 of 19 , Jun 4, 2009
            • 0 Attachment
              > For me, the value of a declarative system is that my CEO can query and
              > drill-down into any aspect of my system's design. There are no blackboxes;
              > just mathematical reasoning.

              I am not sure I want to touch this one with a 30 foot pole but ...

              Do CEO's need access to *any* aspect of the system or those with
              business value? More often than not what your CEO is interested in is
              not your transactional objects but roll ups etc and analysis performed
              upon them. I understand the argument for OLAP but using this as an
              argument for REST seems to me to be like using the fact that they
              where skates as an argument for why I should watch tennis.

              Beyond that for a transactional system there is still a "black box" in
              terms of how data affects other data. Consider an example of a
              resource that tells me sales for the day and a resource that accepts
              sales. There is a direct link between these two that may or may not be
              exposed.


              BTW the solutions I use are fairly far from imperative. Currently I am
              using what would be categorized as MEST (yes there can be argument if
              MEST is just the new buzzword for messaging). I have lately been using
              resources on my read side and messaging on my transactional side. I
              have attempted at using REST more completely but am running into the
              fact that it just doesn't seem to make any sense whatsoever in a
              complex transactional situation.

              On Thu, Jun 4, 2009 at 2:50 AM, johnzabroski <johnzabroski@...> wrote:
              >
              >
              > --- In rest-discuss@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
              >>
              >> Let's assume for a moment that the following supposition is true: At
              >> their heart many systems that we develop are behavior not data
              >> centric.
              >>
              >> REST is essentially a data centric interchange. We can in various ways
              >> build behavioral interfaces as data representations. Seb gave good
              >> examples using his rel links, another good example would be modelling
              >> a resource as a state machine. These solutions do however offer a
              >> rather large impedance mismatch with that of our behavioral system
              >> (often times creating a large language gap as an example).
              >>
              >> When does this impedance mismatch become appropriate to take on?
              >>
              >> Greg
              >
              > So, the first step is to recognize this is not at all a REST question. Put
              > it to you this way, at what point does it make more sense to write things
              > declaratively than imperatively?
              >
              > With declarative, you are saying "be"; with imperative, you are saying "do".
              >
              > This is a pretty huge consequence. In order to be, you need to answer what.
              > In order to do, you need to answer how. If you can make the leap from do to
              > be, then <s>do</s> be it. For one, I think you can reason about reliability
              > of your systems much easier if everything is declarative. Most software
              > problems are related to poorly configured software, in part because we often
              > don't know what our settings do, or we can't easily understand how our
              > production environments differ from development environments.
              >
              > For me, the value of a declarative system is that my CEO can query and
              > drill-down into any aspect of my system's design. There are no blackboxes;
              > just mathematical reasoning.
              >
              > I also think "modeling a resource as a state machine" is an
              > oversimplification. There are many ways to implement a state machine, not
              > all of them correct from a decoupling standpoint. Moreover, modeling
              > programs as Finite State Automata is not easy, however once done correctly
              > the end result is highly robust software that correctly reuses itself. You
              > can very easily stick guards everywhere in your state machine and then say,
              > "Look at this state machine I built", and "mommy might stick it on the
              > fridge", but you've just littered your architecture with termites eager to
              > decay every arch.
              >
              > A state machine without guards is effectively a declarative solution, by the
              > way. Provided, of course, that the state machines it cooperates with are
              > designed the same way. Pat Helland actually has a CIDR paper that sort of
              > addresses such a theme: Can we really continue building reliable components
              > out of unreliable ones? He uses a quick sand metaphor, and doesn't deal
              > directly with object state machines, but the lesson applies regardless.
              >
              >



              --
              It is the mark of an educated mind to be able to entertain a thought
              without accepting it.
            • Mike Kelly
              ... Appropriate resource design and use of hyperlinks can expose those relationships. If the resource that accepts sales also lists all sales, then a list for
              Message 6 of 19 , Jun 4, 2009
              • 0 Attachment
                Greg Young wrote:
                >
                > Beyond that for a transactional system there is still a "black box" in
                > terms of how data affects other data. Consider an example of a
                > resource that tells me sales for the day and a resource that accepts
                > sales. There is a direct link between these two that may or may not be
                > exposed.
                >

                Appropriate resource design and use of hyperlinks can expose those
                relationships.

                If the resource that accepts sales also lists all sales, then a list for
                today should be treated as a subset of that resource

                POST /sales
                GET /sales

                GET /sales;today

                Affect of POST can easily be understood by proxy caches and
                intermediaries so that doesn't seem black box

                Cheers,
                Mike
              • Greg Young
                Sure for a proxy cache or for intermediaries But its still a black box for a CEO!!! which was the context under discussion. ... -- It is the mark of an
                Message 7 of 19 , Jun 4, 2009
                • 0 Attachment
                  Sure for a proxy cache or for intermediaries


                  But its still a black box for a CEO!!! which was the context under discussion.




                  On Thu, Jun 4, 2009 at 8:48 AM, Mike Kelly <mike@...> wrote:
                  > Greg Young wrote:
                  >>
                  >> Beyond that for a transactional system there is still a "black box" in
                  >> terms of how data affects other data. Consider an example of a
                  >> resource that tells me sales for the day and a resource that accepts
                  >> sales. There is a direct link between these two that may or may not be
                  >> exposed.
                  >>
                  >
                  > Appropriate resource design and use of hyperlinks can expose those
                  > relationships.
                  >
                  > If the resource that accepts sales also lists all sales, then a list for
                  > today should be treated as a subset of that resource
                  >
                  > POST /sales
                  > GET /sales
                  >
                  > GET /sales;today
                  >
                  > Affect of POST can easily be understood by proxy caches and intermediaries
                  > so that doesn't seem black box
                  >
                  > Cheers,
                  > Mike
                  >



                  --
                  It is the mark of an educated mind to be able to entertain a thought
                  without accepting it.
                • Mike Kelly
                  .. are you implying most CEOs are less intelligent than a proxy?! Maybe we just need to use better/more appropriate grammar in our URIs?
                  Message 8 of 19 , Jun 4, 2009
                  • 0 Attachment
                    .. are you implying most CEOs are less intelligent than a proxy?!

                    Maybe we just need to use better/more appropriate grammar in our URIs?



                    Greg Young wrote:
                    > Sure for a proxy cache or for intermediaries
                    >
                    >
                    > But its still a black box for a CEO!!! which was the context under discussion.
                    >
                    >
                    >
                    >
                    > On Thu, Jun 4, 2009 at 8:48 AM, Mike Kelly <mike@...> wrote:
                    >
                    >> Greg Young wrote:
                    >>
                    >>> Beyond that for a transactional system there is still a "black box" in
                    >>> terms of how data affects other data. Consider an example of a
                    >>> resource that tells me sales for the day and a resource that accepts
                    >>> sales. There is a direct link between these two that may or may not be
                    >>> exposed.
                    >>>
                    >>>
                    >> Appropriate resource design and use of hyperlinks can expose those
                    >> relationships.
                    >>
                    >> If the resource that accepts sales also lists all sales, then a list for
                    >> today should be treated as a subset of that resource
                    >>
                    >> POST /sales
                    >> GET /sales
                    >>
                    >> GET /sales;today
                    >>
                    >> Affect of POST can easily be understood by proxy caches and intermediaries
                    >> so that doesn't seem black box
                    >>
                    >> Cheers,
                    >> Mike
                    >>
                    >>
                    >
                    >
                    >
                    >
                  • Greg Young
                    What I am saying is that a proxy only needs to know that there is *a* relationship between two things a CEO needs to understand what that relationship is. ...
                    Message 9 of 19 , Jun 4, 2009
                    • 0 Attachment
                      What I am saying is that a proxy only needs to know that there is *a*
                      relationship between two things a CEO needs to understand what that
                      relationship is.



                      On Thu, Jun 4, 2009 at 8:58 AM, Mike Kelly <mike@...> wrote:
                      > .. are you implying most CEOs are less intelligent than a proxy?!
                      >
                      > Maybe we just need to use better/more appropriate grammar in our URIs?
                      >
                      >
                      >
                      > Greg Young wrote:
                      >>
                      >> Sure for a proxy cache or for intermediaries
                      >>
                      >>
                      >> But its still a black box for a CEO!!! which was the context under
                      >> discussion.
                      >>
                      >>
                      >>
                      >>
                      >> On Thu, Jun 4, 2009 at 8:48 AM, Mike Kelly <mike@...> wrote:
                      >>
                      >>>
                      >>> Greg Young wrote:
                      >>>
                      >>>>
                      >>>> Beyond that for a transactional system there is still a "black box" in
                      >>>> terms of how data affects other data. Consider an example of a
                      >>>> resource that tells me sales for the day and a resource that accepts
                      >>>> sales. There is a direct link between these two that may or may not be
                      >>>> exposed.
                      >>>>
                      >>>>
                      >>>
                      >>> Appropriate resource design and use of hyperlinks can expose those
                      >>> relationships.
                      >>>
                      >>> If the resource that accepts sales also lists all sales, then a list for
                      >>> today should be treated as a subset of that resource
                      >>>
                      >>> POST /sales
                      >>> GET /sales
                      >>>
                      >>> GET /sales;today
                      >>>
                      >>> Affect of POST can easily be understood by proxy caches and
                      >>> intermediaries
                      >>> so that doesn't seem black box
                      >>>
                      >>> Cheers,
                      >>> Mike
                      >>>
                      >>>
                      >>
                      >>
                      >>
                      >>
                      >
                      >



                      --
                      It is the mark of an educated mind to be able to entertain a thought
                      without accepting it.
                    • Sebastien Lambla
                      I was pretty sure I replied but can t find the message anywhere, so trying ... You seem to be implying that those 5 different ways, and different flows, would
                      Message 10 of 19 , Jun 4, 2009
                      • 0 Attachment
                        I was pretty sure I replied but can't find the message anywhere, so trying
                        again:

                        > Consider a different use case ... consider setting a default address
                        > (out of a series of existing addresses) onto a customer. Now imagine
                        > that there are 5 different ways this can happen. This rather quickly
                        > seems to sprial out of control.

                        You seem to be implying that those 5 different ways, and different flows,
                        would result in the same resource being modified in the same way without
                        context.

                        Stop me if i'm wrong, but if you were to change an address in 5 different
                        ways using commands, you would have 5 different commands?

                        In ReST, the state that is shared between client and server isn't without
                        workflows. You modify a resource (the concept of address) by sending one or
                        many representations to one or many URIs.

                        Nothing prevents you from operating various workflows through the use of
                        various URIs, or if modelled on a state machine, to keep track of where in
                        the workflow a client application is, and instruct on what to do next, based
                        on the current state being sent back and forth by the client.

                        I think i'm still missing the point as to why changing an address in 5
                        different ways through 5 different flows would be impossible or messy in
                        ReST? The only way I could understand such a statement would be in the case
                        where you believe that they all end up triggering the same operation on the
                        same resource, which is not a ReST constraint per se.

                        Seb
                      • Sebastien Lambla
                        ... What does the URI or putting a grammar on it bring to the party? It seems to me to be an orthogonal concern. Seb
                        Message 11 of 19 , Jun 4, 2009
                        • 0 Attachment
                          > Maybe we just need to use better/more appropriate grammar in our URIs?

                          What does the URI or putting a "grammar" on it bring to the party?

                          It seems to me to be an orthogonal concern.

                          Seb
                        • Greg Young
                          Let`s try a non-CRUD example. ... -- It is the mark of an educated mind to be able to entertain a thought without accepting it.
                          Message 12 of 19 , Jun 4, 2009
                          • 0 Attachment
                            Let`s try a non-CRUD example.

                            On Thu, Jun 4, 2009 at 9:06 AM, Sebastien Lambla <seb@...> wrote:
                            > I was pretty sure I replied but can't find the message anywhere, so trying
                            > again:
                            >
                            >> Consider a different use case ... consider setting a default address
                            >> (out of a series of existing addresses) onto a customer. Now imagine
                            >> that there are 5 different ways this can happen. This rather quickly
                            >> seems to sprial out of control.
                            >
                            > You seem to be implying that those 5 different ways, and different flows,
                            > would result in the same resource being modified in the same way without
                            > context.
                            >
                            > Stop me if i'm wrong, but if you were to change an address in 5 different
                            > ways using commands, you would have 5 different commands?
                            >
                            > In ReST, the state that is shared between client and server isn't without
                            > workflows. You modify a resource (the concept of address) by sending one or
                            > many representations to one or many URIs.
                            >
                            > Nothing prevents you from operating various workflows through the use of
                            > various URIs, or if modelled on a state machine, to keep track of where in
                            > the workflow a client application is, and instruct on what to do next, based
                            > on the current state being sent back and forth by the client.
                            >
                            > I think i'm still missing the point as to why changing an address in 5
                            > different ways through 5 different flows would be impossible or messy in
                            > ReST? The only way I could understand such a statement would be in the case
                            > where you believe that they all end up triggering the same operation on the
                            > same resource, which is not a ReST constraint per se.
                            >
                            > Seb
                            >
                            >



                            --
                            It is the mark of an educated mind to be able to entertain a thought
                            without accepting it.
                          • Mike Kelly
                            A URI pattern/grammar for subsets which clearly indicate their relationship to the parent is necessary to make efficient use of things like cache-invalidation
                            Message 13 of 19 , Jun 4, 2009
                            • 0 Attachment
                              A URI pattern/grammar for subsets which clearly indicate their
                              relationship to the parent is necessary to make efficient use of things
                              like cache-invalidation mechanisms.

                              The 'grammar' of that pattern should make sense in natural human
                              language as well, so CEOs can observe those relationships the same way
                              intermediaries do.

                              The example used for 'data affecting other data' was a sales collection
                              and a subset of today's sales; if resources are identified appropriately
                              then there are no 'side effects', just one effect.

                              Cheers,
                              Mike

                              Sebastien Lambla wrote:
                              >> Maybe we just need to use better/more appropriate grammar in our URIs?
                              >>
                              >
                              > What does the URI or putting a "grammar" on it bring to the party?
                              >
                              > It seems to me to be an orthogonal concern.
                              >
                              > Seb
                              >
                              >
                              >
                              >
                              > ------------------------------------
                              >
                              > Yahoo! Groups Links
                              >
                              >
                              >
                              >
                            • Greg Young
                              A collection of today s sales... sure there is no real black box there as its so obvious. I was talking about summary information. Where the information on
                              Message 14 of 19 , Jun 4, 2009
                              • 0 Attachment
                                A 'collection' of today's sales... sure there is no real black box
                                there as its so obvious.

                                I was talking about summary information. Where the information on
                                today's sales might be roll ups based on say product types and
                                geographical locations (note that sales don't even HAVE geographical
                                location information on them when they are placed). What about when a
                                given sale will become available in the report (we have to assume the
                                possibility that the report is eventually consistent). REST will not
                                magically make this transparent as was originally claimed.

                                On Thu, Jun 4, 2009 at 9:42 AM, Mike Kelly <mike@...> wrote:
                                > A URI pattern/grammar for subsets which clearly indicate their relationship
                                > to the parent is necessary to make efficient use of things like
                                > cache-invalidation mechanisms.
                                >
                                > The 'grammar' of that pattern should make sense in natural human language as
                                > well, so CEOs can observe those relationships the same way intermediaries
                                > do.
                                >
                                > The example used for 'data affecting other data' was a sales collection and
                                > a subset of today's sales; if resources are identified appropriately then
                                > there are no 'side effects', just one effect.
                                >
                                > Cheers,
                                > Mike
                                >
                                > Sebastien Lambla wrote:
                                >>>
                                >>> Maybe we just need to use better/more appropriate grammar in our URIs?
                                >>>
                                >>
                                >> What does the URI or putting a "grammar" on it bring to the party?
                                >>
                                >> It seems to me to be an orthogonal concern.
                                >>
                                >> Seb
                                >>
                                >>
                                >>
                                >>
                                >> ------------------------------------
                                >>
                                >> Yahoo! Groups Links
                                >>
                                >>
                                >>
                                >>
                                >
                                >



                                --
                                It is the mark of an educated mind to be able to entertain a thought
                                without accepting it.
                              • Mike Kelly
                                Sorry, I was going on the original example you gave. Appreciate the subsequent example you ve just given is more complex but it doesn t sound like it would
                                Message 15 of 19 , Jun 4, 2009
                                • 0 Attachment
                                  Sorry, I was going on the original example you gave.

                                  Appreciate the subsequent example you've just given is more complex but
                                  it doesn't sound like it would contain any relationships that couldn't
                                  be modeled transparently using more granular resources and hyperlinks.



                                  Greg Young wrote:
                                  > A 'collection' of today's sales... sure there is no real black box
                                  > there as its so obvious.
                                  >
                                  > I was talking about summary information. Where the information on
                                  > today's sales might be roll ups based on say product types and
                                  > geographical locations (note that sales don't even HAVE geographical
                                  > location information on them when they are placed). What about when a
                                  > given sale will become available in the report (we have to assume the
                                  > possibility that the report is eventually consistent). REST will not
                                  > magically make this transparent as was originally claimed.
                                  >
                                  > On Thu, Jun 4, 2009 at 9:42 AM, Mike Kelly <mike@...> wrote:
                                  >
                                  >> A URI pattern/grammar for subsets which clearly indicate their relationship
                                  >> to the parent is necessary to make efficient use of things like
                                  >> cache-invalidation mechanisms.
                                  >>
                                  >> The 'grammar' of that pattern should make sense in natural human language as
                                  >> well, so CEOs can observe those relationships the same way intermediaries
                                  >> do.
                                  >>
                                  >> The example used for 'data affecting other data' was a sales collection and
                                  >> a subset of today's sales; if resources are identified appropriately then
                                  >> there are no 'side effects', just one effect.
                                  >>
                                  >> Cheers,
                                  >> Mike
                                  >>
                                  >> Sebastien Lambla wrote:
                                  >>
                                  >>>> Maybe we just need to use better/more appropriate grammar in our URIs?
                                  >>>>
                                  >>>>
                                  >>> What does the URI or putting a "grammar" on it bring to the party?
                                  >>>
                                  >>> It seems to me to be an orthogonal concern.
                                  >>>
                                  >>> Seb
                                  >>>
                                  >>>
                                  >>>
                                  >>>
                                  >>> ------------------------------------
                                  >>>
                                  >>> Yahoo! Groups Links
                                  >>>
                                  >>>
                                  >>>
                                  >>>
                                  >>>
                                  >>
                                  >
                                  >
                                  >
                                  >
                                • Sebastien Lambla
                                  ... Are you saying that proxies don t respect the opaqueness of URIs and rely on URL segments to do cache invalidation? I was aware of the historical query
                                  Message 16 of 19 , Jun 4, 2009
                                  • 0 Attachment
                                    > A URI pattern/grammar for subsets which clearly indicate their
                                    > relationship to the parent is necessary to make efficient use of things
                                    > like cache-invalidation mechanisms.

                                    Are you saying that proxies don't respect the opaqueness of URIs and rely on
                                    URL segments to do cache invalidation? I was aware of the historical query
                                    string non-caching, but not of this. This is a whole new can of worms being
                                    opened.

                                    Can you point to reference documentation showing the behaviour for
                                    intermediaries doing cache-invalidation? A quick summary on google didn't
                                    seem to trigger any result.

                                    Seb
                                  • Greg Young
                                    Please model for me the placing of an order to the system and the geographical report in a transparent fashion. The geocoding is an external service. Keep in
                                    Message 17 of 19 , Jun 4, 2009
                                    • 0 Attachment
                                      Please model for me the placing of an order to the system and the
                                      geographical report in a transparent fashion.

                                      The geocoding is an external service. Keep in mind that the report is
                                      eventually consistent and denormalized.

                                      Let`s also throw in some categorization of what is in the order EG:
                                      let`s imagine that we have some sort of feature detection running on
                                      our orders to apply what can be arbitrary categorizations.

                                      If I remember correctly this can be modeled so a 'CEO can easily understand it'

                                      Cheers,

                                      Greg

                                      On Thu, Jun 4, 2009 at 10:04 AM, Mike Kelly <mike@...> wrote:
                                      > Sorry, I was going on the original example you gave.
                                      >
                                      > Appreciate the subsequent example you've just given is more complex but it
                                      > doesn't sound like it would contain any relationships that couldn't be
                                      > modeled transparently using more granular resources and hyperlinks.
                                      >
                                      >
                                      >
                                      > Greg Young wrote:
                                      >>
                                      >> A 'collection' of today's sales... sure there is no real black box
                                      >> there as its so obvious.
                                      >>
                                      >> I was talking about summary information. Where the information on
                                      >> today's sales might be roll ups based on say product types and
                                      >> geographical locations (note that sales don't even HAVE geographical
                                      >> location information on them when they are placed). What about when a
                                      >> given sale will become available in the report (we have to assume the
                                      >> possibility that the report is eventually consistent). REST will not
                                      >> magically make this transparent as was originally claimed.
                                      >>
                                      >> On Thu, Jun 4, 2009 at 9:42 AM, Mike Kelly <mike@...> wrote:
                                      >>
                                      >>>
                                      >>> A URI pattern/grammar for subsets which clearly indicate their
                                      >>> relationship
                                      >>> to the parent is necessary to make efficient use of things like
                                      >>> cache-invalidation mechanisms.
                                      >>>
                                      >>> The 'grammar' of that pattern should make sense in natural human language
                                      >>> as
                                      >>> well, so CEOs can observe those relationships the same way intermediaries
                                      >>> do.
                                      >>>
                                      >>> The example used for 'data affecting other data' was a sales collection
                                      >>> and
                                      >>> a subset of today's sales; if resources are identified appropriately then
                                      >>> there are no 'side effects', just one effect.
                                      >>>
                                      >>> Cheers,
                                      >>> Mike
                                      >>>
                                      >>> Sebastien Lambla wrote:
                                      >>>
                                      >>>>>
                                      >>>>> Maybe we just need to use better/more appropriate grammar in our URIs?
                                      >>>>>
                                      >>>>>
                                      >>>>
                                      >>>> What does the URI or putting a "grammar" on it bring to the party?
                                      >>>>
                                      >>>> It seems to me to be an orthogonal concern.
                                      >>>>
                                      >>>> Seb
                                      >>>>
                                      >>>>
                                      >>>>
                                      >>>>
                                      >>>> ------------------------------------
                                      >>>>
                                      >>>> Yahoo! Groups Links
                                      >>>>
                                      >>>>
                                      >>>>
                                      >>>>
                                      >>>>
                                      >>>
                                      >>>
                                      >>
                                      >>
                                      >>
                                      >>
                                      >
                                      >



                                      --
                                      It is the mark of an educated mind to be able to entertain a thought
                                      without accepting it.
                                    • Mike Kelly
                                      ... I can t see any problem using this on the server side provided the app is implemented properly. I agree that client side would get nasty unless; - the
                                      Message 18 of 19 , Jun 4, 2009
                                      • 0 Attachment
                                        Sebastien Lambla wrote:
                                        >> A URI pattern/grammar for subsets which clearly indicate their
                                        >> relationship to the parent is necessary to make efficient use of things
                                        >> like cache-invalidation mechanisms.
                                        >>
                                        >
                                        > Are you saying that proxies don't respect the opaqueness of URIs and rely on
                                        > URL segments to do cache invalidation? I was aware of the historical query
                                        > string non-caching, but not of this. This is a whole new can of worms being
                                        > opened.
                                        >

                                        I can't see any problem using this on the server side provided the app
                                        is implemented properly.

                                        I agree that client side would get nasty unless;
                                        - the caching rules are disabled by default and the server is required
                                        to indicate compatibility to clients (in a header or something like that)
                                        - or the rules are implemented as code on demand

                                        I would prefer the latter approach.

                                        > Can you point to reference documentation showing the behaviour for
                                        > intermediaries doing cache-invalidation? A quick summary on google didn't
                                        > seem to trigger any result.

                                        I can't find any at the moment. An implementation for use in a RESTful
                                        web app would be relatively simple though, I think.
                                      • johnzabroski
                                        ... At this point, I am just sort of following the discussion. I am a little in awe. I can t even comprehend where it s going or where it s coming from. I
                                        Message 19 of 19 , Jun 4, 2009
                                        • 0 Attachment
                                          --- In rest-discuss@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
                                          >
                                          > > For me, the value of a declarative system is that my CEO can query and
                                          > > drill-down into any aspect of my system's design. There are no blackboxes;
                                          > > just mathematical reasoning.
                                          >
                                          > I am not sure I want to touch this one with a 30 foot pole but ...


                                          At this point, I am just sort of following the discussion.

                                          I am a little in awe. I can't even comprehend where it's going or where it's coming from.

                                          I guess nobody bothers to wonder that. Don't get me wrong, it's interesting and all, but I'm specifically trying to tell you, "Are you asking the right questions?" And it looks like the replies you are getting don't care whether you are asking the right questions. Instead, they want to discuss REST, which is only fair, considering your audience is here to discuss REST.

                                          So your audience is here for REST, but you are starting this thread in essence to ask a more general question (IMHO).


                                          > Do CEO's need access to *any* aspect of the system or those with
                                          > business value? More often than not what your CEO is interested in is
                                          > not your transactional objects but roll ups etc and analysis performed
                                          > upon them. I understand the argument for OLAP but using this as an
                                          > argument for REST seems to me to be like using the fact that they
                                          > where skates as an argument for why I should watch tennis.


                                          First off, I _wish_ tennis players had to wear skates, but Rafael Nadal would protest if his edge on clay was taken away. :)

                                          Second, the only argument I use for REST is continuous deployment. Hypermedia naturally models this. All the other stuff about REST is simply a checklist of "Are we programming with our pants down?" things Roy Fielding came up with to ensure we buckle our pants around our waist.

                                          About my CEO: he used to be a nuclear reactor engineer in the Navy. This might surprise you, but our non-technical people have influenced the architecture where I work just as much as the technical people. In fact, some of our best design decisions were pushed by non-programmers. The technical people still built the infrastructure, but the non-technical people pointed out some silly inefficiencies in the way we were doing certain things. The way we do multi-tenancy, for instance, was pushed by a former marketing guy.

                                          Sometimes people who don't do tech for a living can have a better understanding of a deep, technical subject area than the tech guy. Ever heard of Con Kolivas? He is the guy who has basically revolutionized the design of operating system schedulers, with his Staircase Deadline scheduler. Know what he does for a living? Anesthesiologist. He actually wrote better C code than a professional, highly trained C programmer, _without_ _knowing_ _C_. I am serious.

                                          My major point here is that your push back that "this is what a CEO should be doing" is fuzzy thinking. Being wrong is acceptable, so long as your thinking is concrete. You could be right, even, but not with the line of reasoning you provided.


                                          > Beyond that for a transactional system there is still a "black box" in
                                          > terms of how data affects other data. Consider an example of a
                                          > resource that tells me sales for the day and a resource that accepts
                                          > sales. There is a direct link between these two that may or may not be
                                          > exposed.


                                          Well, you can use a complex event processor to define a virtual event. However, I don't think that is the real money sink effecting most Fortune 500 companies today. I don't have nearly enough experience to say for sure, but I read a piece today off Michael Feathers' twitter (thanks to Colin Jack retweeting it) about American Airlines. http://dustincurtis.com/dear_dustin_curtis.html That letter pretty much exemplifies the sort of process problems that seem to swarm large institutions. Whenever my consultant friends describe their latest "work of art" they're brought in to "restore", it sounds a lot like AA-style problems. And you know what? I feel for that guy at AA. I would never suggest software as the solution, since its a technical solution for a non-technical problem. However, there is a reason why companies like iRise make ENORMOUS profits helping people improve their technical workflow between the sort of 200 person division with multiple sub departments like at AA.



                                          > BTW the solutions I use are fairly far from imperative. Currently I am
                                          > using what would be categorized as MEST (yes there can be argument if
                                          > MEST is just the new buzzword for messaging). I have lately been using
                                          > resources on my read side and messaging on my transactional side. I
                                          > have attempted at using REST more completely but am running into the
                                          > fact that it just doesn't seem to make any sense whatsoever in a
                                          > complex transactional situation.


                                          Ok, you are "far from imperative", but are you completely self-describing and referentially transparent? It sounds to me like you want this in your system, but are struggling with how?

                                          In the example you give above, you are talking solely in terms of physical implementation characteristics. Even an OLAP cube is an implementation detail! When we're talking at this level, be clear that _today_ what most companies do is have _human technical people_ do the work of _compilers_. Choosing to analyze things with a cube is an implementation detail that really ought to be solved by a compiler.

                                          You also sort of sidestepped my comment on using guards. A guard is in its essence an imperative construct, because it effectively defines WHEN something should occur... rather than simply THAT something should occur. Again, hard distinction between "do" and "be". Once you have something that simply "is", you have basically decoupled syntax from semantics as much as possible.
                                        Your message has been successfully submitted and would be delivered to recipients shortly.