[vz-dev] Neue Apidefinition?

Daniel Lauckner vz at jahp.de
Tue May 16 13:25:42 CEST 2017


Mahlzeit,


am Dienstag, 16. Mai 2017 um 08:37 hat Andreas Goetz geschrieben:
> Hier mein Vorschlag für eine neue Struktur:
> /data: einfach nur Daten, keine Verwendung Aggregation, maximaler
> Detailgrad. options=raw ist erlaubt.

Ok.

> /data/<hour|day|month>: Durchschnittswerte je Periode.

Ich verstehe das als Ersatz für &group=.

> options=raw ist bei dieser Abfrage wie künftig sonst auch verboten.

&tuples= fällt für den Fall dann auch flach?

> 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).

Nach meinem Verständnis ist die Preisfrage:
- Aktuelle Periode (Tag ab 00:00, Monat ab 01., Jahr ab 01.01.) oder
- vollständige Periode (24h, 30/31 Tage, 365 Tage)?
Aktuelle Periode scheint mir Zweckdienlicher zu sein.

Möchten wir Abfragen der Art /data/month&tuples=12 ermöglichen?
In dem Fall könnte ich mir als Antwort den aktuellen + die letzen 11
vollständigen Monate vorstellen.
Oder besser ein neuer Bezeichner für sowas?

> /consumption/<hour|day|month>: analog /data/<periode>, es werden
> aber Verbrauchswerte ausgegeben.

Cool.

> /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).

Verstehe ich es richtig das dabei das Problem besteht, wenn z.B.
die letzen 48h abgefragt werden, die day-Aggregation nur für einen Tag
nützt, die übrigen 24h müssen aus minute-Aggregation und data ermittelt
werden?

>  Falls from..to nicht angegeben sind wird das
> Ergebnis um initialconsumption erhöht (heute macht- sehr unsexy- das Frontend das).

Also consumption über den gesamten Datenbestand? Sprich: Aktueller
Gesamtzählerstand als Standardperiode?

Das klingt erstmal vernünftig, hat aber den Beigeschmack einer
Inkonsistenz zur Standardperiode (24h ago) von /data.

> 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.

Da fehlt mir wohl das Verständnis der Interna.

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

Klingt nach viel Arbeit. :)

Ohne Abwärtskompatibilität stellt sich mir halt die Frage wie wir das
mitm Wiki handhaben. Wir sollten zumindest Dokuänderung und Release
mit vertretbarem Zeitabstand veröffentlichen.
Alte Seiten mit Verweis auf neue MW-Version verschieben?


mfg Daniel



More information about the volkszaehler-dev mailing list