Rest API JSON Payload

Setup, Configuration and Use Runtime
1

Are there any workarounds to be able to receive a JSON payload on the rest api?

Im restricted to recieving JSON and the POST method so my plan was to update a string with it and then extract what i need, however the api only receives text/plain.

1 Like
2

I think all the REST API outputs is JSON. I believe the requests input are JSON too.

3

Yeah I think Bruce is correct

4

JSON is just a formal for plain text. The text/plain and text/json is a way to tell the receiver what format the text is in so it knows how to deal with it. But in this case:

  • it doesn’t need to do anything to it except set the Item’s state to it
  • you already know it’s JSON so you can apply your transformations and roles to it regardless as to whether it was posted as text/plain or text/json.

So just poat the JSON as text/plain if you need to. It will still work.

5

Hi guys

So using postman I can successfully set a string if I post using content-type : plain/text
Ie: post https://myopenhab.org/items/ItemName
(Header to authenticate)
If I post using the json content-type it does not update the string.

The documentation also says plain text for post item updates

If you I’m missing something please help and show me an example
Thanks in advance

6

So just post it using plain/text. You’ve already shown that it works.

7

I’ve posted as plain text to test, the provider only sends as application/json tho

8

+1 to accepting text/json in addition to text/plain. It seems odd to me that openhab has support for working with json data, but won’t accept it via the REST API.

I’d really like to integrate openhab with the vegetronix sensor hub. However it (correctly) labels its report as JSON.

I’d be happy to try and open a pull request if someone could give me a pointer to where this is implemented.

9

I think it is likely part of the core. t might be better to file an issue here to be included in openHAB 3. There are no more core changes for openHAB 2.x.

10

But what would you do with it? There is no JSON Item type to accept it.

11

I was hoping I could just store it as a String, and then use rules + transform("JSONPATH", ...) to parse it and put the results into other Items.

Thanks for the pointer!

12

Yep, that was kind of my point. It’s just a string you’re sending to openHAB, and you want it to be treated as just a string. It’s almost an “abuse of process” to want to send something marked as ‘json’ but please treat it as ‘text’.
However convenient it might be for your particular problem, it doesn’t sound appropriate (though of course that’s not my decision).

The “correct” approach for getting JSON from some remote service and analyzing into multiple Items would normally be a binding.

1 Like
13

Actually Python & PHP do that quite easily.

14

Python, PHP, JavaScript, and even Java do it quite easily. But what rossko57 is referring to is how OH is architected and implemented. I tend to agree with him that it feels a bit odd to accept JSON into a plain old String Item. And since OH doesn’t have a JSON type Item, a plain old String Item is all we got.

But I also see Michael’s point because that means that the integration he is after isn’t possible.

So as far as I can see, the solution would be either:

  1. update the core so the REST API accepts all of the text types (text/xml, mime types, etc.)
  2. create a binding
15

Sounds like something for the OH3 roadmap :wink:

16

If the maintainers think it’s something appropriate to do. Just because something can be done doesn’t mean it should be done.

17

And, I suspect, unless it is listed ad a GitHub issue it would not even be considered.

18

I’m not sure I understand this concern. The magic of JSON is that it is a human readable String that can also be interpreted by computers. I think the situation would be different were this some binary format that could be corrupted by interpreting it as text. In that case I would agree with blocking it.

If it is improper to store JSON in a String, then is the transform function provided by openhab (which can take in a string and interpret it as JSON) also improper?

Should I open up an issue on github then? (Sorry, I’m very new to this community.) @rlkoshak 's proposal of accepting all text mime types would definitely solve my use case.

19

I believe this is the proper place.

20

Not at all. My concern is not about shovelling JSON content around in strings, of course that happens in just about any system, whether for convenience or necessity.

It’s about sending an http message that is marked as JSON to a well-defined service, and expecting that service to mishandle the JSON as though it were marked as text.

There’s no imperative for doing that, and it would be reasonable to resist it on the basis that it would adversely impact future development of the REST API. it’s not far-fetched to suppose some future enhancement that does use JSON properly - say, updating both state and tags, or updating multiple Items.

The REST API is quite specific to openHAB. While it is a tool for users, this use case here feels like it is being pressed into service to suit some more general requirement.

What is ideally needed for this job is an “HTTP Server” binding that could service unsolicited HTTP payloads, be they JSON or XML or what, and the user can (as with other bindings) use transformation techniques to pre-process, allot the data to several Items, and/or screen out rubbish, as they wish.
It would be generally useful, I think.

The closest existing thing is the TCP listening binding, which could be used here, but would require a fair amount of building onto I think.

2 Likes