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

Hard-coded state machine not REST?

Expand Messages
  • amaeze77
    All - Recent Jan A published a classification for HTTP-based APIs and I have a question (or questions) related to the distinction between HTTP-based Type II
    Message 1 of 7 , Mar 2, 2010
    • 0 Attachment
      All -

      Recent Jan A published a classification for HTTP-based APIs and I have a question (or questions) related to the distinction between HTTP-based Type II and REST.

      For all I can tell, the biggest difference between these two classifications is that HTTP-based Type II assumes the flow of the state machine and REST does not. I don't understand why the distinction matters. I've read here that it matters because the server could mix things up and then the client in the hard coded situation would be stuck. I'd suggest that even in the "REST" scenario, a server could throw a curve ball that will leave the client with no place to go but home. I think this classification has to more to do with degrees of coupling than it has to do with REST.

      Would an automated load tester (client) for a web application that uses hypermedia to traverse the application and execution not be considered RESTful because the state-machine for the application is hard-coded to some degree?

      I'd like some clarity on this topic.

      Thanks.

      Eb
    • Jan Algermissen
      ... Correct. REST s hypermedia constraint mandates that the client only relies on the current steady state (think Web page ) when deciding what to do next.
      Message 2 of 7 , Mar 2, 2010
      • 0 Attachment
        On Mar 2, 2010, at 12:44 PM, amaeze77 wrote:

        > All -
        >
        > Recent Jan A published a classification for HTTP-based APIs and I have a question (or questions) related to the distinction between HTTP-based Type II and REST.
        >
        > For all I can tell, the biggest difference between these two classifications is that HTTP-based Type II assumes the flow of the state machine and REST does not.

        Correct. REST's hypermedia constraint mandates that the client only relies on the current steady state (think "Web page") when deciding what to do next.

        > I don't understand why the distinction matters.

        Because it decouples the server implementation from the client's expectations. It is the reason why e.g. Amazon can evolve without considering the millions of clients using it. Amazon can even evolve *while* clients are in the middle of a purchase.

        > I've read here that it matters because the server could mix things up and then the client in the hard coded situation would be stuck.

        It matters because REST aims to free the server from having to consider its clients when it evolves.

        > I'd suggest that even in the "REST" scenario, a server could throw a curve ball that will leave the client with no place to go but home.

        Sure. For those cases, REST emphasizes that the client MUST expect such cases and deal with them instead of considering it to be a violation of some agreement. IOW, any 4xx response is still valid from the POV of the constract that governs the communication. It is not a sign of broken communication.

        > I think this classification has to more to do with degrees of coupling than it has to do with REST.

        Huh? REST is essentially about removing any coupling beyond the uniform interface - so that statement does not make sense :-)

        >
        > Would an automated load tester (client) for a web application that uses hypermedia to traverse the application and execution not be considered RESTful because the state-machine for the application is hard-coded to some degree?

        Why would it be hard-coded?

        (Of course you hard-code the knowledge of the media types used, but that is not hard coding the state machine)

        Jan

        >
        > I'd like some clarity on this topic.
        >
        > Thanks.
        >
        > Eb
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >

        -----------------------------------
        Jan Algermissen, Consultant
        NORD Software Consulting

        Mail: algermissen@...
        Blog: http://www.nordsc.com/blog/
        Work: http://www.nordsc.com/
        -----------------------------------
      • Eric J. Bowman
        ... Exactly. My example is an Atom Protocol client s delete function. Unless you re using a forms language that supports DELETE, to instruct the client how
        Message 3 of 7 , Mar 2, 2010
        • 0 Attachment
          Eb wrote:
          >
          > Would an automated load tester (client) for a web application that
          > uses hypermedia to traverse the application and execution not be
          > considered RESTful because the state-machine for the application is
          > hard-coded to some degree?
          >

          Exactly. My example is an Atom Protocol client's delete function.
          Unless you're using a forms language that supports DELETE, to instruct
          the client how that function works using hypertext, then the delete
          function must be hard-coded in the client chrome.

          This works well for deleting members, which is well specified -- but
          deleting collections is not. An Atom Protocol client which hard-codes
          a collection-delete function has its interoperability limited to those
          systems which interpret collection-delete behavior the same way, i.e.
          coupling.

          I don't actually care if a collection-delete button is in the client
          chrome, so long as its behavior is dictated by received hypertext.
          This decoupling allows the server's interpretation of the unspecified
          collection-delete function to change, without breaking clients, i.e.
          decoupling.

          The hypertext constraint is the line between this coupling/decoupling,
          and this holds true for a load-tester as well*. An Atom-Protocol-
          centric system with a load-testing REST client that incorporates
          collection delete, does not need re-coding in the event of the system
          changing. If it does need re-coding, then it cannot be a REST client,
          by definition.

          A tightly-coupled client of any sort, even an implementation-specific
          load tester, fails to achieve REST if the collection-delete is hard-
          coded within. Xforms for example, allows the server to simply define a
          new <model>, within hypertext, dynamically updating all clients when
          they next refresh -- without changing the UI (machine or human).

          So a load-testing REST client would just be driving an Xforms interface
          dynamically. Refreshing the Xform can reflect the reconfiguration of
          the system, without the load-tester needing to care. It's driving the
          same form, which now happens to have a different <model>.

          Hard-coding within the client defeats the purpose of the hypertext
          constraint, so the result is not a Uniform REST Interface.

          -Eric

          * I wouldn't necessarily consider a load tester to be a valid use-case
          for REST. I'd hard-code it, since that hard-coding amounts to unit
          tests. REST trades off the efficiencies that a protocol-exercising
          client likely requires.
        • Jan Algermissen
          ... Not quite. The trick is to only show the delete button when there is an edit link in the entry. You break the hypermedia constraint if the button is
          Message 4 of 7 , Mar 2, 2010
          • 0 Attachment
            On Mar 2, 2010, at 1:48 PM, Eric J. Bowman wrote:

            > Eb wrote:
            >>
            >> Would an automated load tester (client) for a web application that
            >> uses hypermedia to traverse the application and execution not be
            >> considered RESTful because the state-machine for the application is
            >> hard-coded to some degree?
            >>
            >
            > Exactly. My example is an Atom Protocol client's delete function.
            > Unless you're using a forms language that supports DELETE, to instruct
            > the client how that function works using hypertext, then the delete
            > function must be hard-coded in the client chrome.

            Not quite. The trick is to only show the delete button when there is an 'edit' link in the entry. You break the hypermedia constraint if the button is always there (or clickable) because you assume that the edit link will be there. It might not.

            >
            > This works well for deleting members, which is well specified -- but
            > deleting collections is not. An Atom Protocol client which hard-codes
            > a collection-delete function has its interoperability limited to those
            > systems which interpret collection-delete behavior the same way, i.e.
            > coupling.

            Deleting collections is not defined by AtomPub so you'd need to do that in a medi atype (extension) first. OTH, HTTP provides sufficient semantics to DELETE any resource. So if you want to build a client that exploits that it might well show a delete button all the time - in the same way a browser shows a GET 'button' all the time (the location bar).


            >
            > I don't actually care if a collection-delete button is in the client
            > chrome, so long as its behavior is dictated by received hypertext.
            > This decoupling allows the server's interpretation of the unspecified
            > collection-delete function to change, without breaking clients, i.e.
            > decoupling.
            >
            > The hypertext constraint is the line between this coupling/decoupling,
            > and this holds true for a load-tester as well*. An Atom-Protocol-
            > centric system with a load-testing REST client that incorporates
            > collection delete, does not need re-coding in the event of the system
            > changing. If it does need re-coding, then it cannot be a REST client,
            > by definition.

            Right.


            Jan

            >
            > A tightly-coupled client of any sort, even an implementation-specific
            > load tester, fails to achieve REST if the collection-delete is hard-
            > coded within. Xforms for example, allows the server to simply define a
            > new <model>, within hypertext, dynamically updating all clients when
            > they next refresh -- without changing the UI (machine or human).
            >
            > So a load-testing REST client would just be driving an Xforms interface
            > dynamically. Refreshing the Xform can reflect the reconfiguration of
            > the system, without the load-tester needing to care. It's driving the
            > same form, which now happens to have a different <model>.
            >
            > Hard-coding within the client defeats the purpose of the hypertext
            > constraint, so the result is not a Uniform REST Interface.
            >
            > -Eric
            >
            > * I wouldn't necessarily consider a load tester to be a valid use-case
            > for REST. I'd hard-code it, since that hard-coding amounts to unit
            > tests. REST trades off the efficiencies that a protocol-exercising
            > client likely requires.
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >

            -----------------------------------
            Jan Algermissen, Consultant
            NORD Software Consulting

            Mail: algermissen@...
            Blog: http://www.nordsc.com/blog/
            Work: http://www.nordsc.com/
            -----------------------------------
          • Eric J. Bowman
            ... Very well put. Now I m going to go off and disagree with you some... -Eric
            Message 5 of 7 , Mar 2, 2010
            • 0 Attachment
              Jan Algermissen wrote:
              >
              > Sure. For those cases, REST emphasizes that the client MUST expect
              > such cases and deal with them instead of considering it to be a
              > violation of some agreement. IOW, any 4xx response is still valid
              > from the POV of the constract that governs the communication. It is
              > not a sign of broken communication.
              >

              Very well put. Now I'm going to go off and disagree with you some...

              -Eric
            • Eb
              ... on the current steady state (think Web page ) when deciding what to do next. So in the case where a client presupposes the next steady state, the
              Message 6 of 7 , Mar 2, 2010
              • 0 Attachment
                > Correct. REST's hypermedia constraint mandates that the client only
                relies on the current steady state (think "Web page") when deciding what to do next.

                So in the case where a client presupposes the "next" steady state, the hypermedia constraint has been broken? I'll need to digest that.  :) What about if I can handle my assumption being incorrect?  Do I get REST points then?

                To your point about Amazon and to extend that example, if I wrote a client that knew how to order books following a "predefined" state machine (not wrapped behind some OO classes but trying to use hypermedia explicitly say via curl) and it broke because Amazon added a new page that my client couldn't handle, then my client is not RESTful because it assumed what a response should/would be.  Whereas if my client made zero assumptions (acted like it didn't know what would be returned even though it indicates its preference) and didn't ultimately didn't understand what was returned, it would still be RESTful because it made no assumptions and inspected every response.

                Am I summarizing right?

                Eb


                On Tue, Mar 2, 2010 at 7:07 AM, Jan Algermissen <algermissen1971@...> wrote:

                On Mar 2, 2010, at 12:44 PM, amaeze77 wrote:

                > All -
                >
                > Recent Jan A published a classification for HTTP-based APIs and I have a question (or questions) related to the distinction between HTTP-based Type II and REST.
                >
                > For all I can tell, the biggest difference between these two classifications is that HTTP-based Type II assumes the flow of the state machine and REST does not.

                Correct. REST's hypermedia constraint mandates that the client only relies on the current steady state (think "Web page") when deciding what to do next.

                > I don't understand why the distinction matters.

                Because it decouples the server implementation from the client's expectations. It is the reason why e.g. Amazon can evolve without considering the millions of clients using it. Amazon can even evolve *while* clients are in the middle of a purchase.

                >  I've read here that it matters because the server could mix things up and then the client in the hard coded situation would be stuck.

                It matters because REST aims to free the server from having to consider its clients when it evolves.

                > I'd suggest that even in the "REST" scenario, a server could throw a curve ball that will leave the client with no place to go but home.

                Sure. For those cases, REST emphasizes that the client MUST expect such cases and deal with them instead of considering it to be a violation of some agreement. IOW, any 4xx response is still valid from the POV of the constract that governs the communication. It is not a sign of broken communication.

                >  I think this classification has to more to do with degrees of coupling than it has to do with REST.

                Huh? REST is essentially about removing any coupling beyond the uniform interface - so that statement does not make sense :-)

                >
                > Would an automated load tester (client) for a web application that uses hypermedia to traverse the application and execution not be considered RESTful because the state-machine for the application is hard-coded to some degree?

                Why would it be hard-coded?

                (Of course you hard-code the knowledge of the media types used, but that is not hard coding the state machine)

                Jan

                >
                > I'd like some clarity on this topic.
                >
                > Thanks.
                >
                > Eb
                >
                >
                >
                > ------------------------------------
                >
                > 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:
                >    rest-discuss-digest@yahoogroups.com
                >    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/
                >

                -----------------------------------
                 Jan Algermissen, Consultant
                 NORD Software Consulting

                 Mail: algermissen@...
                 Blog: http://www.nordsc.com/blog/
                 Work: http://www.nordsc.com/
                -----------------------------------





              • Jan Algermissen
                ... Yes, right. ... Yeah - it is irritating. OTH, it is more about making explicit that you simply cannot make such assumptions in a networked system rather
                Message 7 of 7 , Mar 2, 2010
                • 0 Attachment
                  On Mar 2, 2010, at 4:02 PM, Eb wrote:

                  >
                  > > Correct. REST's hypermedia constraint mandates that the client only relies on the current steady state (think "Web page") when deciding what to do next.
                  >
                  > So in the case where a client presupposes the "next" steady state, the hypermedia constraint has been broken?

                  Yes, right.

                  > I'll need to digest that. :)


                  Yeah - it is irritating. OTH, it is more about making explicit that you simply cannot make such assumptions in a networked system rather than some mysterious magic.

                  Of course the client code eventually assumes it might find that link and provide code for that case but the approach is different and influences how you think about coding the client.

                  > What about if I can handle my assumption being incorrect? Do I get REST points then?

                  In a sense, yes. But the code should try to make explicit that from the current steady state the overall goal of the client cannot be persued any further. IWO, that there is no transition available that it would make sense to follow next. If you just do a try...catch I'd not give you credit :-)

                  >
                  > To your point about Amazon and to extend that example, if I wrote a client that knew how to order books following a "predefined" state machine (not wrapped behind some OO classes but trying to use hypermedia explicitly say via curl) and it broke because Amazon added a new page that my client couldn't handle, then my client is not RESTful because it assumed what a response should/would be.

                  Yes.


                  > Whereas if my client made zero assumptions (acted like it didn't know what would be returned even though it indicates its preference) and didn't ultimately didn't understand what was returned, it would still be RESTful because it made no assumptions and inspected every response.

                  Yes. Two issues with this:

                  1. Despite not understanding what was returned, REST emphasizes that there still is communication because you know that you are dealing with a "I do not understand" situation (aka 406 essentially). This is a lot more than 'blurb - fail'. In an enterprise context, you could use the 406 response headers and body to directly instruct developers how to bring the client up to date. This is different from doing an error analysis in an OO system.

                  2. The way you design your media types greatly influences how gracefully your client can react. In fact, I have come to think that the hypermedia constraint issue is probably the primary aspect of machine-targetted media type design (which we still have no public example of, unfortunately).

                  Jan


                  >
                  > Am I summarizing right?
                  >
                  > Eb
                  >
                  >
                  > On Tue, Mar 2, 2010 at 7:07 AM, Jan Algermissen <algermissen1971@...> wrote:
                  >
                  > On Mar 2, 2010, at 12:44 PM, amaeze77 wrote:
                  >
                  > > All -
                  > >
                  > > Recent Jan A published a classification for HTTP-based APIs and I have a question (or questions) related to the distinction between HTTP-based Type II and REST.
                  > >
                  > > For all I can tell, the biggest difference between these two classifications is that HTTP-based Type II assumes the flow of the state machine and REST does not.
                  >
                  > Correct. REST's hypermedia constraint mandates that the client only relies on the current steady state (think "Web page") when deciding what to do next.
                  >
                  > > I don't understand why the distinction matters.
                  >
                  > Because it decouples the server implementation from the client's expectations. It is the reason why e.g. Amazon can evolve without considering the millions of clients using it. Amazon can even evolve *while* clients are in the middle of a purchase.
                  >
                  > > I've read here that it matters because the server could mix things up and then the client in the hard coded situation would be stuck.
                  >
                  > It matters because REST aims to free the server from having to consider its clients when it evolves.
                  >
                  > > I'd suggest that even in the "REST" scenario, a server could throw a curve ball that will leave the client with no place to go but home.
                  >
                  > Sure. For those cases, REST emphasizes that the client MUST expect such cases and deal with them instead of considering it to be a violation of some agreement. IOW, any 4xx response is still valid from the POV of the constract that governs the communication. It is not a sign of broken communication.
                  >
                  > > I think this classification has to more to do with degrees of coupling than it has to do with REST.
                  >
                  > Huh? REST is essentially about removing any coupling beyond the uniform interface - so that statement does not make sense :-)
                  >
                  > >
                  > > Would an automated load tester (client) for a web application that uses hypermedia to traverse the application and execution not be considered RESTful because the state-machine for the application is hard-coded to some degree?
                  >
                  > Why would it be hard-coded?
                  >
                  > (Of course you hard-code the knowledge of the media types used, but that is not hard coding the state machine)
                  >
                  > Jan
                  >
                  > >
                  > > I'd like some clarity on this topic.
                  > >
                  > > Thanks.
                  > >
                  > > Eb
                  > >
                  > >
                  > >
                  > > ------------------------------------
                  > >
                  > > Yahoo! Groups Links
                  > >
                  > >
                  > >
                  >
                  > -----------------------------------
                  > Jan Algermissen, Consultant
                  > NORD Software Consulting
                  >
                  > Mail: algermissen@...
                  > Blog: http://www.nordsc.com/blog/
                  > Work: http://www.nordsc.com/
                  > -----------------------------------
                  >
                  >
                  >
                  >
                  >

                  -----------------------------------
                  Jan Algermissen, Consultant
                  NORD Software Consulting

                  Mail: algermissen@...
                  Blog: http://www.nordsc.com/blog/
                  Work: http://www.nordsc.com/
                  -----------------------------------
                Your message has been successfully submitted and would be delivered to recipients shortly.