HTTP API Design - langsames IoT Device

Seite 1 von 1 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/http-api-design-langsames-iot-device_261849/page_1 - zur Vollversion wechseln!

Vinci schrieb am 01.05.2023 um 11:41

Grüß euch

Mal angenommen ich hab ein ein lahmes IoT Device dass von irgendwelchen angeschlossenen Sensoren Daten lesen und schreiben kann. Wie sähe da eine sinnvolle HTTP API aus wenn das Ding so lahm is dass man auf den 1.Request nicht synchron antworten kann?

Mein aktueller Vorschlag wäre

PUT mit JSON Anhängsel lesen/schreiben/Daten usw. -> 202 Accepted sofern JSON sinnvoll is
GET pollen bis alles gelesen/geschrieben wurde, oder ev. Timeout, Fehler, etc. -> Antwort Code je nach Ergebnis

Ergibt das irgendwie Sinn? Gibts irgendeine "best practice" was man tut wenn angeforderte Daten nicht sofort zurückgemeldet werden können?

tia

COLOSSUS schrieb am 01.05.2023 um 11:46

Meiner erfahrung nach i. w. so, wie du das bereits beschrieben hast

Der Request Handler am Server, der die Daten entgegennimmt, retourniert "schnellstmoeglich" eine Response, die einen einen einzigartigen Token beinhaltet, den sich der Client/UA merkt. Spaeter kommt der Client/UA mit dem Token im Request an einem anderen Endpoint/Request Handler vorbei, wo er dann pollen kann, was der Server inzwischen zum Ergebnis seines urspr. Requests sagen kann.

Welche Verben du dafuer verwendest, bleibt dir ueberlassen (zumal du eh Client und Server kontrollierst), aber zumindest fuer die zweite Haelfte ist GET sicher nicht grundfalsch.

Viper780 schrieb am 01.05.2023 um 12:38

pollen ist sicher nicht falsch.
Je nach dem was es genau ist und wie Zeitkritisch die Daten sind bzw Reihenfolge relevant ist kannst du auch auf eine (fertige) Message Queue setzen

Vinci schrieb am 01.05.2023 um 17:06

Ok, Danke für die Tips, wollte nur wissen ob ich nicht eh irgendwas komplett unsinniges tu da ich in dem Bereich frisch bin.

Zeitkritische Daten hab ich in dem Projekt auch, allerdings für andere Dinge. Dort ist aber auch vieles bidirektional und ich hab gleich einen Websocket dafür genutzt.

JDK schrieb am 01.05.2023 um 17:14

Wennst eh schon Websockets am Start hast, kannst die doch gleich weiterverwenden, oder was ist der Use-Case?

Vinci schrieb am 01.05.2023 um 17:23

Zitat aus einem Post von JDK
Wennst eh schon Websockets am Start hast, kannst die doch gleich weiterverwenden, oder was ist der Use-Case?

Die Websockets verwend ich aktuell für Firmware-Updates die vom IoT Device selbst noch rausgehn. Also nicht das Update vom IoT Ding selbst, sondern von den Modulen die dran hängen.

Viper780 schrieb am 01.05.2023 um 18:53

Was ist denn dass für ein SoC?
Was verwendest für ein Framework?

Vinci schrieb am 01.05.2023 um 19:03

SoC ist ein ESP32-S3, das Framework is von Espressif selbst, ESP-IDF.

Viper780 schrieb am 01.05.2023 um 19:19

Da würd ich garnicht all zu viel selbst stricken und ein Framework verwenden
ESPHome, Tasmota, Esp easy, ESPurna ...

Drunter verwenden glaub ich alle PlatformIO - musst shcauen welcher den S3 jetzt schon kann

Vinci schrieb am 01.05.2023 um 19:26

Die Sensoren waren eigentlich nur ein Beispiel für irgendeine Peripherie die etwas Zeit braucht um Werte zu liefern, in Wahrheit is das alles noch viel schlimmer. Ich möchte Modelleisenbahnen ansprechen wo die Kommunikation mit einer Modulation der Stromversorgung funktioniert und teilweise nur Binärrückmeldungen auf Basis von Stromimpulsen existieren... Man kann sich vorstellen dass da selbst ein f* Byte lesen etwas dauert kann.

Viper780 schrieb am 01.05.2023 um 20:09

Kann ich mir gut vorstellen dass es alles andere als einfach umgesetzt ist.

Da ich kein guter Entwickler bin setz ich lieber auf konfigurieren und halt kleine Teile erweitern als alles selbst zu schreiben.

Da kannst dann den "Kern" von der Stange nehmen und musst dich "nur" um den Part für die Interpretation der Binär Meldung kümmern.

Firmware Update und MQ ist da schon gelöst

Vinci schrieb am 02.05.2023 um 07:59

Zitat aus einem Post von Viper780
Kann ich mir gut vorstellen dass es alles andere als einfach umgesetzt ist.

Da ich kein guter Entwickler bin setz ich lieber auf konfigurieren und halt kleine Teile erweitern als alles selbst zu schreiben.

Da kannst dann den "Kern" von der Stange nehmen und musst dich "nur" um den Part für die Interpretation der Binär Meldung kümmern.

Firmware Update und MQ ist da schon gelöst

Das System hat jetzt aber nicht zig Nodes die irgendwie "generisch" sein könnten. Ich hab meine Elektronik, also ein selbst designtes SoC und sonst nur noch arkanes Modellbauzeug. Dazwischen is sonst eigentlich nix mehr.

Auch wenn ich das natürlich begrüßen würde, aber ich wüsst grad nicht wo mir da was Arbeit abnehmen könnte.