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

CherryPy and REST: REST vs RPC and CherryPy dispatch methods

Expand Messages
  • Dan Stromberg
    I just sent this to a CherryPy mailing list (web framework), but I thought I should ask the same question here too. Sorry if I m re-opening the scab on an old
    Message 1 of 9 , Aug 2, 2012

      I just sent this to a CherryPy mailing list (web framework), but I thought I should ask the same question here too.  Sorry if I'm re-opening the scab on an old flame war!

      I've been asked to set up a generic REST interface for a variety of data, probably using CherryPy.  We don't appear to have a lot of REST under our belts (I know I don't), and I've heard there's a lot of misunderstanding of true REST around the internet (getting it conflated with the weaker goals of RPC), so naturally, I'd like to see if we can get it (REST) right from the start.  Getting it right seems (so far) to boil down to keeping the verbs (and adjectives?) out of our URL's, and just letting GET/PUT/POST/DELETE be our verbs, sent to noun-nodes in our hierarchy.

      We're having a discussion about using CherryPy's MethodDispatcher (CRUD) and RoutesDispatcher (whatever you make of it) - and perhaps others, and which would be better to encourage true REST.  I caught wind of a meme suggesting MethodDispatcher is more RESTful (more "directly" REST) than other dispatchers.  Would it be a bad thing to use one and not the other, for the sake of REST?  And is REST purity worth bothering with?  Is it a goal that often can't be reached 100%, but is still worth striving toward?

      Here's a pair of CherryPy Links about how to use MethodDispatcher and RoutesDispatcher:

      Thanks!


    • Steve Klabnik
      Of course, this post is a classic: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
      Message 2 of 9 , Aug 2, 2012
      • Dan Stromberg
        ... Interesting. He seems to be saying that REST must be discoverable via HTML.
        Message 3 of 9 , Aug 3, 2012
          On Fri, Aug 3, 2012 at 4:05 AM, Steve Klabnik <steve@...> wrote:
          Of course, this post is a classic: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

          Interesting.

          He seems to be saying that REST must be discoverable via HTML.

        • mike amundsen
          not just the HTML media type, but media types that provide the appropriate levels of hypermedia controls (affordances). Here are a few IANA registered media
          Message 4 of 9 , Aug 3, 2012
            not just the HTML media type, but media types that provide the appropriate levels of hypermedia controls (affordances).

            Here are a few IANA registered media types that provide hypermedia affordances:
            - VoiceXML
            - Atom
            - HAL
            - Collection+JSON

            There may be other registered media types that I missed. I know there are some unregistered designs in development, too.


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




            On Fri, Aug 3, 2012 at 1:02 PM, Dan Stromberg <drsalists@...> wrote:



            On Fri, Aug 3, 2012 at 4:05 AM, Steve Klabnik <steve@...> wrote:
            Of course, this post is a classic: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

            Interesting.

            He seems to be saying that REST must be discoverable via HTML.




          • Nick Gall
            I ve never heard that one style of dispatching is more RESTful than another. What most differentiates REST from RPC is the what as known as the hypermedia
            Message 5 of 9 , Aug 3, 2012
              I've never heard that one style of dispatching is more "RESTful" than another. What most differentiates REST from RPC is the what as known as the hypermedia constraint. To be fully RESTful (according to the Richardson Maturity Model[1]), the response generated by the REST interface you are writing must use a media type that contains "hypermedia controls." With each interaction with a resource (via the interface you are writing), the client selects among the hypermedia controls returned in each response to choose the next interaction it can perform. HTML is only one of many hypermedia media types containing hypermedia controls.

              For a good discussion of hypermedia types (and a list of the popular ones) see [2]. For a good ranking of the degree of hypermedia-ness (ie measurement of the level of hypermedia support and sophistication of a media-type) of various hypermedia types see the hfactor.[3] For a good example of a JSON-based hypermedia type, see HAL.[4]


              -- Nick

              Nick Gall
              Phone: +1.781.608.5871
              Other Contact Info: http://bit.ly/nickgall


              On Thu, Aug 2, 2012 at 5:41 PM, Dan Stromberg <drsalists@...> wrote:



              I just sent this to a CherryPy mailing list (web framework), but I thought I should ask the same question here too.  Sorry if I'm re-opening the scab on an old flame war!

              I've been asked to set up a generic REST interface for a variety of data, probably using CherryPy.  We don't appear to have a lot of REST under our belts (I know I don't), and I've heard there's a lot of misunderstanding of true REST around the internet (getting it conflated with the weaker goals of RPC), so naturally, I'd like to see if we can get it (REST) right from the start.  Getting it right seems (so far) to boil down to keeping the verbs (and adjectives?) out of our URL's, and just letting GET/PUT/POST/DELETE be our verbs, sent to noun-nodes in our hierarchy.

              We're having a discussion about using CherryPy's MethodDispatcher (CRUD) and RoutesDispatcher (whatever you make of it) - and perhaps others, and which would be better to encourage true REST.  I caught wind of a meme suggesting MethodDispatcher is more RESTful (more "directly" REST) than other dispatchers.  Would it be a bad thing to use one and not the other, for the sake of REST?  And is REST purity worth bothering with?  Is it a goal that often can't be reached 100%, but is still worth striving toward?

              Here's a pair of CherryPy Links about how to use MethodDispatcher and RoutesDispatcher:

              Thanks!





            • Mike Kelly
              ... Hmm, as far as I can tell, REST s main source of differentiation from RPC is the combination of self descriptive messaging and layered constraint which
              Message 6 of 9 , Aug 3, 2012


                On 3 Aug 2012, at 19:35, Nick Gall <nick.gall@...> wrote:

                 

                I've never heard that one style of dispatching is more "RESTful" than another. What most differentiates REST from RPC is the what as known as the hypermedia constraint. 

                Hmm, as far as I can tell, REST's main source of differentiation from RPC is the combination of self descriptive messaging and layered constraint which produces a system in which applications are designed as network-visible interactions as opposed to the non-visible invocations you get from RPC. All of the uniform interface subconstraints separate REST from RPC but I think self descriptive messaging is the key one from that pov

                Cheers,
                M
              • Nick Gall
                ... Mike, you may have lost me. How does the requirement of self-descriptive messaging relate to style of dispatching? Or are you saying that self-descriptive
                Message 7 of 9 , Aug 3, 2012
                  On Fri, Aug 3, 2012 at 6:08 PM, Mike Kelly <mikekelly321@...> wrote:


                  On 3 Aug 2012, at 19:35, Nick Gall <nick.gall@...> wrote:

                   

                  I've never heard that one style of dispatching is more "RESTful" than another. What most differentiates REST from RPC is the what as known as the hypermedia constraint. 

                  Hmm, as far as I can tell, REST's main source of differentiation from RPC is the combination of self descriptive messaging and layered constraint which produces a system in which applications are designed as network-visible interactions as opposed to the non-visible invocations you get from RPC. All of the uniform interface subconstraints separate REST from RPC but I think self descriptive messaging is the key one from that pov

                  Mike, you may have lost me. How does the requirement of self-descriptive messaging relate to style of dispatching?

                  Or are you saying that self-descriptive messaging separates REST from RPC more than the hypermedia constraint?

                  If you are saying the latter, then I would claim that there are lots of self-descriptive RPC architectures out there, so self-descriptive messaging does NOT separate REST from RPC nearly as much as the hypermedia constraint does. I'd also argue that the hypermedia constraint is the one that is hardest for those with a traditional RPC mindset to grok, whereas almost anyone can grok self-descriptive messaging. So in terms of the mental shift required, the hypermedia constraint is also the biggest differentiator.

                  In fact, in his thesis Roy defines REST in terms of the hypermedia constraint: "This chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems." In other words, if you're not doing hypermedia, you're not doing REST.

                  -- Nick

                • Mike Kelly
                  ... I was saying the latter.. I m not saying hypermedia is unimportant, just that it is not the most fundamental aspect in terms of differentiating from RPC.
                  Message 8 of 9 , Aug 4, 2012
                    On Sat, Aug 4, 2012 at 12:56 AM, Nick Gall <nick.gall@...> wrote:
                     

                    On Fri, Aug 3, 2012 at 6:08 PM, Mike Kelly <mikekelly321@...> wrote:


                    On 3 Aug 2012, at 19:35, Nick Gall <nick.gall@...> wrote:

                     

                    I've never heard that one style of dispatching is more "RESTful" than another. What most differentiates REST from RPC is the what as known as the hypermedia constraint. 

                    Hmm, as far as I can tell, REST's main source of differentiation from RPC is the combination of self descriptive messaging and layered constraint which produces a system in which applications are designed as network-visible interactions as opposed to the non-visible invocations you get from RPC. All of the uniform interface subconstraints separate REST from RPC but I think self descriptive messaging is the key one from that pov

                    Mike, you may have lost me. How does the requirement of self-descriptive messaging relate to style of dispatching?

                    Or are you saying that self-descriptive messaging separates REST from RPC more than the hypermedia constraint?

                    If you are saying the latter, then I would claim that there are lots of self-descriptive RPC architectures out there, so self-descriptive messaging does NOT separate REST from RPC nearly as much as the hypermedia constraint does. I'd also argue that the hypermedia constraint is the one that is hardest for those with a traditional RPC mindset to grok, whereas almost anyone can grok self-descriptive messaging. So in terms of the mental shift required, the hypermedia constraint is also the biggest differentiator.

                    In fact, in his thesis Roy defines REST in terms of the hypermedia constraint: "This chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems." In other words, if you're not doing hypermedia, you're not doing REST.

                    -- Nick

                    I was saying the latter.. I'm not saying hypermedia is unimportant, just that it is not the most fundamental aspect in terms of differentiating from RPC. As far as I can tell this is reflected in the evaluation section of Roy's thesis:


                    "What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. The result is an application that allows for layers of transformation and indirection that are independent of the information origin, which is very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC mechanisms, in contrast, are defined in terms of language APIs, not network-based applications."

                    Also, even though it wasn't the point I was making, self-descriptive messaging can and does effect the style of dispatching. On the web, it's responsible for enabling the existence of web server component frameworks such as Ruby's "Rack"[1] or node.js's "Connect"[2].


                    Cheers,
                    M 
                  • Nick Gall
                    ... Hmmm...I m not sure I m getting your point. Though the section you quote mentions RPC mechanisms, it doesn t mention either self-descriptive messaging
                    Message 9 of 9 , Aug 4, 2012
                      On Sat, Aug 4, 2012 at 6:13 AM, Mike Kelly <mikekelly321@...> wrote:




                      On Sat, Aug 4, 2012 at 12:56 AM, Nick Gall <nick.gall@...> wrote:
                       

                      On Fri, Aug 3, 2012 at 6:08 PM, Mike Kelly <mikekelly321@...> wrote:


                      On 3 Aug 2012, at 19:35, Nick Gall <nick.gall@...> wrote:

                       

                      I've never heard that one style of dispatching is more "RESTful" than another. What most differentiates REST from RPC is the what as known as the hypermedia constraint. 

                      Hmm, as far as I can tell, REST's main source of differentiation from RPC is the combination of self descriptive messaging and layered constraint which produces a system in which applications are designed as network-visible interactions as opposed to the non-visible invocations you get from RPC. All of the uniform interface subconstraints separate REST from RPC but I think self descriptive messaging is the key one from that pov

                      Mike, you may have lost me. How does the requirement of self-descriptive messaging relate to style of dispatching?

                      Or are you saying that self-descriptive messaging separates REST from RPC more than the hypermedia constraint?

                      If you are saying the latter, then I would claim that there are lots of self-descriptive RPC architectures out there, so self-descriptive messaging does NOT separate REST from RPC nearly as much as the hypermedia constraint does. I'd also argue that the hypermedia constraint is the one that is hardest for those with a traditional RPC mindset to grok, whereas almost anyone can grok self-descriptive messaging. So in terms of the mental shift required, the hypermedia constraint is also the biggest differentiator.

                      In fact, in his thesis Roy defines REST in terms of the hypermedia constraint: "This chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems." In other words, if you're not doing hypermedia, you're not doing REST.

                      -- Nick

                      I was saying the latter.. I'm not saying hypermedia is unimportant, just that it is not the most fundamental aspect in terms of differentiating from RPC. As far as I can tell this is reflected in the evaluation section of Roy's thesis:


                      "What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. The result is an application that allows for layers of transformation and indirection that are independent of the information origin, which is very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC mechanisms, in contrast, are defined in terms of language APIs, not network-based applications."

                      Hmmm...I'm not sure I'm getting your point. Though the section you quote mentions RPC mechanisms, it doesn't mention either self-descriptive messaging (SDM) or hypermedia. So how could it possibly reflect anything about the relative importance of the two in terms of differentiating from RPC?

                      What is reflected in the quote is that "generic interfaces with standard semantics" is the most fundamental aspect in terms of differentiating from RPC. I would agree that of all the principles the Roy highlights in his description of REST, the principle of generality/uniformity is the most important one. Roy's thesis says so quite explicitly: "The central feature that distinguishes the REST architectural style from other network-based styles [including presumably RPC --nlg] is its emphasis on a uniform interface between components. By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved." And I've highlighted the fundamental importance of interface generality/uniformity in other venues.[1][2]

                      However, Roy says that four constraints are required for uniform interfaces (aka generic interfaces): "In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state." So again, I don't see how the section you quote reflects the relative importance of any of the four interface constraints, much less the relative importance of just the SDM and hypermedia constraints.


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