I agree with you Toby.
Although REST is an architectural "style", it moves oBIX in a direction where a
user has to have full understanding of the data (types) they are looking for?
This is exactly why API's are so difficult to use in the first place, because
of strongly typed parameters and functions.
One of the main principles of REST is that the resources (URL's) should be
nouns, instead of verbs? For example:
http://www.myfacility.com/points/analogpoints/AHU12RaTemp
instead of:
http://www.myfacility.com/points/GetPointData?ptid=AHU12RaTemp
Doesn't this obviously get away from the SERVICES-oriented nature of web
services? What about partial matches and wildcards? "AHU12*", etc. where you
only have partial information available (such as the name only and not the
point type?).
Currently, if I need to access any one of several "Big 5" controls vendor's
systems, I have to figure out which service to use from their API, if it's an
Analog Input point, I have to use
LPCSTR GetAnalogInputValue(pszPtName, LPCSTR *rgszPtParams, BOOL fFromCache);
if it's an AnalogOutput, it's:
LPCSTR GetAnalogOutputValue(pszPtName, LPCSTR *rgszPtParams, BOOL fFromCache);
and so on, and so on...
So, when I'm developing my interface, I have to explicitly know the "type" of
point it that I'm dealing with.
Easy enough?
Well, what if it's a user setpoint for an Air Handler? Is that a Pseudo Analog
Input (or Output), an Analog In, ??? I'm stuck with having to know "too much"
about the system I'm trying to get the data from.
This is the danger of coming up with a rigorous, (too) well defined
architectural style that will not be simple and extensible. Clearly, as you
pointed out, this is a major issue. Maybe I'm issing something, if so, it won't
be the first time; but it just seems like it's getting way to complicated.
Keith
Keith E. Gipson
Chief Technology Officer
Impact Facility Solutions, Inc.
www.myfacility.com and soon...
www.mybuilding.com
"facility management, on demand!"
--- "Considine, Toby (Facilities Technology Office)" <>
wrote:
