Include args in response - [merged] #93

Closed fraunhofer-iis-bot closed 1 year ago

In GitLab by @jannismain on Feb 25, 2020, 15:37

Merges include-args-in-response -> dev

Closes #26

In GitLab by @cstender on Feb 25, 2020, 15:49

Why would one need the args from the request in the resonse?

In GitLab by @jannismain on Feb 25, 2020, 15:56

Das get_temperature Beispiel zeigt es ganz schön:

--> {"japi_request": "get_temperature", "args": {"unit": "kelvin"}}
<-- {"japi_response": "get_temperature", "data": {"temperature": 290.0, "unit": "kelvin"}}

Hier muss die Anwendung explizit das argument aus der anfrage mit der antwort zurücksenden. Im Beispiel wird das gemacht und der client kann den zurückgegebenen Wert interpretieren. Aber in anderen Anwendungsfällen (z.B. Interstellar) wurde das bisher nicht gemacht. Da sieht eine Anfrage dann so aus:

--> {"japi_request": "get_config", "args": {"device": "adc1"}}
<-- {"japi_response": "get_config", "data": {"config": "3e4a78b4c3a9e"}

Der Client versteht die Antwort nur, wenn er sich die anfrage gemerkt hat. Folgendes Verhalten würde ein umschreiben der gesamten ADC und DAC Server Spezifikation umgehen:

--> {"japi_request": "get_config", "args": {"device": "adc1"}}
<-- {"japi_response": "get_config", "args": {"device": "adc1"}, "data": {"config": "3e4a78b4c3a9e"}

Man kann es auch gerne optional machen, wenn der overhead ansonsten nicht gewünscht ist! :-)

In GitLab by @cstender on Feb 25, 2020, 16:01

Nachdem man es nur im Fall eines asynchronen Zugriffs benötigt, würde ich es auf keinen Fall standardmäßig machen.

Man könnte es bei der Registrierung der Request Handler mit einbauen, dass man noch ein "Options" Parameter hat (als Bitmask) in der eine Option "INCLUDE_ARGS_IN_RESP" ist.

In GitLab by @cstender on Feb 25, 2020, 16:04

marked as a Work In Progress

In GitLab by @cstender on Feb 25, 2020, 16:04

changed target branch from master to dev

In GitLab by @jannismain on Feb 26, 2020, 10:05

Man könnte es bei der Registrierung der Request Handler mit einbauen, dass man noch ein "Options" Parameter hat (als Bitmask) in der eine Option "INCLUDE_ARGS_IN_RESP" ist.

Würde das nicht bestehende anwendungen brechen, die den options parameter nicht mit angeben? Oder soll ich hier eine neue funktion mit dem zusätzlichen parameter einführen?

In GitLab by @jannismain on Feb 26, 2020, 10:07

Andere Möglichkeit die Kompatibilität zu wahren wäre eine Variadische Funktion, aber das wird schnell unübersichtlich...

In GitLab by @cstender on Feb 26, 2020, 12:36

Ja, das ist eher unüblich für sowas. Eher gebräuchlich, sind da wirklich flags. Wenn man keine Flags angibt, muss NULL verwendet werden.

Wenn man die API nicht brechen will, könnte man auch eine eigene Funktion zum Registrieren von Request Handlern mit Flags einbauen. Aber das wird dann (auch zum Dokumentieren) schnell viel und ebenfalls unübersichtlich.

In GitLab by @jannismain on Feb 26, 2020, 16:27

added 10 commits