-
Notifications
You must be signed in to change notification settings - Fork 9
Related Work
This page contains notes on existing music library APIs and how we can take inspiration from them.
There are a few APIs that have some ecosystem surrounding them—multiple clients or multiple server implementations. Two common APIs with multiple clients (Plex and DLNA/UPnP) are not discussed here because information about them is so scarce.
DAAP (iTunes)
An HTTP, REST-esque API. Responses are a binary dictionary-like format.
A /server-info resource lists capabilities of the server and the protocol version. Capabilities like supportsX indicate various features the client can expect. The endpoint is unprivileged; loginrequired indicates whether you have to authenticate for other stuff.
Authentication works by requesting /login using HTTP Basic Auth to get a token. The token is then sent along with all subsequent requests (?session-id=X).
The server keeps track of a "revision number" of the database. This seems to be updated whenever the database changes. Clients can request the number to check whether they need to re-sync the track list.
Multiple distinct databases are (in theory) allowed.
Authentication works by sending the username and password along with every request. This can either be in query parameters or with Basic Auth.
Three serialization formats are supported: XML, JSON, or JSONP.
You can browse songs either by file path (old style) or tags (new style).
Authentication can either be by username/password or by generated API key.
Can brows artists, albums, and songs (even videos).
There's a "localplay" API for DACP-like control, even including a "democratic" voting system.
Other projects have developed an API for a specific client/server pair; other clients (and other server implementations) have not yet appeared.
Authentication is exclusively by a one-time code. There seems to be a voting API.
A /stats endpoint exposes logs for the entire server or individual users (identified by IP). The file type to download is indicated by an extension; it will be transcoded if necessary. You can download a zip file of music subsets.
Authentication (like DAAP) exchanges a username/password for a token. A special /tracks/N/convert explicitly transcodes files into a separate directory on the side. Exposes playlists.
Separate indices of artists, albums, and songs. There's also a separate "query" endpoint. Download a zip file for chunks of music, including their album art.
Straightforward REST-esque design.
A somewhat different approach—more like a complete music player client like Tomahawk than a server. Separated into client and server (UI) components, but not along the lines that we're targeting.
Focuses on keeping clients up to date in real time. Instead of querying for information, you "subscribe" to information and are pushed information as it is updated.
Also designed to reduce conflicts when multiple clients are sending update commands at the same time. Two clients can update the play queue simultaneously without race conditions causing one of the updates to do something unexpected.
Mopidy started as MPD-alike with Spotify, but has since evolved to be a multi frontend/backend streaming solution. The main bit relevant for AURA is parts of our core model for tracking state and allowing frontends to modify things. Core is exposed to clients through a MPD-frontend that translates core to MPD-protocol and a HTTP-frontend which speaks JSON-RPC over WS or HTTP "REST". Pushing events to clients is supported using MPD idle or WS.
Note that the current core API is rather data heavy and there is work underway to only operate on refrences so we can dedupe the data sent in mopidy#704 The goals for 1.x is also breaking API changes of core to take into account things learned so far.
As of 2014-11-04 it looks like it would be trivial to add a AURA frontend to mopidy.
A music streaming server with an ActivityPub-based federation twist.