MODBUS is not RESTful
- I am moving this permathread from the SOA Yahoo Group to the REST-discuss group.
In essence, Gregg is arguing that the MODBUS protocol (see this MODBUS tutorial ) is RESTful. See the permathread for more context.
--- In email@example.com , Gregg Wonderly <gergg@...> wrote:
> Here is where the discussion might be better focused.OK! Here goes...
> 1. Identification of resources.
> 2. Manipulation of resources through representations.
> 3. Self-descriptive messages.
> 4. Hypermedia as the engine of application state.
> My thoughts go this way:
> 1. Resources in MODBUS are the RTUs
> 2. As I've said, the content of a modbus packet after the RTU is
> just like a typical HTTP POST representation. It's arbitrary
> in format for any application, and the MODBUS spec defines some
> standard representations that are useful, but there are many other
> device (nay application specific) representatons as well.
> 3. Self descriptive messages is an interesting issue. I believe that
> if POST is descriptive, then TRANSFER or EXECUTE or some other
> message is just as descriptive even if it is implicit in a system
> with only one message.
> 4. Hypermedia is a red herring from my perspective. In implies nothing
> and allows anything, because the content of a response is not
> detailed. I.e. what's in an HTML page or XML document is open
> to any detail needed by the application. Some responses don't
> contain any type of navigation information, while others do.
> It is application specific whether such things make sense or
> are needed.
> Maybe we can have a better discussion around these specific things?
Hypermedia is not a red herring, it really is what makes REST different from just any old LCODC$SS (Layered, Code-On-Demand, Client-Cache-Stateless-Server) architecture (see Figure 5.9 in the thesis).
Before we get into hypermedia however, since I barely know anything about MODBUS, could you explain how it meets REST's cache constraints (see 5.1.4): "Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or noncacheable." (emphasis added) From what I skimmed in the MODBUS protocol documentation and tutorial, I saw no such requirement, ie that the data within a response be labeled wrt cacheability.
Since cacheability is such a fundamental part of REST, the lack of cacheability labeling in MODBUS means MODBUS is not RESTful for that reason alone. Of course, one could add such cache labelingby convention in a particular application of MODBUS. But to do so would really just be layering an additional constraint to close the gap between MODBUS and REST.
Now as to whether hypermedia is a red herring because "the content of a response is not detailed", let me refer you to section 5.3.3 (Data View):REST concentrates all of the control state into the representations received in response to interactions. The goal is to improve server scalability by eliminating any need for the server to maintain an awareness of the client state beyond the current request. An application's state is therefore defined by its pending requests, the topology of connected components (some of which may be filtering buffered data), the active requests on those connectors, the data flow of representations in response to those requests, and the processing of those representations as they are received by the user agent. [emphasis added]
While there is a lot more "detail" about the content of a RESTful response representation in the thesis, I think this one "detail", this most important detail, is sufficient to refute both your contention that hypermedia is a red herring and your contention that MODBUS is RESTful. To parphrase the quoted paragraph, a fundamental REST constraint (because it enables server statelessness) is that representations of resources contain not only the data representing the resource, but the also the control state of such resources.
I know of no other mainstream architecture that REQUIRES this (except perhaps functional languages using continuations). And I'm willing to bet that MODBUS does not impose such a constraint, ie that control state be returned in representations and not be retained on the server.
Because the fourth constraint ("hypermedia as the engine of application state") does have teeth and because MODBUS fails to enforce such a constraint, MODBUS is not RESTful. More generally not all LCODC$SS architectures with a small set of general operations are RESTful, eg SCSI, TCP/IP, Unix Pipes, UDB. Only LCODC$SS architectures that require control state be passed in representations and not cached on the server (as well as the other 3 constraints you list) are RESTful. Why do you think they call it representational STATE transfer? It's all about transferring representations with control state in them.
- Nick Gall wrote:
> I am moving this permathreadMy specific argument was about it being uniform. The fact that the definition
> from the SOA Yahoo Group
> <http://tech.groups.yahoo.com/group/service-orientated-architecture/> to
> the REST-discuss group.
> In essence, Gregg is arguing that the MODBUS
> <http://en.wikipedia.org/wiki/Modbus> protocol (see this MODBUS tutorial
> <http://www.lammertbies.nl/comm/info/modbus.html>) is RESTful. See the
> permathread for more context.
of REST if defined by other less concrete terms such as Generality and
Hypermedia is a separate issue.
- --- In firstname.lastname@example.org, Gregg Wonderly <gergg@...> wrote:
> Nick Gall wrote:
> > I am moving this permathread
> > from the SOA Yahoo Group<http://tech.groups.yahoo.com/group/service-orientated-architecture/> to
> > the REST-discuss group.tutorial
> > In essence, Gregg is arguing that the MODBUS
> > <http://en.wikipedia.org/wiki/Modbus> protocol (see this MODBUS
> > <http://www.lammertbies.nl/comm/info/modbus.html>) is RESTful. Seethe
> > permathread for more context.definition
> My specific argument was about it being uniform. The fact that the
> of REST if defined by other less concrete terms such as Generality andBut the meaning of "uniform" in the context of REST is much more
> Hypermedia is a separate issue.
> Gregg Wonderly
specific than the dictionary definition of "uniform". In the context
of REST and especially in the context of Roy's thesis, "uniform
interface" is defined precisely by the four constraints that you
yourself suggested the "discussion might be better focused"! Since
hypermedia is the most important of those four essential constraints
that define the very meaning of "uniformity" in the context of REST,
hypermedia is hardly "a separate issue".
Hypermedia goes to the very heart of the meaning of "uniform
interface" in the thesis. In the REST usage, an interface CANNOT be
"uniform" unless it uses hypermedia as a resource representation.