ioBroker / ioBroker.iot

Connection for Alexa, IFTTT, Google Home and co
MIT License
72 stars 25 forks source link

POST Daten & RESPONSES #16

Open Zefau opened 5 years ago

Zefau commented 5 years ago

Hallo zusammen,

ich habe in meinem ioBroker.nello adapter bereits die custom services von ioBroker.iot in Benutzung. Um Benachrichtigungen der nello API zu empfangen muss ein Webhook gesetzt werden. Statt einer DynDNS und einem offenen Port im Router, nutze ich hierfür die custom services des ioBroker.iot.

Gerne würde ich das auch für den ioBroker.owntracks nutzen, um auch hier die Portöffnung zu umgehen. Die Android App unterstützt einen HTTP-Mode in dem ich die URL eintragen kann.

  1. Ich empfange auch den location payload, aber keine Benutzerdaten. Diese werden für Android über X-Limit-U bzw. X-Limit-D (vgl. https://owntracks.org/booklet/tech/http/#distinguishing-payloads) bereitgestellt, die ich aber nicht weitergereicht werden und ich daher nicht auslesen kann.

  2. Außerdem kann ich keine Antwort (RESPONSE) zurückschicken, was entsprechend der OwnTracks Dokumentation (vgl. https://owntracks.org/booklet/tech/http/#http) möglich wäre. Dies ist notwendig, um mehrere User zu verbinden.

Es würde mich freuen, wenn die zwei genannten Dinge Unterstützung fänden. Gerne unterstütze ich bei der Implementierung.

Vielen Dank im Voraus und viele Grüße Zefau

Zefau commented 5 years ago

@Apollon77 Sorry for the direct tag. I was wondering though if I was able to implement my feature request myself, but looking at the source code I think I can't?

The adapter uses a MQTT client connect to Amazon Services and will thus not receive header information of a POST request. Are you able to change anything on the server part to make this possible? I can do the adapter part afterwards.

I would much appreciate this.

Cheers, Zefau

Apollon77 commented 5 years ago

@GermanBluefox needs to do the server part ...

jpawlowski commented 1 year ago

Can I sneak in here?

The support of POST requests of the IoT adapter is fairly limited as the current implementation mixes URL parameters like ?service=*&user=*&key=*. That means the applications can't expect to have the request body for its data all alone. This is important for applications that are sending JSON data with POST. URL parameters would usually use GET requests and shall better not be mixed with POST requests, I personally would consider this best practice. For a fact, there are frameworks that invalidate URLs with URL parameters when using POST request format (for example Apple, e.g. can quickly be validated with Siri Shortcuts).

So, if there was any change planned, thinking about a new/alternative/additional URL schema would be very much appreciated. The ioBroker.cloud adapter provides such functionality and doesn't have this restriction so switching from ioBroker.cloud to ioBroker.iot is not possible for some scenarios as of today.