Friday, 27 June 2008

I’m proud to announce our new public API, which allows any application or device deeper integration with the Last.fm platform than ever before. Our vision is the most comprehensive social music API on the web, and today marks a big step forward in that direction.

The new API introduces a user authentication protocol which for the first time allows applications to create user sessions, bringing both read and write services to web apps, desktop apps and mobile devices.

Take our new taggingAPI’s. Developers can both pull and apply tags to music content from any application on any platform now. The same goes for sharing – developers can build Last.fm sharing support into any app.

There are also new search, playlist, event and geo API’s being rolled out today, with lots more stuff planned in the coming weeks and months.

If you’ve been working with our existing services, bear in mind scrobbling is also integrated with the new API, so there’s just one session key required to use any Last.fm service now.

If you want to work with Last.fm services or have done so in the past, don’t forget to join our new Last.fm web services group to provide feedback & suggestions as well as discuss your application ideas. From tour planners to batch tag editors, we can’t wait to see what you come up with – you’ve consistently surprised us with imaginative ideas so far and we have no doubt in your ability to get on your feet and make it happen.

Most definitely going to be doing some stuff with this. We’ll also need to write some more webservices for other put/set operations that we’ve never had before such as editing playlists and batch tagging.

I’m confused by this on the page to apply for the API key:Bespoke Use
Bespoke applies if you want to stream music using the Last.fm Radio API, or if your organisation has a turnover greater than US $5 Million.

Bespoke Use appears to be a level higher than commercial use, so does this mean that if we want to create applications which can stream Last.fm radio stations we will need to pay for a licence to allow us to use the Radio API? If so, then I don’t imagine many of the users who would like to develop applications like this would have access to the same finances as an organisation making over $5 million a year.

hi, i was excited on hearing that you had a new restful api but it’s really disappointing to see that it’s not restful at all; it’s not even close. It’s simply the same xml-rpc api with the xml swapped out for a x-www-form-urlencoded rpc body.

You clearly want it to be restful judging by the amount of times you mention the term so will you be planning to add a true restful api to the two existing rpc ones in the near future?

Steven: I think there are various valid cases for applying for a bespoke license, not just the large company case. Individual developers can ask for bespoke licenses if they wish, with the dialogue happening via email.

Spud: It’s clearly not a RESTful API in several respects, but the response markup exhibits RESTful properties (it is made up almost exclusively of resources with respective URLs). There are no plans to provide support for true RESTful requests as an alternative to the RPC style.

For simplicity, REST requests are used to describe those that use HTTP POST and GET variables to invoke a method.

@Anil: The presence of links to resources doesn’t make it any more RESTful than the XML-RPC interface. If anything, the only real difference is that the so-called “RESTful” interface is less bulky than the XML-RPC one. Spud is right on the money.

Where’s the uniform interface? All I see is an ad-hoc collection of methods like ‘album.getInfo’: using GET and POST for operations without and with side-effects misses the point. Sure, it might include the URIs of genuine resources on the main site, but the APIitself—and this is the critical point—is not modelled as a set of resource, which makes the idea that if could possibly described as RESTful laughable. If I include links to stuff in an email, that doesn’t make the email RESTful any more than the Last.fm API becomes RESTful because it includes links to stuff.

“For simplicity” just doesn’t cut it as all APIs like this that aren’t RESTful but tunnel RPC over HTTP and yet describe themselves as RESTful create incorrect notions of what REST is about, which makes the term meaningless. Also, there’s already a term for the kind of API you’re exposing: POX over HTTP.

This isn’t to say that it’s great that you’re exposing this API, but advertising it as RESTful is really wrong-headed. Fix the mislabelling and you’ll find a lot of people’s complaints go away.

Keith: I do agree that there is a misuse of the term RESTful here. I understand the architectural distinctions. May review this, though straight up ‘RPC’ is as good a term as POX (which is a lesser known acronym that does not allude to the method invocation paradigm) to describe the behaviour. This distortion of REST is fairly ubiquitous and the decision was made based on approachability and familiarity as much as semantic integrity.

I’m a blind last.fm user and unfortunately I can’t manage my playlist via the web-page and would really appreciate, if I at least could do it via your web-service. It seems your API only offers a playlist.fetch() and no rearrange/resort of the playlist.

Another issue is the flash-player. I can’t use the flash-player controls with my screen-reader. Is it possible to have external controls. Especially the volume- and skip-functionality would be really needed. Couldn’t you at least offer a javascript-API for controlling your flash-widgets? You could have alook at http://video.yahoo.com/ how javascript controls could improve the accessibility of flash-players.

@Artur Ortega, could you try editing your playlist via http://beta.last.fm since we’ve tried to make sure this page also works without javascript (though there is currently a bug that prevents reordering upwards that I’m going to fix now). If you need an invite to the beta let me know you’re username.

I haven’t played with it much, but there are a couple of points I’d like to make.

1) There is no user.getGroups function. I believe (1) this would be useful & (2) it’s been asked for. (The converse, group.getMembers is also missing.)

2) The server for this is still outside the last.fm domain. Any javascript requests on .last.fm pages will fail for these APIs due to XSS security concerns. Thus, user scripts will not be able to access these functions (other than Greasemonkey, which bypasses XSS security). Could future updates be accessable through an api.last.fm style host? (If this is done correctly, the authentication could use the Last.fm auth mechanism.)

3) (Okay, I lied.) There is no parameter on the tag.getTopArtists call to set the parameters to limit to a particular users’ tags, so you’re getting the global tags, and can’t chain user.getTopTags -> tag.getTopArtists to get a users’ tagged artists by tag. (Something I’d like anyway.) (Ah, I see others above have asked for this, too.)

Having said all that, the api looks good, with a consistent calling structure and error codes. The geo.* functions could be quite handy.

@Gabe: The answer, for now, is no.
@Ysamjo: Regarding point 3 – activity services are planned.
@snyde1: Regarding point 1, those methods are coming shortly. Regarding point 3 – some services are coming to satisfy your need for further tagging API’s.

In general the api is cool. But since I have been playing with it for a few days I found that there are some bugs here and there.

For eg: The api to get the neighbors of a user, user.getNeighbours , returns this faulty link for image —> ‘<image>http://userserve-ak.last.fm/serve//1451306.gif</image>
‘
I had to go all the way around and parse the entire string to obtain the right link.

I had another query, could I somehow get the link directly to the preview of a song? play it through XSPF player or something?
Where can I report bugs?