RESTful ranges

[ferrisoxide]

Hi folks

I'm currently mapping MODBUS to XPCA. The first cut was pretty naive -
just single coils and single registers - but I'm going to have to deal
with multiple registers at some point.

Single resources are easy to represent, e.g. GET /coils/2 gets the
value of the second coil. POST is the the same. But what's the best
way to represent multiple resources? Writing to multiple coils in
typical MODBUS parlance uses a base address and a series of values,
but how to make sense of this as RESTful resources?

I've been thinking of something like GET /coils/2/to/4 - or some kind
of convention like GET /coils/2_4 - but I suspect I'm thinking this
the wrong way.

Anyone with more experience with MODBUS care to comment?

Cheers
Tom

[Anton Maurovic]

In my usual fashion I am going to overcomplicate this without fully understanding the platform -- since I know nothing about MODBUS and am not too sharp on REST -- but that's how I roll ;)

I would imagine that since this is a GET, and therefore a query for information based on predicates, that query-strings make sense.

It seems the simplest case is enumerating coils (i.e. an "index page"):

GET /coils

Then if you want to get data for a specific coil:

GET /coils/2

But if you want to retrieve the full data for multiple "nodes" at once:

GET /coils/(insert selection criteria here)

...where the criteria could be to either fetch all nodes in a given range, or all which have a given property (i.e. all which are activated, in an error state, etc based on what MODBUS defines).

Perhaps the "criteria" are expressed as part of the path, while a querystring could be used to select a subset of properties? Hmm, XPath comes to mind, assuming that MODBUS can be viewed as a hierarchy of nodes and attributes.

Another thing I wonder about, again not fully understanding MODBUS or most industrial control... if you're selecting a range, is it important to know what all the parallel values were at the same instant in time (i.e. such that they're aligned and you have a "state")? Or, can each value be fetched sequentially, in which case having several devices that are slow to respond means that you get values that were sampled at different points in time? Maybe this is irrelevant.

- Anton

[flipback]

Queering by selection criteria  is a powerful feature and I think what it most be used fully. But I afraid that syntax such query will be difficult for
using manual definition request (for example in address string of browser).  May be good way is support two methods? For example, we have:

<coils>
  <coil>
    <addr> 0 </addr>
    <value> 1 </value>
    <timestamp> ... </timestamp>
  </coil>
  <coil>
   ....
  </coil>
   .....
</coils>

Powerful methods:

/coils?addr="0..10" or /coils&?firstadd=0&count=10 or /coils?addr=">=0&<=10"

and simple friendly for human:

/coils/1#20

1 -first address
# - special character
20 - count of coils

-Aleksey

[flipback]

Sorry - *Querying by selection*

[ferrisoxide]

Yep.. I think you and Anton are right. Funnily enough, it's the thing
I argue whenever I see someone add a "/search" verb to an interface.
In my playbook "search" is just "/index" with parameters.

OK, you've steered me the right way. Thanks folks.