I have issues with poor APIs that put important data into headers instead of doing a humane JSON body. Unfortunately, I couldn’t find a way to get a header inside RESTFul Sensor.
More details and example scenario: Allow to access headers in RESTful sensor template - #7 by 0x77dev
You might have to resort to using curl with a commandline or shell command integration.
Yeah, but it appears to be a workaround rather than a proper solution. It’s already cloud/local polling, using a shell with curl and most probably doing scripting seems even more awful than just polling itself. Making headers accessible within value_template would be a much better approach.
Your request is valid, but it’s also good to state an alternative until such time it’s implemented — if ever.
Is what you describe even valid in restful apis?
Headers in RESTful APIs, as per RFC 9205 and related RFCs, are not limited to metadata. Headers can go beyond metadata and hold essential data to interpret the response or even the data itself (which is a common bad practice, but some people still do it) for interpreting responses beyond Content-Type. Having the ability to access headers in a RESTful sensors scenario seems logical since RESTful APIs are based on HTTP, and headers usually carry important metadata that is not accessible with the current state of RESTful sensors.
My specific use case involves a reverse-engineered cloud API of an intercom manufacturer that stores information like when the last call was made in headers. For example, I cannot automate actions based on when my door was last opened because I cannot access state information stored in headers, like for example when the last call happened.
It would be nice to have a good developer experience in this scenario:
What I am proposing:
sensor:
- platform: rest
...
value_template: "{{ headers['x-last-called'] }}"
...
Instead of doing something like this and utilizing shell to parse the header.
Also just an unrelated note, to workaround this I temporarily hosted an Android emulator with a Home Assistant companion app and intercom app to listen for the last notification, which is not bad since this way it’s a push pattern not polling, but managing an Android VM in my home lab is much more expensive than making it run on polling and not thinking that VM died or intercom app has expired push notifications token and needs to be opened.
You convinced me to vote. And thanks for the interesting post.
I want access to the HTTP status code along with this. Use case: ability to check the response’s HTTP status code in the availability template to make the sensor unavailable if it does, or doesn’t, get a correct response code.