EasyWI hat soweit ich weiß eine Rest-API.
So macht man das übrigens bei vielen Diensten, die über das Internet erreichbar sind.
Ich frage z.B. mit GET-Requests den Status von einem Akku ab und mit POST-Requests erteile ich dem Akku Befehle (Ein-/Ausschalten, Fehler rücksetzen).
- GET: Informationen abfragen
- POST: Neuen Eintrag hinzufügen und Daten ändern
- DELETE: Daten löschen
- INSERT: neuen Datensatz einfügen
- UPDATE: Datensatz/Information aktualisieren
Ich nutze z.B. nur GET und POST, den Rest nicht.
So kann z.B. eine Rest-API aussehen:
partner.steamgames.com
Wenn du Python verwenden möchtest, kann ich dir für so etwas
FastAPI empfehlen.
Hat auch den Vorteil, dass wenn man seinen Code vernünftig dokumentiert, am Ende auch eine automatisch generierte API-Dokumentation zur Verfügung gestellt wird.
Wenn die API z.B. andere Dienste/Anwendungen steuern soll, hängt es von der Anwendung ab.
Die Rest-API könnte z.B. Konsolen-Anwendungen starten und die Argumente festlegen.
Wenn irgendwas zur Laufzeit der Anwendung verändert werden soll, muss man gucken,
ob diese Anwendung irgendwelche Schnitstellen zur Verfügung stellt.
Konsolen-Anwendungen könnte man z.B. via stdin neue Befehle erteilen und stdout lesen, um das Ergebnis zu bekommen.
Verarbeiten muss man die Ausgabe auch. Wie man das macht, hängt von der Ausgabe ab.
Meist nimmt man regex oder einen Parser (HTML, XML, JSON, YAML).
Komplett falsch wäre es z.B. die Ausgabe von Programmen zu verarbeiten, die Sprachabhängig sind.
So kann z.B. das Tool fdisk den Text auch auf Deutsch ausgeben. Wenn man zuvor etwas geschrieben hat,
dass den englischen Text verarbeitet und dann in einer anderen Umgebung die Ausgabe verarbeitet, erlebt man Überraschungen.
Wenn man die Anwendung, die man steuern will, selbst entwickelt hat, ist es natürlich viel einfacher.
Vor dem Start:
- Argumente
- Umgebungsvariablen
Zur Laufzeit:
- signale
- message-queues (zmq, mqtt, ...)
- sockets: Unix, TCP, UDP
- mmap (Memory Mapped IO)
In meinem Fall mit dem Akku, habe ich die Dienste aufgeteilt.
- Datenlogger
- Liest Daten vom seriellen Port
- speichert die verarbeiteten Daten in einer sqlite-Datenbank
- schreibt die aktuellen Werte in eine Datei (mmap)
- empfängt Befehle via zmq (message queue)
- Rest-API
- liest die aktuellen Werte aus einer Datei (mmap)
- sendet Befehle via zmq (message queue)
- Liest Daten aus der Datenbank um Graphen und CSV-Dateien zu erstellen
- Speichert Konfiguration für: wifi und email
- WiFi-Service
- Startet WLAN im Client- oder AP-Modus
- Wechselt zwischen Client- und Ap-Modus, wenn man einen Taster betätigt
Es gibt viele Beispiele im Internet, an denen man sich orientieren kann.
