Fake Sonos HTTP API

[kswilster]

This issue should serve as more of an RFC for the idea I'm proposing. I'd like to gauge interest in this idea and see if it's worth pursuing, as well as getting feedback.

I am developing an application that uses node-sonos-http-api, and my ability to make progress on it is dependent on having access to a Sonos device, which is not always convenient. I would prefer to have a fake http server I can spin up locally and use to develop and test against. At the moment, I am using a fake-sonos-http-api that consists of duplicated responses from node-sonos-http-api, but I'd like to take this idea further. The goal of this fake server would be to mimic this existing API while updating a database that stores fake sonos data about existing zones, how they're grouped, and what music they're playing.

I'm proposing a project that mirrors fake servers like fake-s3 and https://mailtrap.io/, a fake email service. Here are some of the features I'd like to see in such a project. Again, I'm submitting this issue to collect feedback, I'd love to hear what others might find useful in such a project.

Features

• Database or other storage mechanism for maintaining state
• Background workers to update time-based state such as elapsed time on songs or current track when playing through an album
• Admin interface for modifying state (either an API or GUI)
  • zone CRUD should happen here (you can't create zones through the standard api)
• mimic node-sonos-http-api responses for all existing requests

[jishi]

Hi! Interesting suggestion. I never really foresaw the http api to be the basis of other applications, but rather the underlying library (sonos-discovery) for node.js based ones. Hence, the HTTP API was initially purely a thin wrapper for the discovery-package. It has, however grown since then and some of the features are purely in the http-api (unfortunately).

Could you please describe what kind of application you are building on top of the http api? I might help shed light on what kind of fake server you actually want.

In theory, it should suffice to build a fake discovery, since the primary part of the software actually resides in there. All state tracking etc are part of that package, and if only that is faked, the same http api code should run on top of that.

[kswilster]

@jishi excellent point that the fake discovery service would provide the necessary foundation for the http api to run on top of. Assuming that is the preferred implementation of the fake service, what features do you think are worth exploring for an MVP?

I use the http api for bronos, a command line interface for sonos.

As a side note: I would love to hear what you see as the use cases for both the http api and sonos-discovery, it's possible that I'm using the wrong package for my needs. did you intend for the http api to mostly be used through a browser/Postman/curl?

[jishi]

The HTTP API was primarily for home automation needs, since HA systems usually allows for simple requests to be issued. I'm also using it extensively with IFTTT (exposing it publically with lets encrypt SSL certificate and basic auth). Also for basic scripting where you are not running a long-lived process to keep track of the players.

The sonos-discovery is the real engine behind it, and it make sense for your program to use directly if it is it's own console and not a regular cmd line util (not one execution, one command).

[fguchelaar]

A little late to the game and probably too late as well, but last week I found myself in a similar position: I don't have enough devices in my possession to accommodate for all my use-cases. So I started working on a mock.

It's a very simplistic implementation so far, but it provides me with the ability to group multiple devices and set the volume. Data is not persisted across run. For those interested, you can find the repo here: https://github.com/fguchelaar/mock-sonos-http-api.