search

jishi / node-sonos-http-api

An HTTP API bridge for Sonos easing automation. Hostable on any node.js capable device, like a raspberry pi or similar.
http://jishi.github.io/node-sonos-http-api/
MIT License
1.84k stars 461 forks source link

New feature request: static response-interfaces #480

Open DJPicasso opened 7 years ago

DJPicasso commented 7 years ago

Would it be possible to define a static topology (interface) for the response? E.g. /roomname/state If there is no image in the folder of the song, "albumArtURI" will not be delivered in the response. Also very often objects like "artist" are missing. It would be very helpful that all objects, even if they are empty, are always delivered.

jishi commented 7 years ago

This is usually the case for different kind of sources. For radios and line-in for example, non of that stuff is available, and rather other stuff should be part of it instead. I think it is at least consistent depending on which kind of source type it is, and if I we're to introduce all fields for all responses, there would always be fields that would be empty/null/undefined and I'm not sure if that is desirable.

Are you using some sort of JSON -> Class de-serializer that expects fields to be present?

DJPicasso commented 7 years ago

That's exactly the feature that would be helpful and would make "life" easier. Even if fields would be empty they should be delivered. I use node-sonos-http-api as kind of a gateway between Sonos and a SmartHome server (Phyton based). Here a link of the module I have created with your tool (https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/987045-sonos-integration-in-gira-homeserver-hs3-hs4-vorstellung). My module is also downloadable from that forum. That type of SmartHome server only allows communication through more or less static "interfaces". If only one field is missing it throws an exeption. So I have to create a number of interface with any variation of e.g. /state-responses. Any exeption I have to re-request /state to connect to another type of interface until the exact "construction" of the actual file gets all expected fields ... and that needs to be done e.g. for any "new" song. The same way with other requests like /queue, /zones etc. Also a different sort of fields would throw an exeption and would need a new request.

I think you can image what effort it causes to realize and maintain all kinds of responses. Also a defined topology of response-fields could be "untouchable" even if request functionalities would change.

jishi commented 7 years ago

Additional properties would always need to be allowed, otherwise your deserialization is flawed.

The way I would approach it with the current setup would be:

Have a base interface, that only takes in the source type and other "generic" fields. De-serialize to that first hand.

Check type, and based on type, de-serialize to a more concrete type.

I do understand your argument, but you have to understand that your requirements aren't applicable for everyone and most languages allow for "dynamic" parsing of JSON, where this isn't a problem.

It's a tomato/tomato discussion, but I'll give it some thought.

NovaGL commented 7 years ago

I do this by doing data sanitisation after I receive the json. I replace the albumart with a generic image if no image is available. If title contains the full song description I split it based on title - artist - album

You obviously need to tailor it to each source but once done it makes the data much more usable.

Maybe consider something like Node-Red to complete the information for you.