Filtering meterReadings by readingType and REST

[Jacopo Scazzosi]

Hello everyone.

We're considering implementing support for Green Button Data [GBD] Connect My Data [CMD] and we've stumbled into a couple of conceptual issues that could greatly do with some input from more GBD-experienced devs.   

== The premise

Given GBD's support for multiple kinds of measurable entities and units of measure [UoM], we're planning on having multiple meterReadings available spanning over the same time interval, one for each supported UoM. One of our potential data consumers asked how he would be able, assuming we carry on with our efforts, to discriminate between these meterReadings. This turned out to be a trickier question than I thought it would.

I should also mention that I did spend some time trying to learn the inner workings of GBD and CMD before posting this, going through all bits of documentation I could find. I've also has a good look around in this group. Please forgive me if I have missed something that is immediately available. 

== The problem

Assuming a dumb client, I can't find a simple way to filter meterReadings according to a value specified in their respective readingTypes. Judging from the demo API, such a client would have to simply download all the available meterReadings, retrieve each meterReading's readingType and filter the former in or out according to the values found in the latter. Since we're dealing with a REST API, I half expected this to be the case.

Assuming a smart client, though, I still cannot find a simple way to discriminate which atom link to follow in order to retrieve a meterReading's readingType as the relationship "related" is used across multiple kinds of resources (intervalBlock + readingType). Defaulting to a-priori knowledge of the API's URL structure wouldn't make sense - that's what a dumb client relies on. The only way I can think of for a smart-client to discriminate between meterReadings is to first get all meterReadings related to a given usagePoint, retrieve all "related" resources for each meterReading and then filter those in or out according to the values in each meterReading's readingType.

In both cases, the client needs to perform a significant number of useless HTTP requests. A hybrid client relying both on a-priori knowledge of the API's URL structure while parsing the data it comes across would have a much easier time, although the need for such a client would take all the RESTfulness out of REST.

  

== The questions

1) If things really are as the appear to me, CMD looks quite inefficient, not to mention quite unRESTful. Is there anything I am missing? Is there a flaw in my approach to this API? Is there an easier way to accomplish what I described?

2) A-priori knowledge of an API's URL structure - beside the URL for the API's entrypoint - is usually considered to be an anti-pattern in REST, at least AFAIK. Does the CMD spec mandate the structure that is demonstrated in CMD's demo or are implementors allowed to use whatever URL structure they prefer?

Many thanks in advance to all of you.

Cheers.