Re: CherryPy and REST: REST vs RPC and CherryPy dispatch methods

On Sat, Aug 4, 2012 at 6:13 AM, Mike Kelly <[email protected]> wrote:

>
>
>
>
> On Sat, Aug 4, 2012 at 12:56 AM, Nick Gall <[email protected]> wrote:
>
>> **
>>
>>
>> On Fri, Aug 3, 2012 at 6:08 PM, Mike Kelly <[email protected]>wrote:
>>
>>>
>>>
>>> On 3 Aug 2012, at 19:35, Nick Gall <[email protected]> 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:
>
> http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_2
>
> "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.

[1] http://bit.ly/QXM1X4
[2] http://j.mp/uXzVcB

-- Nick