The questions you raise concerning REST pertain
to the description of the “service” that conveys the information
and not necessarily to the information that is conveyed through that
service. For example in the current OpenADR spec there is am XML
definition for the the so called EventState. Furthermore there are
specifications for how that EventState is conveyed using REST, SOAP, and BACnet
web services. Each of those differ in how the service for conveying the
EventState is specified even though the information that is transported through
each service is the same.
Hi Ed,
Of course everybody has their own definition of REST, but specifically I am referring to the modeling aspects of REST. Models are built upon a naming system which allows cross-referencing of entities. In the case of OpenADR, these references are modeled in the traditional RDBMS sense as "Primary Keys" and "Foreign Keys". In a REST model, I would suggest that all those primary/foreign keys were replaced with a URI.
For example, perhaps it might be more powerful to name things like participants, utility programs, type events, etc with a URI? That allows the "web" of these definitions to grow with the scalability of the Internet using a existing, global naming system. Otherwise who "owns" these Primary Keys?
Although definitely the naming system tends to be where models and protocols collide. Of course the URIs might be opaque or maybe even something like a UUID. But when they are HTTP, now I have a generic way to dereference the definition without prior knowledge of how I turn a "primary key" into something useful. More importantly it allows me to leverage HTTP content negotiation to get the abstract resource using a encoding that makes sense me, HTML page for humans, XML definition for machines, and the ability to add new formats without breaking the system.
In the case of OpenADR, I think all those keys are just strings, so I suppose nothing is stopping me from implementing them as a web of URIs.
Just food for thought.
Brian