Eigentlich habe ich mehrere Fragen zu dem, was entwickelt wurde.
So wie es jetzt ist, hast du einfach die Funktionsweise kopiert, die auf der Route « aggregated_states » verwendet wurde. Diese Route hatte einen bestimmten Zweck: die Anzeige von Sensorwertdiagrammen für mehrere Sensoren zu ermöglichen.
Die Parameter und das Format dieser Route sind spezifisch für diesen Bedarf, und ich bin mir nicht sicher, ob es hier der gleiche Bedarf ist. Daher denke ich nicht, dass das gleiche API-Format beibehalten werden sollte.
Ich frage mich, ob der Bedarf hier nicht eher eine Route in diesem Stil ist (zu diskutieren):
GET /api/v1/device_feature/:device_feature_selector/state
Mit den GET-Parametern:
?from=DATE
&to=DATE
(Ich habe start_interval / end_interval geändert, weil wir bereits dieses from/to in einer anderen Route hatten, /api/v1/user/:user_selector/location)
Dies würde möglicherweise die Möglichkeit bieten, optionale Parameter hinzuzufügen: ?take= und &skip für diejenigen, die diese Route verwenden möchten, um große Datenmengen in Chunks zu exportieren, um diese Daten beispielsweise in ein Grafana zu injizieren, ohne die Leistung ihrer Instanz zu beeinträchtigen ^^
Die Antwort dieser Route wäre ein Array von States in ihrem DB-Format:
[
{
"id": "4ad21395-686b-41e5-988c-6e9201ba985a",
"value": 10,
"created_at": "2022-04-04 19:26:16.815 +00:00",
"updated_at": "2022-04-04 19:26:16.815 +00:00"
}
]
Ich denke, das ist lesbarer und besser an das angepasst, was wir hier tun wollen. Die Tatsache, dass nur ein einzelnes device_feature in dieser Route angefordert wird, ermöglicht es, die Paginierung zu verwalten, falls erforderlich, für jemanden, der Exporte durchführen möchte, ohne seine Gladys-Instanz zu überlasten (was wahrscheinlich dein Fall ist, nehme ich an!! :D)
Was denkst du darüber?
Ich komme später auf den Code zurück, aber im Moment ist für mich das Wichtigste, sich auf die Spezifikation zu einigen!
