[vz-dev] Neue Apidefinition?

[Andreas Goetz]

Servus,

ich greife die Diskussion mal wieder auf.

> On 16. May 2017, at 13:25, Daniel Lauckner <vz at jahp.de> wrote:
> 
> 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=.

So ists gemeint. Parallel ist zu undurchsichtig.

> 
>> options=raw ist bei dieser Abfrage wie künftig sonst auch verboten.
> 
> &tuples= fällt für den Fall dann auch flach?

Am besten ja. Falls nein Zusatzaufwand und neue Komplexität da die Rechenregeln zur Verdichtung von Verbräuchen andere wären als bei Rohwerten. Im Prinzip müsste man hier wieder “Durchschnitt” anwenden statt der Interpreter-spezifischen Regel.

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

Dito. Für alles Andere lässt sich ja weiter from-to angeben, sogar in PHP-Notation “1+day+ago”.

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

Mindestens neuer Bezeichnet. Ist aber eigentlich ein völlig eigenständiges neues Feature.

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

Siehe next branch. Da ist die Funktion mittels “group” drin.

> 
>> /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?

Genau. Macht die MW heute auch schon so, nur dass ihr das Frontend vorgibt welche Aggregationsstufe für die “Beschleunigung” der Abfrage ausgewählt werden soll.

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

Da ist was dran. Meine Denke war a) Zählerstand jetzt und b) Verbrauch einer Periode. Bessere Ideen die beiden Dinge auseinander zu halten?

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

Da muss ich Frank nochmal fragen- kann sein dass das ebenfalls schon gelöst ist.

> 
>> Vmtl. habe ich dabei einige Anwendungs- und Randfälle übersehen. Was haltet ihr davon?
> 
> Klingt nach viel Arbeit. :)

Das meiste ist schon fertig, eigentlich fehlt nur das API.

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

Wenn wirs machen wollen dann die aktuelle Version als 0.4 taggen und dann eine neue als 1.0 oder ähnlich rausbringen. Keine Parallelwelten. Wer ständig git pull macht ist ohnehin selbst schuld :)

> 
> 
> Mit freundlichen Grüßen
> Daniel
> 
Viele Grüße, 
Andreas