Rdio Developer Blog

We've updated the Web Service API to improve some methods and expose some new data. Here's a brief summary of the changes:

Playlists:

• addToPlaylist and removeFromPlaylist now return the playlist on success or null on failure rather than true/false. They also now take an extras argument to specify which playlist fields are desired.

Users:

• userFollowers and userFollowing now take a new inCommon argument - a user to filter the results by. For example if I call userFollowing(user='s1', inCommon='s13') then I will get the users that user 's1' follows that 's13' also follows.

Labels:

• New methods getAlbumsForLabel and getArtistsForLabel return the albums and artists for a particular label.
• Album objects now have an optional label field that describes the label.

Minor improvements:

• searchSuggestions now takes an optional types argument to indicate which types search.
• getActivityStream now takes a count argument
• getObjectFromUrl now supports short-code urls (ie: http://rd.io/x/...)

Here’s the latest news from the Rdio API developer community:

API Updates

• Removed the authentication requirement for getPlaylists
• Allowed the Web Playback API to expose the current user's subscription state so that apps can easily check if the user is a subscriber or not

New Apps

• SoundTracking launched their new Android app featuring Rdio support

Misc

• Added a jQuery plugin for the web playback API

Join the Rdio API Google Group to discuss the API, ask questions, and share what you’re working on — we might feature your projects on the Rdio blog. (we recently featured Trnsmit)

For the news and updates, follow @RdioAPI on Twitter, and subscribe to the Rdio Developer Blog RSS feed.

At Rdio we're excited to be sponsoring and participating in Hollywood Hack Day, a music and video hack day in Los Angeles over the weekend of November 5th and 6th. Rdio will be there to help developers build hacks and apps on top of our platform and to give out some cool prizes.

The hack day is being generously hosted by Katalyst at their offices in the heart of the media industry in Hollywood. Our co-sponsors include a cross-section of multimedia platform companies. For more information on other sponsors and the prizes we’ll be giving out check out the official site:
http://www.hollywoodhackday.com/

And sign up to attend at:
http://hackhollywood.eventbrite.com/

We’re really excited to see what hacks we can create!

Recently we've made some improvements to the Rdio web service. The documentation is now up to date.

Iframe Embedding

Until recently Rdio allowed users to embed albums, tracks and playlists by copy-and-pasting and <object>/<embed> tag. We've just moved to using an <iframe> based embedding approach, partly to fix some bugs and partly to give us more flexibility in the future. Things that can be embedded (Tracks, Albums and Playlists) now have an optional iframeUrl field that can be requested through extras from any method that returns those types. You can embed with code like:
   <iframe width="width" height="height" src="iframeUrl" frameborder="0"></iframe>

UPCs and ISRCs

UPCs are Universal Product Codes, like CD bar codes. There's one for each musical release (like an album or a single). ISRCs are International Standard Recording Codes, they're like that but for musical recordings. Each recording should have the same ISRC, even if a recording is shared across multiple releases (for example a single, an album track and a best-of compilation track). Rdio now exposes UPCs on albums and ISRCs on tracks through the optional upcs and isrcs fields on Album and Track objects.

There are now getAlbumsByUPC and getTracksByISRC methods to search the Rdio catalog based on these identifiers. These are quite useful for mashups since other music services and databases expose these.

More extras and cleanup

More methods now take extras including getObjectFromUrl, getObjectFromShortCode and getActivityStream. getObjectFromUrl and getObjectFromShortCode no longer require authentication. getHeavyRotation takes start and count so it's possible to page through results.

Track now has an optional isInCollection field that indicates if the track is in the calling user's collection. Playlists have an optional trackKeys array field. Users have artistCount and albumCount to complement the existing trackCount, these indicate the user's collection size.

We've noticed that getting a working OAuth library installed isn't as straight-forward as we'd like. It's hard to get libraries installed and many of them don't support the subset of OAuth that Rdio uses. In response we've developed a set of very simple libraries for PHP, Python and Ruby that implement the parts of OAuth that Rdio uses, plus basic methods for authenticating against Rdio and calling methods on the Rdio Web Service.

We hope that these will help developers get up and running on the Rdio platform quickly.

More documentation is available here: http://developer.rdio.com/docs/read/rest/rdiosimple 
And the source code is here: https://github.com/rdio/rdio-simple 

On Friday we launched an API for our service. There are currently two components, a flash-based playback API and an RPC API over HTTP. We had an internal discussion on how to describe that second API in our high-level documentation. Technically speaking it's RPC over HTTP POST with OAuth signing, but that's a bit wordy and confusing. We worked on making it as simple to use and as familiar as possible. It's inspired by the popular Flickr, Last.fm and Facebook APIs.

On Monday Jens Alfke posted about our API criticizing our use of the term REST to describe it. This made the front page of Hacker News. Jens is right, our API, like most of the popular "REST" APIs, is not REST as defined by Roy Fielding. We're going to update our documentation to reflect that.