1 Sonic Extensions API Specification

This document describes the Sonic Extensions API: an open, collaborative effort to extend the Subsonic API in a backwards-compatible manner. If you would like to contribute to the specification, please read the 2   Proposals for Changes to the Sonic Extensions API Specification document.

1.1 Introduction

The existing Subsonic API defined by the Subsonic project is a client-server API for music streaming. The Subsonic API is supported by a large ecosystem including servers written in many different languages and targeting many different server architectures, and clients for many different platforms. The Subsonic API defines methods for:

  • Browsing songs, artists, and albums

  • Managing playlists

  • User management

  • And more…

However, the Subsonic API has many problems which are not being fixed in the upstream specification (and likely will not be since Subsonic is no longer open source software). Some of the issues with the existing specification include:

  • Outdated and insecure authentication methods.

  • The versioning schema is suboptimal.

  • Insufficient methods for expressing the functionality that a server supports.

  • There is no way of evolving the API in an open and collaborative manner.

This document describes a set of extensions to the existing Subsonic API to help mitigate some of the problems with the existing API and to move the specification forward in an open and collaborative manner.

1.1.1 Goals

The following are goals of the Sonic Extensions API.

  • Be an open, collaboratively maintained specification. See the 2   Proposals for Changes to the Sonic Extensions API Specification document for details on how to contribute to the specification.

  • Be secure.* All of the extensions must be proven to be secure.

  • Be entirely backwards-compatible with the existing Subsonic API. Clients which use the Sonic Extensions API should be able to connect to servers which do not support the Sonic Extensions API. Likewise, clients which do not utilize the Sonic Extensions API should be able to connect to servers which support the Sonic Extensions API.

  • Be piecewise optional (to the furthest extent possible). To the furthest extent possible, each part of the Sonic Extensions API should be optional. Servers should be able to choose what parts of the Sonic Extensions API that they implement, and clients should be able to choose what parts of the Sonic Extensions API that they consume.

* Hopefully one of the byproducts of the security of the Sonic Extensions API is that it will provide more secure methods of interacting with the existing Subsonic API.

1.1.2 Anti-Goals

The following are not goals of the Sonic Extensions API.

  • Replace or deprecate the existing Subsonic API. The Sonic Extensions API is entirely additive. Implementations of the Sonic Extensions API should be also be compliant with the Subsonic API (or at least a well-defined subset thereof).