[vz-dev] Neue Apidefinition?

[Andreas Goetz]

Hallo Zusammen,

nach diversen Diskussionen mit Frank habe ich mal überlegt wie wir das API etwas übersichtlicher und v.a. entlang der Erwartungen der Anwender strukturieren könnten. Das erscheint mir insbesondere deshalb sinnvoll weil es mit dem next Branch die Möglichkeit gibt auch Verbrauchswerte abzufragen, z.B. je Periode. All dies ist heute in den /data Kontext gequetscht und recht verwirrend. 

Hier mein Vorschlag für eine neue Struktur:

/data: einfach nur Daten, keine Verwendung Aggregation, maximaler Detailgrad. options=raw ist erlaubt.

/data/<hour|day|month>: Durchschnittswerte je Periode. options=raw ist bei dieser Abfrage wie künftig sonst auch verboten. Zu überlegen wäre ob from..to- falls nicht angegeben- einen Standardwert je Periode bekommen sollte (also z.B. immer _aktueller_ Tag oder letzte 24h).
Diese Abfrage würde auch weiter vom FE genutzt um Aggregation für große Zeitperioden zu aktivieren.

/consumption/<hour|day|month>: analog /data/<periode>, es werden aber Verbrauchswerte ausgegeben. Geht natürlich nur bei entsprechenden Kanälen. from…to schränkt die Auswahl ein. Zu überlegen ist ob eine Periodengrenze zu erzwingen wäre (eher nicht).

/consumption: in dem Fall wird der Gesamtverbrauch der Periode ausgegeben. Die MW bestimmt selber welcher Aggregationsmodus verwendet wird (zu überlegen da Anfang/Ende der Daten nicht aggregiert sind). Falls from..to nicht angegeben sind wird das Ergebnis um initialconsumption erhöht (heute macht- sehr unsexy- das Frontend das).
Diese Variante könnte ggf. auch entfallen, dann müsste allerdings der Anwender überlegen in welcher Art/ Gruppierung er Gesamtwerte erheben will- eher unsexy.

Schön wäre auch die Timestampbildung für from..to gleich mit zu überarbeiten da im Moment durch die enge Koppelung zum FE zuviele Werte erzeugt werden die eigentlich nicht zur Abfrage passen und eher verwirren.

Vmtl. habe ich dabei einige Anwendungs- und Randfälle übersehen. Was haltet ihr davon?

Viele Grüße, Andreas