The REST API is quite common and not specific to openHAB.
JSON is extremely common when using REST APIs. If openHAB uses strings, that is indeed quite specific to openHAB.
The REST API is quite common and not specific to openHAB.
JSON is extremely common when using REST APIs. If openHAB uses strings, that is indeed quite specific to openHAB.
You misunderstand the usage of the term here. English is a language. So is German. Therefore, all English speakers understand German? So it goes with API, and the subset of API called REST API. Sending a bundle of http to a Google Maps API with a bunch of data about Things and Items (i.e. OH format) isnât going to do much.
The specific problem here is sending a message via REST API that says âset Item X to content zzzzzzâ.
That goes wrong if you send âabcdâ to a Number type Item, understandably.
But works if you send â3.14â (which is text, a string)
Itâs fine to send some text â{ value: pair }â to a String Item.
But - gasp - thatâs JSON!
No it isnât, itâs a string that you can choose to interpret as JSON later if you wish.
The trouble here is with the HTTP that wraps around our actual message, which carries additional information about the type of content.
Every real OH REST API message expects http content type âtextâ
Even when the content is â3.14â destined for a Number Item.
The proposal is for http content âjsonâ, which is not just text, it has key-value pairs, structure, hierarchy, etc. Which bit of that should we select as the OH payload?
What the OP wanted was for the REST API to break the http rules - âI know I said it was JSON, but please ignore that and treat it as though it was a long single string of text insteadâ
Thatâs not altogether unreasonable, but is a band-aid, a bodge.
Looking ayt many configurations here, you would think so
The API is specific but the REST API, especially using JSON is pretty much a standard now.
The OP does not want to use JSON, he wants to ignore JSON (until later)
All German speakers understand English of course
True but as a non-German speaker I get lost in many of the configurations here due to language barriers.
I worked for a Swedish company for a while ane all Swedes understand English. I got working with come Swedish C code (variable names made sense if you knew Swedish). Some alerts were Swedish only but I had people who could translate for me when I could not figure out the logic.
Indeed, REST is not specific to openHAB. It is a way to define an API. openHAB has implemented an API using this technique. But openHABâs implementation is necessarily different from InfluxDBâs REST API or Rokuâs REST API or Google Mapâs REST API because itâs openHABâs API. Every service that provides a REST API provides a unique implementation because an API defines how to interact with a specific service. There is not one REST API that everyone uses. There are an infinity of APIs that are implemented using the REST technique.
So rossko57 is right, the fact that openHAB doesnât accept text/json to update or command Items is a choice of the openHAB developers. Not accepting text/json at that end point doesnât mean openHAB isnât using REST. Just because JSON and REST are very common doesnât mean it makes sense for openHAB to accept JSON at that specific REST API endpoint for openHABâs REST API. openHAB gets to define itâs own API in any way that it wishes.
Iâm not arguing against modifying the REST API to accept text/json, though I tend to agree with rossko57 that it feels a little off. Typically itâs the job of the client (i.e. the thing making the REST API call) to conform to the API as defined by the service (i.e. openHAB), not the other way around.
So in my original example, my external provider has an api that I can periodically query. However the limits imposed by them mean that this is clunky, data has to be split up and the load on the system is quite big.
However they also have webhooks available, but they will only send json content. Using openhabCloud I could get the binding to set up the webhooks, but the problem is openhabs api cannot accept the json.
Thanks for the additional explanation! I guess I had been thinking about this as âjust another bindingâ that wasnât flexible enough to accomplish what I want, rather than as âThe Official REST API for openhabâ. I can see the argument that validation is desirable here, for example, if someday there is a JSON datatype and you want to only accept text/json when writing to such an Item.
Iâve gone ahead and accomplished what I needed with python/flask. It is another piece to manage, but it works.
Do we think its useful to open a github issue to be more flexible here? There seem to be several users asking for it, and IMO this behavior would be consistent with other parts of openhab. At least in rules, the system seems to be fairly liberal when coercing types (though I will admit, Iâve only been a user for < 1 month). Or is the consensus that this will be rejected and I should just move along?
I think you need to construct a good use case.
âI want to force arbitrary openHAB objects that expect text updates to accept JSON content, but to hack the format and not treat it as JSON but as a string instead, because âŠâ
A better form of words would be wise, but the âbecauseâ part is important. This is a core part of openHAB intended for UI control, and changes wonât be made lightly.
Wonât be my decision, itâs just advice.
Itâs not clear to me if a âproperâ JSON REST API point would do what you want e.g. send JSON like
{ âItemnameâ=âmyItemâ ; âstateâ=âONâ }
Iâm not clear what security risks may arise; nothing extra, I guess.
It still strikes me that what is actually needed is a general âHTTP/HTTPS server (listener) bindingâ that would allow use of all the usual validation and transformation tools, choice of multiple channels to Items of varied type etc., and potentially offer some security validation (e.g. passwording)
As a hack, one can build their own using the conf/html config files. I do something similar to this to handle an OAuth2 callback in OAuth2 using just OH Rules and myopenhab.org. Iâm not sure how easy or whether itâs possible to accept POST/PUT with a body in that way, but based on my experience most users are limited by their service only supporting GET webhooks.
Good Day Guys
Just a quick question regarding the REST API, Is there any way to pass an event origin parameter to rest API and get it back from the event streaming API. What I want to do is differentiate the events coming from openhab and connected devices vs events coming back form the updates I sent from REST to avoid loops.
Cheers
Roshan
Short answer is no. If you are using Rules see Design Pattern: Manual Trigger Detection for a way to do this.