Each endpoint type has a unique way of navigating into sub-directories to expose further endpoints.


The root of your API is a Directory. This simply outlines the possible Collections you can use, and allows you to navigate into them.


200 OK
    { "name": "artists", "type" : "collection" },
    { "name": "albums", "type" : "collection" },
    { "name": "tracks", "type" : "collection" }

The name field shows the string you can use in the URL to navigate into that collection from this directory, e.g. /artists, /albums or /tracks.


Collections list the available Items you can navigate into.

GET /artists

200 OK
    { "id": 122 },
    { "id": 123 },
    { "id": 124 }

Collections use an Identifier field, defined in your (Stems or Fluent) code. This is conventionally an id field, or perhaps a unique name field. Specifying the value of an identifier in the URL navigates into an Item.

Additionally, you can use the by_ prefix to navigate into a Dictionary. This groups the collection by a field and displays the results as an object with a field for each value. Dictionaries can be further navigated by the value, which means these can be used to specify which identifier to use to find an item too, e.g. /artists/by_name/noisia.


Items are single entities within a collection.

GET /artists/123

200 OK
    "id": 123,
    "name": "Noisia"

Field names can be drilled-into to return the single value of that field. These values could be sub-collections, sub-items or simply Scalar values.

Sub-collections and sub-items provide further navigation. These can all be chained together into longer URLs, e.g. /artists/123/tracks/456/artists.


Currently, scalar values can't be navigated into any further.

GET /artists/123/name

200 OK