[Gelöst] [V 3.4] Wie geht HTTP POST am Beispiel von Pushover? (WD-2171)

[Parsley]

Hallo zusammen,

ich habe jetzt dieses Forum nach allen Stichworten durchsucht, die mir einfielen und bin noch nicht bis zu meinem Ziel gekommen.

Anhand dieser Pushover API Beschreibung habe ich...

Code: Alles auswählen

% curl --form-string "token=MEIN_APP_TOKEN" --form-string "user=MEINEN_USER_KEY" --form-string "message=foo bar baz" https://api.pushover.net/1/messages.json 

... in meinem Terminal erfolgreich aufrufen können und habe die Nachricht empfangen.
Dann habe ich mir die Wikiseite zum HTTP-API angesehen. Diese hat mMn eher den Charakter einer Feature-Auflistung. Mir fehlt eine wirkliche Anleitung mit Screenshots und Erklärung anhand von Beispielen.
Das Video zur HTTP-/REST-API hat einieges an zusätzlicher Klarheit gebracht. Ich habe mir wie im Video gezeigt ein Subsystem angelegt und in diesem Subsystem einen HTTP-API Server erstellt.
An dieser Stelle hänge ich jetzt aber, weil ich mir bereits bei dem Einstellungen für diesen Server nicht mehr sicher bin.

Wenn ich das richtig verstehe wird Pushover per POST aufgerufen und benötigt dabei keine Autorisierung aber dafür drei "Feld=Wert" Angaben. Scheinbar ist der "user=" als Äquivalent zu einer Autorisierung zu sehen. Von den "token=" kann sich jeder Pushover Nutzer scheinbar mehrere generieren, um mutmaßlich verschiedene Quellen/Geräte (TWS, IFTTT, Waschmaschine, Hund, Katze, Maus,...) jeweils mittels eines eigenen token auseinander halten zu können?
Der dritte ist der eigentlich interessanteste und enthält die Nachricht.

Bezogen auf den TWS verstehe ich es so, dass man in einem HTTP-Subsystem einen "HTTP-API Server" haben will, der user= und token= bereits fest hinterlegt hat und über ein TWS-Objekt einen string als message= übergeben bekommt. Ein neuer string aus dem Objekt würde dann als trigger den HTTP POST absenden. Verstehe ich das soweit richtig?

So ein bisschen habe ich noch Probleme damit diesen gestaffelten/hirachischen Aufbau zu verstehen und was dort wo hin gehört:

1. Subsystem
2. HTTP-API Server
3. Resource
4. Objekt

Zu 1 habe ich verstanden, dass es sinnvoll ist für unterschiedlich "schnelle" Netze eigene Subsysteme zu machen. Enthält ein Subsystem mehrere HTTP-API Server, dann verden diese sequenziell (und nicht parallel) bedient, sodass ein langsamer Server die Kommunikation zu den anderen lahmlegt. richtig?

Zu 2 ist noch so viel klar, dass hier zunächst mal die grundsätzlich anzusprechende Domain und eventuell notwendige login Daten/autorisierungs DAten angegeben werden.

Aber ab jetzt komme ich nicht wirklich weiter...

• Wo gehört der Teil "/1/messages.json" nach der TLD hin?
• Wo/wie kann ich die token=xy und user=xy?
• Wie bekomme ich ein string Objekt in message=string hinein und verwende es gleichzeitig als Trigger?

Screenshot 2022-03-20 at 15.14.34.png

Im Server könnte ich vermutlich im Feld "Optionale Headers" die zwei Zeilen
user:<USER_KEY>
token:<APP_TOKEN>
eintragen, der Rest könnte passen, oder?

Screenshot 2022-03-20 at 17.25.58.png

Im Resource Teil bin ich mir mit dem Request Content-Type unsicher. Da ich keine Response erwarte ist mir der Response Content-Type vermutlich egal.

Screenshot 2022-03-20 at 18.08.35.png

Im Objekt hat mich ziemlich verwirrt, was zunächst in dem Feld stand, wo ich jetzt message eingetragen habe: "JSON Selektor eingeben" habe ich in diesem Zusammenhang nicht verstanden.





Dieser Eintrag ist jetzt im laufe des Tages entstanden. Die Screenshots oben geben (abgesehen von user und token im Server) meinen aktuellen Stand wieder.

Screenshot 2022-03-20 at 18.20.06.png

An dieser Stelle hätte ich jetzt eigentlich auch gerne so eine Art Doktor Modus, sodass ich dem Objekt RT1 einen string geben und einen Trigger auslösen könnte.

Ich muss mir später mal überlegen wie ich testen kann ob das funktioniert was ich hier gemacht habe...


EDIT: Ich habe diesen Thread jetzt als "Problem" gekennzeichnet. Siehe Post 4

[Sun1453]

Hallo Parsley, @Parsley

also in Sachen Subsystem solltest du immer zwischen Ressourcen innen und außen trennen. Weil externe Ressourcen sind ja nicht so stabil wie interne.

Das zum 1. Punkt Subsysteme.

API Server könntest du noch mit Auth ja und Header als Lokation verwenden. Das du aber weitere Sachen hast müssen die in optionale Header. Ressource URI (Ressource) und Hostadresse (Server) sind korrekt befüllt. Auch sehen die anderen Angaben gut aus nach meiner Bisherigen Erfahrung mit der HTTP API.

Nimm zum Testen am besten die Logik Engine vom TWS. Multiplexer String eignet sich am besten. Belege da die Eingänge mit den gewünschen Wert und nimm dann den Doktor Modus der Logik Engine und setzte den Selektor auf den gewünschten Eingangswert. PS: Selektor 0 = Eingang 1. Ausgang der Logik ist dann der Eingang bei der HTTP API.

Hier wird alles gut beschrieben wie ich finde für Server und Ressource:

Code: Alles auswählen

import http.client, urllib
conn = http.client.HTTPSConnection("api.pushover.net:443")
conn.request("POST", "/1/messages.json",
  urllib.parse.urlencode({
    "token": "APP_TOKEN",
    "user": "USER_KEY",
    "message": "hello world",
  }), { "Content-type": "application/x-www-form-urlencoded" })
conn.getresponse()

[Parsley]

Danke @Sun1453.

Ich habe es jetzt mit einer Logik wie von dir vorgeschlagen getestet. Der Text erscheint wie erwartet im Objekt, aber leider gibt es statt einer Benachrichtigung einen Fehler.

Hier einmal die ganze Kette (außer dem Subsystem):

Screenshot 2022-03-20 at 20.15.23.png

Screenshot 2022-03-20 at 20.18.44.png

Screenshot 2022-03-20 at 20.21.17.png

Screenshot 2022-03-20 at 20.24.13.png

Frage: was mache ich falsch?

Hinweis an Elabnet: "Eine Übertragung..." der Text unter Sendefilter ist zu lang und ein Mouse Over bringt einen Tooltip, der aber nicht den vollständigen Fehelrtext enthält.

[Parsley]

Scheinbar liegt es an den Werten für user und token, die im HTTP_API SErver nicht korrekt in den Header eingebaut werden...

Screenshot 2022-03-20 at 21.49.51.png

Ich vermute entweder, dass die im Hinweistext beschriebene Syntax (feld:wert) falsch ist, oder dass es zwar so funktionieren sollte, es aber leider nicht tut. Vergleiche Screenshot oben und unten. Unten ist zu sehen, wie user:wert und token:wert entsprechend dem Hinweis formatiert sind. Oben ist zu sehen, dass im header "user:wert:" als Feld ohne Wert interpretiert und im Header eingebaut wurden.

Screenshot 2022-03-20 at 20.15.23.png

[Parsley]

Und noch ein Update: (Sorry für die vielen Posts.)

Wenn ich feld: wert eingebe (Also mit einem Leerzeichen nach dem Doppelpunkt) dann scheint der Header laut "Zuletzt empfangene und gesendete Daten"-Anzeige korrekt gebaut zu werden.
Somit ist für Elabnet und den TWS vermutlich schon fast alles wieder in Butter. Es sollte aber besser auf die korrekte Syntax hingewiesen werden.

Leider scheint das nicht das letzte Problem zu sein, denn die Fehlermeldung in der Antwort hat sich dadurch leider nicht verändert. Ich habe also noch immer ein Problem mit der korrekten Anbindung der Pushover API an den TWS

[Sun1453]

Hallo Parsley,

okay damit hast du ja schonmal einen Zugriff und auch eine Antwort erhalten. Ich möchte an dieser Stelle nochmal einen großen Dank an die vielen Funktionen und auch die Diagnose Möglichkeiten im gesamten TWS an @StefanW sowie das Elabnet Team senden.

Also jetzt muss ich mal schauen was diese Meldung als Antwort des Dienstes bedeutet. Gut das man dies sehr schön im TWS sieht und man nun die Abfrage überprüfen kann.

[Sun1453]

@Parsley

Bitte tausche mal die Reihenfolge von user und token bei optionale Headers. In der API Dokumentation wird immer erst Token und dann User angegeben.

Wenn das nichts hilft könnte es auch damit zusammenhängen das die Message vor den beiden Sicherheits Merkmalen gesendet wird und dadurch das System abbricht. Den Header an sich könnte aber wenn das nur Stefan und sein Team in den groben Zügen ändern.

[StefanW]

Hi Parsley,

bitte mal die Tests von Michael machen.

Die Sache mit dem Leerzeichen nach dem Doppelpunkt wird zeitnah korrigiert

Wiki Dokumentation ist noch nicht erstellt. Das ist eine zweischneidige Sache. Zum einen wäre es toll, wenn es schon eine komplette Dokumentation gibt, wenn ein neues Feature rauskommt, andererseits würde das den Rollout der ersten Version davon um Wochen verzögern und zum anderen hat die Erfahrung auch gezeigt, dass es nochmal zu Änderungen und Erweiterungen kommt, wenn die Testnutzer Rückmeldungen geben und dann muss man das Wiki wieder überarbeiten und vor allem alle Screenshots austauschen, was anstrengender ist, als es aussieht.

Da uns Effizienz und frühe Bereitstellung auch wichtig sind, haben wir noch kein Wiki. Vielleicht bekommen wir die Nutzer dazu, uns mehr zu bezahlen, dann könnten wir dafür jemanden einstellen, das Wiki besser und rechtzeitiger zu haben.

lg

Stefan

[StefanW]

Hi Parsley,

wir haben uns das angesehen.

Aus der der von Dir verlinkten API (den Beispielen) kann man ersehen, dass USER und TOKEN als Parameter zu übergeben sind, NICHT als HEADER.

Also bitte noch zwei Logiken anlegen, welche die Strings für USER und TOKEN erzeugen und diese Objekte als Parameter übergeben, so wie TEXT auch. Hierbei sind die Trigger so einzustellen, dass diese beiden Werte gesendet werden, wenn TEXT sich ändert, so dass immer alles drei übergeben wird.

lg

Stefan

[Parsley]

Hallo Michael, hallo Stefan

danke für eure Unterstützung.

bitte mal die Tests von Michael machen.

Erledigt. Siehe unten.

Die Sache mit dem Leerzeichen nach dem Doppelpunkt wird zeitnah korrigiert

Ganz dickes Lob an euch! Danke!

Wiki Dokumentation ist noch nicht erstellt. Das ist eine zweischneidige Sache. Zum einen wäre es toll, wenn es schon eine komplette Dokumentation gibt, wenn ein neues Feature rauskommt, andererseits würde das den Rollout der ersten Version davon um Wochen verzögern und zum anderen hat die Erfahrung auch gezeigt, dass es nochmal zu Änderungen und Erweiterungen kommt, wenn die Testnutzer Rückmeldungen geben und dann muss man das Wiki wieder überarbeiten und vor allem alle Screenshots austauschen, was anstrengender ist, als es aussieht.

Da uns Effizienz und frühe Bereitstellung auch wichtig sind, haben wir noch kein Wiki. Vielleicht bekommen wir die Nutzer dazu, uns mehr zu bezahlen, dann könnten wir dafür jemanden einstellen, das Wiki besser und rechtzeitiger zu haben.

Alles gut. Dass das Wiki mir nicht helfen konnte, weil es derzeit diese Inhalte noch nicht bietet, soll bitte nicht als Kritik verstanden werden. Für alle nicht-3500er TWS ist dieses Feature ja auch noch gar nicht in der Hauptversion angekommen fällt mir gerade auf.
Andere Foren sind leider nicht so freundlich wie dieses, sodass es eher ein Reflex war zunächst zu schreiben was ich bereits unternommen habe. In diesem Forum gibt es ja zum Glück keinen RTFM-smilie.
Die Zweischneidigkeit (besonders mit Screenshots) kann ich gut verstehen und ihr habt da denke ich schon ein gutes Gespür für den richtigen Kurs. Im Idealfall ist eh alles selbsterklärend und es reichen die Tooltips. Ultimativ sollte die Doku aber nicht vergessen werden, weil sie leider oftmals auch einen sehr großen Teil des Wertes eines Gerätes ausmacht. Sowohl in der Erstellung (Kosten), als auch in der Anwendung (Nutzen).

Ich möchte an dieser Stelle nochmal einen großen Dank an die vielen Funktionen und auch die Diagnose Möglichkeiten im gesamten TWS an @StefanW sowie das Elabnet Team senden.
[...] Gut das man dies sehr schön im TWS sieht und man nun die Abfrage überprüfen kann.

Dem möchte ich mich gerne anschließen! Auch meinen spontanen Wunsch direkt in HTTP-Resource/-Objekt testen zu können kann ich eigentlich schon wieder relativieren, weil es nach Michaels Tip ja auch so schon super einfach zu testen geht.

Bitte tausche mal die Reihenfolge von user und token bei optionale Headers.

Diesen Test habe ich soeben durchgeführt. In den gesendeten Daten sehe ich auch, dass user und token getauscht wurden. Die Antwort ist aber leider unverändert negativ.

Dazu habe ich jetzt auch die Gegenprobe gemacht und im Terminal im curl-Aufruf die parameter vertauscht. Dort funktioniert es auch dann, wenn ich message zuerst sende. Die Reihenfolge der parameter ist also egal. (Wäre mMn auch schlimm, wenn nicht.)

Es scheint also noch irgendeinen Unterschied zwischen curl und TWS zu geben, den ich entweder übersehe oder nicht sehen kann. Dank https komme ich mit meinen beschränkten Wireshark-skills leider auch nicht weiter, sonst hätte ich versucht die Pakete von curl und TWS zu vergleichen.

Spontane Idee in Anlehnung an das Video:
Gibt es eine http (ohne s) api zum Testen, der ich beliebige Dinge zusenden kann? Im Idealfall kommt im response einfach mein request zurück? Dann könnte ich sowohl mit curl, als auch mit dem TWS dieser api irgendwelche POST Daten senden und könnte mittels Wireshark vergleichen was curl und TWS unterscheidet...

lg