development:api:start
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungNächste ÜberarbeitungBeide Seiten der Revision | ||
development:api [2010/07/23 01:07] – steffenvogel | development:api:start [2011/11/27 16:27] – [Middleware-API] berthold | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== API ====== | ====== API ====== | ||
- | Zur Zeit entwickeln wir zusammen mit den Machern von [[http:// | + | ===== Die Software auf volkszaehler.org besteht aus 2 Komponenten: ===== |
- | Das API besteht aus 2 Teilen: | + | ==== Frontend ==== |
+ | Das ist die Visualisierung der Werte, i.d.R. also ein Browser, in dem der Verlauf der Stromverbrauchswerte angezeigt wird. | ||
+ | Alternativ zum Browser sind aber auch andere Frontends angedacht: eine direkte Anzeige des aktuellen Verbrauchswertes z.B. via [[http:// | ||
- | * Kommunikation zwischen Controller und Backend (derzeit bei Flukso XMLRPC, soll auch bei Flukso auf JSON/REST umgestellt werden [[http:// | + | ==== Middleware ==== |
- | * Kommunikation | + | Hierbei handelt es sich im Wesentlichen um einen Wrapper um die Datenbank. Sämtliche |
- | **[[api: | ||
- | ===== Anforderungen | + | ===== Entsprechend besteht die API aus 2 Teilen: |
- | Das API sollte: | + | ==== Frontend-API ==== |
- | * die komplette Kommunikation mit dem Backend | + | Diese definiert die Kommunikation zwischen dem Frontend und der Middleware. |
- | * je nach Möglichkeit | + | |
- | * Verbindungsprobleme zum Backend-Server abfangen können | + | ==== Middleware-API ==== |
+ | Das ist jetzt leicht: die Middleware-API beschreibt die Kommunikation zwischen dem Messgerät (AVR Net-IO, Flukso, ...) und der Middleware. | ||
+ | |||
+ | **Zur** < | ||
+ | |||
+ | ===== Aufgaben der API ===== | ||
+ | |||
+ | * die komplette Kommunikation mit der Middleware | ||
+ | * die Möglichkeit | ||
* nicht nur Pulse übertragen können, sondern auch Messwerte anderer Sensoren (Temperatur, | * nicht nur Pulse übertragen können, sondern auch Messwerte anderer Sensoren (Temperatur, | ||
- | * eine eindeutige | + | * eine eindeutige |
* jeden Kanal eindeutig referenzieren (UCID - ''' | * jeden Kanal eindeutig referenzieren (UCID - ''' | ||
* Fehlfunktionen der Sensoren/ | * Fehlfunktionen der Sensoren/ | ||
Zeile 23: | Zeile 32: | ||
===== Umsetzung ===== | ===== Umsetzung ===== | ||
- | Als Protokoll hat sich HTTP bereits durchgesetzt: | + | Die gesamte Kommunikation mit der Middleware wird ausnahmslos über HTTP-Anfragen abgewickelt. |
+ | Beim Entwurf der API wurde auf folgende Punkte geachtet: | ||
+ | **HTTP-Protokoll** | ||
* wird nur selten in Netzwerken gefiltert | * wird nur selten in Netzwerken gefiltert | ||
* kann getunnelt oder durch Proxies benutzt werden | * kann getunnelt oder durch Proxies benutzt werden | ||
Zeile 30: | Zeile 41: | ||
* ist durch vorhande Bibliotheken gut nutzbar und weit verbreitet | * ist durch vorhande Bibliotheken gut nutzbar und weit verbreitet | ||
- | Für die Übertragung der Daten sehe ich folgende Möglichkeiten: | + | **[[http:// |
- | | + | * [[http:// |
- | | + | * [[http://de.wikipedia.org/wiki/Representational_State_Transfer# |
- | | + | * [[http:// |
- | | + | * [[http://de.wikipedia.org/ |
- | * über eine [http:// | + | |
- | * unterschiedliche " | + | |
- | * die Zustandslosigkeit ist gerade für schwache Controller von Vorteil. | + | |
- | Bei genauerem Hinsehen sollten wir diese REST Grundsätze (siehe Wikipedia Artikel) für das ganze Backend nutzen. Dies halte ich auch für die beste Variante: [[Benutzer: | + | **JSON-Format** |
+ | * von Menschen lesbar | ||
+ | * geringer Overload im Vergleich zu XML | ||
+ | * performante Verarbeitung der Daten mit Javascript | ||
- | ===== Zukunftsmusik ===== | ||
- | * Direktzugriff auf den Controller für Echtzeitdarstellung & Steuerung des Controllers (Ethersex besitzt bereits einen HTTPD) | ||
- | * Matthias von mysmartgrid hat das bereits für den Flukso Controller implementiert | ||
- | * Erkennung und Übertragung der Sensortypen, |
development/api/start.txt · Zuletzt geändert: 2018/12/10 15:15 von zugschlus