Internal storage, presented in pseudo-Rails ORM notation. DDL designates schema-upfront. JSON designates document storage.
- has_many Sensors
- metadata about maintainer (DDL)
- descriptions of attributes that sensors in the network can have (JSON)
- has_many SensorObservations
- location in lat-lon (DDL)
- attributes particular to this sensor (JSON)
- descriptions of attributes that observations from this sensor can have (JSON)
- timestamp (DDL)
- individual sensor values (JSON)
@levyj sorry I missed this comment for so long. Thank you for the detailed feedback!
That was a deliberate dodge on my part. So no, not yet, but stay tuned. I wanted to start by thinking through metadata, so that's why I went with the trivial example of requesting by ID, even though nobody will ever really query that way.
First off, you're not bikeshedding at all. This is precisely the sort of feedback I was hoping for. As for the trouble with repetition with sending all of the sensor and sensor network metadata all the time, I think a good default behavior would be to leave out the
included
section of the response (so line 50 down, basically) and just include therelationship
attribute that would let you query for metadata based on ID. I like the way you put the distinction between an API for the data and an API for the metadata. I was trying to go that way by splitting out thesensor-observations
,sensor-nodes
, andsensor-networks
resources. You can think of thesensor-observations
as the data and the other two as the metadata.I like that idea a lot. I hadn't considered how to signal to the client that the metadata has changed. As for whether it should be a flag or an automatic trigger to include the new metadata in the response, I also lean to the second. I imagine it's equally easy for a client program to neglect to check a flag as it is to not notice that updated metadata has been included in the response. But at least including it in the response automatically means that much less work for the developer.
Interesting. That would be useful. By default I would go with the simpler approach but I'd be open to hearing arguments on why it's useful enough to justify the complexity.
As usual, a thought-provoking exchange. Thanks, Jon!