API version 1.0, retiring 0.1

API version 1.0, retiring 0.1

Posted 13 Jul 2017, 7:46:17

Hey setlist.fm API users,

We have recently deployed a new version of the setlist.fm API. This API is now the recommended way to access setlist.fm data and we’ll be retiring the old version (/0.1) by the end of the year 2017.

The migration from 0.1 to 1.0 is pretty straight forward as the endpoints have been kept very similar to the previous version. The same applies to the format where only minor adaptations are necessary. In order to use the new API version it is now necessary to provide your API key (can be found in your API settings) as HTTP header x-api-key in your request. To have a look at the new methods and format you can easily use the interactive web interface

If you’re having troubles with the migration, please post your problems to this forum topic. Should you be having troubles with your API key or problems that can’t be posted publicly, please get in touch with us using one of the contact e-mail addresses.

Re: API version 1.0, retiring 0.1

Posted 14 Jul 2017, 11:44:18

Cool to see an update to the API! Is there a list of changes anywhere?

One thing that irked me about the 0.1 API is that 'sets' (and songs I think?) would change from array to an object if there was only one item. Is it guaranteed to always be an array now?

I look forward to trying this out!

Re: API version 1.0, retiring 0.1

Posted 14 Jul 2017, 12:00:49

Is there a list of changes anywhere?

No, there really weren't a lot. The most important ones maybe are

  • you have to provide your API key as header
  • to receive a JSON response you need to set the Accept header to application/json
  • the @ for attributes in the json response got removed
  • last.fm properties got deprecated

Is it guaranteed to always be an array now?

The underlying serialization got switched out and therefore some previous inconsistencies got fixed. Also, I checked and compared some setlists (with one set, with more sets, with one song, with more songs) and the results were always an array where it used to be an object. So I'd like to answer the question with yes, but please check for yourself :)

There is the odd more property in some queries, but generally the API has been kept as close to the old version as possible to make the switch easier for users.

Re: API version 1.0, retiring 0.1

Posted 14 Jul 2017, 12:06:12

That's great, glad to hear that! I'll try it out and let you know if I have any feedback.

Re: API version 1.0, retiring 0.1

Posted 14 Jul 2017, 15:40:17

One thing to notice: You need to access the API now through https. If you try to access the API through http you receive a cloudfront error.

Re: API version 1.0, retiring 0.1

Posted 14 Jul 2017, 18:47:27

I've finished a first API-Wrapper of the new API-Version for Node.js. The wrapper is Promise based and contains all endpoints of the current release. Just in case anyone would like to dive into the new API with Node.js right away:

https://www.npmjs.com/package/setlistfm-js
https://github.com/terhuerne/setlistfm-js

Re: API version 1.0, retiring 0.1

Posted 8 Sep 2017, 17:12:14

terheueme,

I tried your Runkit with this and it returned nothing:

var setlistfm = require(“setlistfm-js”);
var data ={}
var setlistfmClient = new setlistfm({
key: “MYKEYWASHERE“, // Insert your personal key here
format: “json”, // “json” or “xml”, defaults to “json”
language: “en”, // defaults to “en”
});
setlistfmClient.getArtist(“8538e728-ca0b-4321-b7e5-cff6565dd4c0″)
.then(function(setlists) {
// Returns page one of all Depeche Mode setlists
data = setlists
console.log('setlistman' + setlists);
})
.catch(function(error) {
// Returns error
console.log('error' + error);
});

console.log('data' + data);
Re: API version 1.0, retiring 0.1

Posted 15 Nov 2017, 5:26:11

Hey, I was wondering if setlist.fm supports CORS and if no, why not. I am running into issues with using the setlist.fm api in javascript and keep getting a CORS error. Another theory is that the request are missing the api key. Thanks!

Last edited 15 Nov 2017, 5:27:26

Re: API version 1.0, retiring 0.1

Posted 15 Nov 2017, 6:24:02

@ksegal You're right, the request fails because the setlist.fm API does not allow requests from foreign frontends. This is, I guess, a security feature as setlist.fm wants to prevent developers from exposing their API key to the public through user readible code in the frontend.

I would suggest to build a middleware with Node.js, host it on your Domain and then access the ressource through the connector.

Re: API version 1.0, retiring 0.1

Posted 15 Nov 2017, 9:20:00

This is spot on by terhuerne, nothing to add except agreement :-)

A reminder maybe: please be sure not to expose your private API keys.

Re: API version 1.0, retiring 0.1

Posted 15 Nov 2017, 16:15:03

Thank you for your prompt replies and confirming the source of the issues I was encountering.

I think it could be useful to add to the setlist documentation that the API does not allow CORS (and also maybe to remind there that people should not expose private API keys as I see a lot of other APIs including that reminder on their documentation).

Re: API version 1.0, retiring 0.1

Posted 24 Mar 2018, 16:53:53

Just wanted to say thanks for your work on the new API version :)

Re: API version 1.0, retiring 0.1

Posted 26 Mar 2018, 7:07:33

Just wanted to say thanks for your work on the new API version :)

That's very nice to hear. Thank you!

Re: API version 1.0, retiring 0.1

Posted 13 May 2018, 23:11:38

@terhuerne can you elaborate on how we would do this with middleware? I'm creating a simple React app and just using the fetchAPI to request data from the these endpoints, and keep running into the CORS error when simply console logging on Chrome. Same with your NPM Wrapper.

How is setlist intending for clients to use this then? How are we to access these resources without exposing the API key in the 'x-api-key' of the header?

The documentation addresses none of these concerns.

Last edited 13 May 2018, 23:48:26

Re: API version 1.0, retiring 0.1

Posted 14 May 2018, 7:35:04

How is setlist intending for clients to use this then?

That's the point. The API key should never be on the client (= browser).

How are we to access these resources without exposing the API key in the 'x-api-key' of the header?

This is up to the consumer's implementation. But the general idea is not to let the clients fire requests to the setlist.fm API. It should be “your client app” -> “your server app” -> “setlist.fm API“. Ideally additionally with some caching on your side.

Last edited 14 May 2018, 7:35:54

Post Reply

You're not allowed to do this, please sign in first.