#REST headers XML

1 messages · Page 1 of 1 (latest)

sonic dirge
#

Would it make sense to only map the known headers strict and just look at leftover content?

#

so XML header -> parse XML, JSON header -> parse JSON, different header -> check if it's XML or JSON

ember notch
#

I think it would be better to allow configuring the data type

sonic dirge
#

oh that's also a good one

ember notch
#

should we suggest that?

sonic dirge
#

I already left a review as prek was failing

#

But it went stale, let's first check if they get back

ember notch
#

Why wait? If we have some other idea, we should suggest that now to not waste time?

sonic dirge
ember notch
#

Ah, I misunderstood. I thought you wanted to wait until after the auther was active in the PR again,

sonic dirge
#

I think that's also a bit what I meant

oblique ivy
#

To be honest, I would not even add a option to select the data type as the device is sending the data completely wrong

sonic dirge
#

Sure, but then the options are

  • Try to parse it
  • Users can't use the rest integration because their device is not doing something correct
  • Have the user explicitly set the type
  • Have a list of exceptions or headers to take into account
oblique ivy
#

The problem with having an option would mean we are ignoring the content type and try to parse is as specified and that could lead to bugs. Also if you have a device, which sends sometime XML and sometime json would not work anymore. I don't have a concrete example and I don't even expect that some device will do it but currently it would be possible, which will be prevented if a config option

sonic dirge
#

Sure, if an endpoint provides data in a specific case, that wouldn't be covered. However

  • That's and edge case
  • You'd at least assume that it would change headers if that's a feature
#

But if that happens today, then the REST integration wouldn't work for that device either

oblique ivy
#

Currently the rest integration just works fine if the content type changes between requests

sonic dirge
#

but I didn't want to break that

oblique ivy
#

Sorry but the PR is really an edge case, where a device is sending a wrong content type header, which is not matching the returned data

sonic dirge
#

We could make an optional key to force a certain type, because we can't parse everything

#

Yes, but we receive data fine, the only limiting factor is us not being able to map it

oblique ivy
#

Wait maybe I have an idea

#

We could add an accept header to the rest integration https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept so we tell the device which data we can understand

MDN Web Docs
Accept header - HTTP | MDN

The HTTP Accept request and response header indicates which content types, expressed as MIME types, the sender is able to understand.
In requests, the server uses content negotiation to select one of the proposals and informs the client of the choice with the Content-Type response header.
In responses, it provides information about which content...

#

Also can you ask the user to try to manually add it? Some devices are checking it and returning then the correct data format. Maybe this will help

sonic dirge
#

I guess we can try, but I think that's a separate discussion

#

Like if they already don't care about the headers we're getting back, I can see a world where this doesn't work

oblique ivy
#

It's worth a try as it would fix the issue for him without any changes. You can already set headers

#

and we should set them as we just accept certain types

sonic dirge
#

At this point I am convinced it will probably break a lot of very niche devices 😅