OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

smartgrid-interest message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [smartgrid-interest] Energy Market Information Exchange Charter - supporters wanted; ready for submission to create Technical Committee

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]