Jamendo Api Read Methods
As mentioned in the introduction, all read api methods have to be http or https GET requests. You can find the list of all existing read methods below, linking to their respective documentation page.
Parameters
Every Read Method (the base url) accepts a given list of get parameters, with some conditions imposed on their values (type, accepted values, can it have multiple values, etc).
If one ore more of these conditions are not respected, the Api framework will raise an appropriate error code and message, while any get parameter not belonging to the accepted list will simply get ignored, it will raise a warning though.
Every method's documentation page presents a table, containing the list of accepted parameters, their value type and a description.
In the type-column, the syntax []integer means that such parameter also accepts multiple values, and each of those values must be an integer. In this case, multiple values can be specified using ' ' (a space) or '+' (a plus sign) as separator. A maximum number of accepted multiple values exists, and it's .
Note that also the enum type exists.
By default every /entity/subentity method will inherit the parameters declaration of its relative /entity "parent" method. In addition to this, almost every read method accepts and shares the declaration of the following common parameters. Any eventual exception to this rule is clearly marked on the method documentation pages.
| name | type | description | required |
|---|---|---|---|
| client_id | string | A Client Id provided by devportal.jamendo.com. | yes |
| format | enum: {xml, json, jsonpretty} | The results formatting type | no |
| callback | string | Use this parameter to have the response json wrapped in a callback function (jsonp technique). Such feature is enable only for json format and GET requests; if used in combination with other formats or a not-get request, the callback parameter is simply ignored and a warning is raised | no |
| offset | integer | The position to start returning results from | no |
| limit | string | The max number of results to return. Default is 10 and Max is 200. Using the keyword 'all' still a max of 200 rows will be returned | no |
| order | []enum: {} | Sort results by the queried field(s). You can specify whether to follow an ascending or descending order adding the suffix _asc or _desc to every field (order=field_asc). Asc is the default one. | no |
| fullcount | boolean | Setting this parameter to true, the document header will be enriched with the 'results_fullcount' value, that is, the absolute number of rows the query would return if there was no limit and offset parameter. This value is of course very useful for pagination, but please: use it only if you really need it, as it affects performances! For this performance reasons such parameter is not available in most heavy methods. | no |
Returned fields
Every method will return a list of entities matching your query. Every entity is described by a list of fields (and their values of course) that does not forcedly have a correspondent parameter, although it often is the case. Note that at the moment the returned fields are statically returned, meaning that you cannot "switch off" or "switch on" any returned field.
Entities aggregation
You'll notice that methods like /playlists/tracks lists the 'track' subentities in an aggregated and not tabular way. In this case the limit paramter still refers to the number of playlists to return, and not the number of tracks-per-playlist.
Soon we will enable the subentities limit and offset handling through parameters in the form of <subentity>_limit and <subentity>_offset. For instance, in the method /playlists/tracks, the parameter tracks_limit will set the limit of tracks per playlist.
Be carefull because there's a maximum limit of total aggregated subentities returned by entity/subentity methods and thus we cannot ensure that the number of returned subentities corresponds to the expected amount.
Such limit is 400, while the maximum number of entities returned is 200.
