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

Nick Gall <[email protected]>
Newsgroups gmane.comp.web.services.rest
Message-ID <CA+xhAPX5v5y-M8t5GC1AJQHnzQpXASMeOS-9god9grqAryYzAw@mail.gmail.com>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.