HTTP API Design - langsames IoT Device

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.

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.

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.

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

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.

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.