add support for non-json-request/response

[GsakuL]

Flatpak
StreamController: 1.5.0-beta.4
Requests-Plugin: 1.0.0

Background: I'm using WebHooks on my HomeAssistant. Yes I know there is the HomeAssistant Plugin, but I have existing automatons with WebHooks as triggers, also because some of them may take multiple parameters, which currently is not supported anyways in the HA Plugin. But also personally, I'm hesitant to setup access tokes, without "proper" permission management by HA.

Back on Windows, I used these WebHooks also. And since the stuff I'm using it for is quite obvious (mostly lights), I would see if there is some issue (in any case [HA-Plugin/WebHook/curl] I would check HA first to look at automation traces).
In general, HA WebHooks return an empty (content-length: 0) 200 upon receiving it, regardless of if the Hook ID exists at all.

Currently I use curl -s "http://ha.local/api/webhook/WebHookId?arg1=abc" > /dev/null. This works for my existing/current setup.
But this may become rather long in a single line, if one ever wanted to send a bunch of body data (with sensible Key-Value names?).

Currently the plugin expects all responses to be json. Which would log a lot of "expected errors".
Also an empty response should not show an error in this case.

Nonetheless I can not make sense of the error I'm getting:

2024-06-22 23:31:53.122 | ERROR    | plugins.com_core447_Requests.main:_on_key_down:153 - the JSON object must be str, bytes or bytearray, not dict

That line should not be reached, if there is no json decode in the response?

"My suggestion" would to maybe have a selector of like

• json
  • default, because current
• ignore
  • no text on button
• plain-text ?
  • response.text as is / whitespace-stripped
• xml ?
  • pretty much like json, but different parser. since it may be also pretty popular with certain APIs
  • may need key-syntax addition, to differentiate between child-element and attribute

I know Python in general pretty well, but have never really done ui stuff. However this seems "simple enough to copy" (and read up on Adw inputs), and Wiki Instructions for plugin development seems easy to set up. So I may could do this myself (in the next few days/weeks). Unless of course there is a existing roadmap/changes. (wanted to ask beforehand, as to not "waste" time on a PR that would get rejected).
I'd also extend PostRequest with xml a bit. And of course make all of it clean and extendable (without over-engineering).

I'd be happy to help. :)

[Core447]

I know Python in general pretty well, but have never really done ui stuff. However this seems "simple enough to copy" (and read up on Adw inputs), and Wiki Instructions for plugin development seems easy to set up. So I may could do this myself (in the next few days/weeks). Unless of course there is a existing roadmap/changes. (wanted to ask beforehand, as to not "waste" time on a PR that would get rejected). I'd also extend PostRequest with xml a bit. And of course make all of it clean and extendable (without over-engineering).

I'd be happy to help. :)

No, this is/was not a planned change, so if you want you can implement it. I can also work on this, however, I'm currently focusing on the next app release coming in the next week or so.

[GsakuL]

I'll take a shot at this then. So you can focus on the more important stuff