| ... | ... | @@ -4,6 +4,7 @@ title: Behaviour Details |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# **Subscription behaviour** #
|
|
|
|
## Subscription creation ##
|
|
|
|
- A subscription POST to create datapoint subscription will not create duplicates
|
| ... | ... | @@ -26,7 +27,7 @@ Example: The subscription POST subscribes to a device aswell as a location with |
|
|
|
- The API considers a call back client (or endpoint / receiver) as a combination of URL and Secret
|
|
|
|
- Creating two identical Subscriptions will result in two Subscription Resources with theire own Id but no duplicate Datapoint callbacks
|
|
|
|
- Changing one of the Subscription Resources URL or Secret will not lead to changes of the other Subscription
|
|
|
|
- Instead the API considers the Subscription related two different call back clients/endpoints/receiver
|
|
|
|
- Instead the API considers the Subscription related to two different call back clients/endpoints/receiver
|
|
|
|
|
|
|
|
# **Date Time value expression** #
|
|
|
|
- The API will use the current time of the host system to complete Date Times to the mandated ISO format
|
| ... | ... | @@ -34,6 +35,6 @@ Example: The subscription POST subscribes to a device aswell as a location with |
|
|
|
|
|
|
|
|
|
|
|
# **Datapoint values** #
|
|
|
|
- Datapoint values are currently not persitantly stored
|
|
|
|
- Datapoint values are currently not persistently stored
|
|
|
|
- After a restart all datapoint values will not have a value
|
|
|
|
- Note: If the API was "offline" the values reliability is degraded, a persistant storage is therefore not implemented |
