Open dpmcgarry opened 6 years ago
The car will always need to have some way to identify itself, so some form of state is required in the car. This does not have to be the @iot.id from the SensorThingsAPI. You could for instance store the licence plate number in the properties field of the Thing, and use that to find the correct Thing to update:
v1.0/Things?$filter=properties/plateNr eq 'xyz 123'
You are correct that there is not explicit time associated with a Thing, but there is nothing stopping an implementation from keeping track of that internally, and automatically deleting Things based on that. This time could even be exposed through the properties field of the Thing.
Gotcha thanks. So would it be a "good" approach for an implementation to have a specific set of items within the properties field as somewhat of a STAPI "profile" based on the needs for that implementation?
Most server implementations allow you to put anything you like in the properties field. It's completely up to the client. I think it would be good to have to best-practice sets for different domains, so clients know better what to expect.
We have an issue handling things that are transient. For example, tracking a vehicle. Since a vehicle may report for a while and then cease to report, there is no clear way in the spec for the vehicle to know what it's @iot.id will be. This introduces the requirement to store arbitrary state in the client to remember it's id across sessions. There is no "easy" way we could see in the API for a thing to grab what it's ID was and continue to update it after a period of offline.
In addition to this, there is the issue of things never going away unless they are explicitly deleted. Since there are no time fields explicitly associated with a thing, there is no clear way to determine when things should be deleted.