Please go see the news feed (here is the RSS) at webservices.rhapsody.com! The news feed is regularly updated with reviews, tips, news, and announcements about Rhapsody web services and its api set. Or subscribe to the community forum RSS feed. Thanks all.
Matthew Lapora
Program Manager, Rhapsody Web Services
Leo Dirac wrote a firefox extension using Greasemonkey that lets you listen to Rhapsody music from any web page. It scans web pages for the names of popular artists and converts them to Rhaplinks. You can also read more about the computer science of regular expressions in javascript in an earlier post about how the script was developed.
The script is still being tweaked, but feedback is welcome. Instructions for installation are here. If you find any issues with it, please let us know in the mashup discussion forum.
Over the last few weeks there's been a lot of Rhapsody news. Sonos and SanDisk announced several completely new products that will set new industry standards. We've just released a ground-breaking new version of the Rhapsody jukebox. Rhapsody Online has now gone live with an entirely new set of features and capabilities. All of these products and services were constructed using Rhapsody DNA: We've cranked on the lights in the Rhapsody network.
This white paper provides an overview of Rhapsody DNA, the music software platform that enables integration of the award-winning Rhapsody experience directly into hardware, software and the Web.
Rhapsody DNA is an extension to Rhapsody that provides the entire technology stack needed for a Rhapsody-branded consumer facing experience. Rhapsody DNA provides the consumer with secure, personalized end-to-end hardware, software and browser access to music and music assets.
Rhapsody DNA delivers unlimited and dynamic music content from connected and off-line home entertainment systems, portable music devices, mobile phones, Web and software applications. It redefines the consumer digital music experience by creating ubiquitous, personalized and interoperable music access from any device.
Rhapsody DNA provides developers, OEMs and device partners a world-class standards-based platform that can be used to directly compete or coexist with other end-to-end music platforms.
This white paper serves as an introduction to the Rhapsody DNA SDKs. Look for updates to this white paper as we introduce individual SDKs and as we add additional APIs, features and capabilities.
We welcome your feedback and invite you to join our forums, participate in our blogs and develop with Rhapsody DNA.
Make Music Happen
Ben Rotholtz
General Manager, Web Services
& Syndication
Hey everyone, just a friendly reminder that we are focusing more on our website these days instead of our blog (as it has blog functionality, and more). We are posting news articles there, as well as keeping on top of a dynamic Rhapsody Web Services forum. Please take a look and feel free to commune...
http://webservices.rhapsody.com
-- UPDATE --
Here are the main RSS feeds for the webservices.rhapsody.com site:
News articles: http://webservices.rhapsody.com/backend.php
Forum (general topics): http://webservices.rhapsody.com/backforum.php?forum_id=1
Thanks,
The RWS team
Today we took the wraps off of Rhapsody DNA and the first MP3 player that uses Rhapsody DNA. Although Rhapsody is often chosen by consumers and critics as the best digital music service for the PC, we know we won’t succeed in making it a mass market product until we also let consumers access Rhapsody off their PC.
To make Rhapsody DNA possible we have expended tremendous effort across multiple groups within Real over the past 18 months. Rhapsody DNA is both a technology platform and a set of marketing initiatives.
At this point it seems obvious that everyone sees the problems with the almost purely horizontal approach that the PlaysForSure device makers and music services have been using. We believe that a successful music platform must specify more of the consumer experience than PFS ever did, as well as the technical components that are used to build that experience. However, we do not believe it’s necessary to build the hardware ourselves or only have one hardware partner. With Rhapsody DNA we have developed a highly specified consumer experience across multiple environments and use cases while simultaneously enabling multiple hardware makers to build differentiated products for on-line and off-line music access. Consider it a balance that is more vertical than PlaysForSure but overtly horizontal compared to Apple.
To create Rhapsody
Now that we've built this API, Rhapsody can be easily extended to other embedded audio systems and solutions without involving a PC at all. The web service API is a cornerstone of DNA.
-- Rob Williams, VP Music Software
The word is finally out! Sonos has released version 2.0 of their system software (http://www.sonos.com). This mind-bending new firmware update enables access to the entire Rhapsody catalog without the use of a PC. Sonos has set a new standard for ease of use. This new release is already garnering incredibly positive reviews- in the words of Walt Mossberg of the Wall Street Journal: this system "pairs up Rhapsody with the elegant Sonos whole-house music system, and it works very well. It is simple, fast and rewarding"
With this release we're also now at liberty to begin publicly speaking about an entirely new set of APIs that are powering Rhapsody experiences for home entertainment as well as web connected experiences. Rhapsody Direct includes a robust set of WSDL-compliant SOAP APIs. As the name implies, these new APIs give you direct access to the Rhapsody servers without requiring the use of the Rhapsody client. What can you expect from these new APIs? Well, the Sonos Version 2.0 is demonstrably fast! Performance is a key benefit. There's also the power of time-to-market. Because these new APIs are WSDL compliant you can simply drop them into your environment and they rapidly adapt to whatever programming language you're using. Do they run on the PC as well? Absolutely, Sonos has also implemented a PC version of their client interface using Rhapsody Direct. Paired with the smart URLs, Rhaplinks and RSS feeds of Rhapsody Web Services, Rhapsody Direct has now provided an entirely new level of developer access points into the Rhapsody music platform and created the foundation for an unparalleled set of new hardware and software music applications.
Over the next few weeks we will be providing detailed documentation around these new powerful APIs. In the interim, we welcome your feedback and congratulations to Sonos for a job very well done!
-- Ben Rotholtz, GM Web Services & Syndication
As part of MusicMob's Rhapsody integration, the company made available a resolver, which converts open standard playlist files called XSPFs so the songs can be played back in Rhapsody. This is very exciting as it allows for an excellent bridge between silent playlists of data and Rhapsody playback. See Toby Padilla's blog entry on the subject for more background.
Lucas Gonze, Webjay creator and XSPF chieftain, penned a nice explanation of MusicMob's integration. Lucas writes:
An important part of the XSPF design is the idea that a playlist entry is not so much an exact locator for a song as it is a collection of metadata that a kind of software called a content resolver can use to locate an instance of the song. For example, you might have a track listing containing nothing but a song title, and the resolver would look up that song title in the MP3s on your hard drive to see if you had it available....
Musicmobs long ago shipped software that allowed you to do this relative to the iTunes store; what they have done here is allow you to use Rhapsody's catalog.
MusicMobs' work is an excellent example of creating a consumer-focused product, but also having an eye on making an impact in the echosystem. Users of competing services such as Last.fm, which enable sharing playback preferences and playlists, will now be able to use MusicMobs to not only share the data of the songs, but the actual songs--played in full length and full quality with Rhapsody. It's an example of how developing in an open manner on open standards will strengthen your business, not diminish your differentiation. The availability of this tool will no doubt serve MusicMobs well in marketing to the technoaudiophiles who may not have been aware of their service.
--Dave Hanley
The playlist sharing community MusicMobs just launched their site with Rhapsody playback of all their playlists. There are thousands of playlists that you can peruse and play. The site matches that playlist with Rhapsody via the Data.xml API and plays back all available songs in the Rhapsody Web Player. Toby had this to say about Rhapsody:
"Lately we’ve been pretty excited about Rhapsody. We’ve always wanted to provide a way to open playlists into a music subscription service but until now, no APIs were mature enough. The new Rhapsody Web Services API offered a great way to link into their service and play the majority of the songs in any playlist on the web." (MusicMobs Blog)
To play songs, simply pick a play list, then find the play button 
with the Rhapsody logo.
That's where the magic really happens.
At that point a new browser window will open and an a little animation with entertain you while MusicMobs matches the songs in the play list with the Rhapsody Content IDs. The application first looks to see what matches are available in its data cache, then it starts hitting Data.xml, the Rhapsody REST API, to fill in the gaps (Example Data.xml: Album, Artist). The application seems to match about half of the songs right now, but that will surely improve over time.
Once the songs are matched, playback starts in the same window.
I know MusicMobs has even more plans for Rhapsody integration in his site, so we'll watch for that. In the meantime, enjoy this great site and find some new music.
--Dave Hanley
We are proud to announce the two winners in the first round of the Rhapsody Web Services Contest. We thank all of you who entered the contest and look forward to seeing how your sites and applications continue to grow and change. Both winners will receive a SanDisk Sansa e260 mp3 player with a six-month Rhapsody subscription.
Without further adieu, here are the winners:
Ron Gatewood submitted an Internet Explorer plugin that links text on any web page to Rhapsody.com. Simply highlight any artist or album text on any webpage, right-click and select ‘Search Rhapsody.com’ from the context-menu. The application uses the Rhapsody Search API to find the right match and takes the user to the appropriate page. We’ve been playing around with this and found it a great way to quickly get from a blog posting or album review to playing the content. The more you use it the more useful it seems to be. Congrats Ron.
Brian Greenbaum showed us his Pitchforkmedia+Rhapsody Mashup, which matches the excellent reviews on Pitchfork with Rhapsody Playback and Discovery. You can hear content from the latest reviews, or go back and peruse over 2,000 past reviews. Brian's site scrubs Pitchfork for new reviews, uses Data.xml to determine if the album and artist are available in Rhapsody, then posts the artist, album, and play links on his site. This is a great way to discover new music. Congrats Brian.
A number of you have shown me your works in progress, and there are some truly great web services integrations and mashups going on. So look for more prize announcements next month. Congratulations to these two winners. Enjoy your swag.
--The Rhapsody Web Services Team
I'm struck this morning by the simultaneous moves to open up and close off data and services to developers. The last few weeks we have seen MySpace's security concerns lead them to shut down outbound links from flash widgets, seriously curtailing the business of third party developers and decreasing the functionality of their ecosystem. One must assume that MySpace has learned the ills of erecting walls around one's garden from the likes of AOL, so hopefully these restrictions will be short lived. I'm guessing them will rectify the situation shortly.
Kudos this week go to Facebook, which in my opinion was the most closed of all of the social network sites until most recently. In fact, being insular was their initial point of differentiation--providing access to profiles only to classmates and their friends. Last week Facebook announced a developers program, which should provide an interesting platform for college projects and even for-profit businesses. I can picture that one lurpy guy with the too-high pants developing the newest fashionable way to hook up using Facebook. We'll see.
The APIs allow access to a fair amount of data, but the social network site is obviously doing its best to protect its data from being siphoned off and used outside of its system. This challenge is faced by all holders of proprietary information. We see the benefit of distributing the information widely in order to reinforce our networks and to create greater value to our customers as they utilize the information in ways they choose. But there is fear that the data will simply slip away into nefarious hands, or that the value of the data to the service will dissipate as it becomes broadly available on the web.
So it is up to the content rights holder to make the decision whether or not to be open, or how to structure their openness as they walk this line. We have had several debates on the Rhapsody team about this subject, weighing the power of the incredible editorial content cultivated over years of work and the desire to support of developers. So far we have decided to err on the side of being open, and I believe that will continue. While there will be some small bits that we will have to hold back due to licensing issues or copyright concerns, but we're working on getting in your hands all the tools that will make your applications better.
So in that spirit, tell us what you want, and we'll try to oblige.
--Dave Hanley
Today we announced the Rhapsody Web Services contest, where we'll give away lots of prizes, including a trip to see any artist anywhere in the world, a Sonos system with Rhapsody subscription, and lots of Sansa e260 mp3 players with Rhapsody subscriptions.
The big winners will be announced at Web 2.0, and we'll be giving monthly prizes as well. So dust off those good ideas and build something unique. We'll promote it on the new Rhapsody Web Services site, and you could get some nice swag.
It looks like Richard MacManus is the first to review the contest. Check out his postings at Read/Write Web and ZDNet.
Update: John Musser just posted his thoughts on Programmable Web.
Some of you may have already noticed Rhapsody playback on RollingStone.com. But now there's a whole new way to mash up the sites yourself.
If you check out one of Rolling Stone's artist feeds (which you'll find just below the artist's picture on the artist pages), you'll notice that the IDs used for each artist on Rolling Stone are the same as those in Rhapsody Web Services. The feeds contain news about the artist.
So try mashing up their news with our playback and data in your own way. Then tell us about it.
--Dave Hanley
Some of you may know SIGamp, which is a service that allows you to display what you're listening to on any page.
Here's the process:
The SIGamp plugin observes your playback on Rhapsody.com and uploads it to their service
You grab an image to embed on your blog, email signature, or space, and you're done.
Windows only, so my SIGamp will usually be blank. But yours may not...
I'd love to see an upgrade, which pulls the album art from data.xml and displays it in the SIGamp. Heck, we'll even be ecumenical and suggest you put those images on songs played by Yahoo! and iTunes. We're just that way.
--Dave Hanley
I saw this a couple of months ago, but didn't blog about it. Brian Greenbaum did a great mashup that matches Pitchfork's fine reviews with Rhapsody playback. The site contains a list of more than 1700 albums with links to the pitchfork review and to Rhapsody.com to play it.
It appears that the site either looks up the album using data.xml or simply builds the Play Link, and verifies that it resolves to a playable album. Either way, very cool.
I ran into this great gadget that you can add to your Google or Live.com pages, and presumably to MySpace if you had a use for it there. LabPixies takes Rhapsody's top album and track feeds and makes a nice flash interface for it, utilizing the album art. Very cool.
Check it out:
LabPixies Rhapsody Top Feeds Gadget
--Dave Hanley
We've just launched a set of widgets and gadgets based on Rhapsody feeds and play links. Use the gadgets to quickly browse Rhapsody's free radio stations, and the top albums in each station's genre. The gadgets are available for Mac Dashboard, Yahoo! Widgets, Live.com, and Google.com/ig.
Try one of the following:
For Live.com and Google.com/ig, add this URL to your page.
Today Programmable Web has Rhapsody Web Services listed as their featured API. And we got five stars to boot! Thanks to PW for helping get the word out.
So who's going to post the next music mashup?
This isn't really about webservices, but it is about building cool websites. Sometimes developers face that classic "good problem" that their site is more popular than their server(s) can handle. Some of you might have noticed that we ran into this recently issue recently and I'd like to share with you what we did about it.
First, a little background on our server architecture. www.rhapsody.com points to a load balancer that distributes page requests amongst a set of identical app servers. The app servers try to serve content out of their local caches and if the content they need isn't there, they look it up in a shared database. All very standard.
Our particular issues start with the fact that the entire rhapsody catalog is too big to fit into the cache space that our app servers can use. It takes an order of magnitude or two longer to serve pages out of the database than from one of the local caching layers. The result has been that popular content which is in cache gets served pretty fast and less popular content gets served much slower. Adding more app servers to the farm helps to a certain extent, but at some point the database gets maxed out and adding more app servers doesn't help at all or even makes things worse. We could add more read-only database instances and replicate, but there's a better solution.
Load balancers often are configured to use "session affinity" whereby a particular user/browser-session always gets routed to the same server so that server-side session information is preserved. In our case, there is very little user-specific information on our pages -- the catalog content is the vast majority of the pages and also the performance bottleneck. So instead of session affinity we enabled a kind of load balancing that seems obvious, but based on my reading of the literature I don't think is very common. You could call it "content affinity" or I think a more descriptive term is "URL affinity." Instead of binding a session to a particular server, we bind URLs to servers.
This means that every time somebody asks for the hoobastank page, it goes to the same server. So now instead of every server on the farm trying to cache hoobastank's data, we have just one place. (Actually a couple -- I'm simplifying things a bit.) Even better, because of our friendly URL mechanism, it's easy for the load balancer to send all hoobastank traffic to the same server -- their artist pages, album pages, etc. So when we cache the hoobastank object on the app server, we get to use that for all of their pages. Thus each of our app-server caches is responsible for less content, and gets more efficient for the content it is responsible for. Moreover, as we add more servers to the farm, the cache efficiency increases. As our caches get more efficient, database load goes down, as does page load time. Ahh, scalability. It's beautiful.
I'm posting this primarily because I'm hoping some of you will find it useful. I've read a number of books on the subject, and none of the ones I've found talk about this kind of content caching problem. I'm looking forward to reading Cal Henderon's new book on scalable web sites as I bet he's had to address these issues on flickr.
I'm not posting asking for advice on how we should have done things or what's wrong with this system. I understand full-well that this isn't ideal for a lot of reasons. But it works pretty well for what we need right now. A more sophisticated architecture would do essentially the same thing but with a dedicated data caching tier behind the web application tier. That gives you the ability to scale multiple types of content, e.g. catalog content and user-specific content. But we're actually going to move that functionality down to the browser. Stick around and you'll see what I mean.
-Leo Parker Dirac
Hey everybody! Check out our new site:
http://webservices.rhapsody.com/
Sign up as a registered Rhapsody Web Services Developer. You'll get access to a brand new version of the SDK and discussion forums and all sorts of great stuff. Once we clean up the design, we'll be switching the main links over to it. In the meantime, look for more posts about the cool new web services we've been adding.
-LPD
A friend pointed me to Slide.com, which is a great free service for sharing photos on MySpace, blogs, or wherever you want to express yourself. The slide shows have an elegant, slick design, which I find very appealing. But the best part is one of their relatively unpublicized services: an RSS-to-slide-show converter, which allows us to dump in our album listening history feeds and get this slide show. The album covers of the music you're listening to just float on by. When a visitor is curious about the album he can mouse over to see the album info and click to play the album. You can mod it by changing variables such as size, scrolling direction, etc.
To set up your slide show, do the following:
Kudos to Slide.com for creating such a cool service.
Check out Rhapsody.com. Look down at the bottom each page. On the right side. There it is. Orange RSS buttons at the bottom of each page. Rhapsody's RSS feeds are officially open to the public. It's not just for blog-readers anymore.
That's all.
-LPD
As we expand the scope of Rhapsody Web Services, we've come to realize that the single numeric space that we've been using to identify content isn't broad enough for all the kinds of data that we use. And it's been confusing to boot. For example, artists, albums and tracks have all shared one numeric space, but genres have had their own space. We've got an answer that will let us grow far into the future, but unfortunately it might require a few code changes for existing applications.
RCID values take the following format: an alphanumeric string moniker followed by a period and then an identifier which is unique within the namespace defined by that moniker. How about a few examples?
The "g." identifies it as a genre and the numeric portion identifies which genre. How about artists? They start with "art."
Note that 299 can be either the rapper Redman or the genre Jazz depending on the moniker. For example:
http://www.rhapsody.com/artist?artistId=art.299 redirects to http://www.rhapsody.com/redman
and
http://www.rhapsody.com/genre?genreId=g.299 redirects to http://www.rhapsody.com/jazz
As I've said, albums, artists and tracks share a namespace and won't collide, but with the new system you really won't notice. For completeness, here's a list of monikers you'll be seeing:
You'll be seeing more of these as we expand the scope of the API. But for now that's all we need. These new RCID types are now live across the site. Enjoy!
-LPD
Why does the world need XSPF? Playlists are linear lists of items. I think RSS covers this need pretty well, and is already supported by a huge range of apps. Especially when you consider the custom data fields in RSS 2.0, what is the value of XSPF? Are these extra metadata so important that we need a whole new XML format? Can't we just standardize on some extra RSS tags? What do you think?
Check out this awesome mashup that Adam Phillabaum made combining Rhapsody Web Services and Google Calendar:
http://borrowr.com/~adam/mashup/
You can book music to listen to in your google calendar. Pick an artist and an album and make a calendar entry and open this mashup. It can work as an alarm clock with any music you want. Now all it needs is a pretty javascript clock and a snooze button. Note that v1 is firefox only.
Featured on programmable web as the mashup of the day. Keep 'em coming!
-LPD
Something's running through my head that I'd like a little feedback on from the community. At some point we want to give you the ability to customize the look and feel of the Rhapsody Web Player. I see a couple of different technologies that can enable this. I'm wondering what folks think gives the best balance of power and ease of use.
One way is put all colors and images and layout information into CSS and enable devs to override our CSS with their own. This would let you change colors, adjust fonts and sizes, replace images, move parts around, and even hide components that you don't want. But the hidden components would still have all the code overhead of maintaining them -- our js code would still update them, but the user just wouldn't see them. Certainly not the end of the world, but a little slower than it needs to be. But computers are fast, right? I see this way offering a great deal of flexibility while staying accessible to a large number of web developers.
A more powerful way is to build the player display components in DHTML entirely in javascript. Start with a blank page with a bunch of empty <div> tags with appropriate names like "albumart" and "volumecontrol" and "playbutton". Then our js code would find the divs and fill them with display/control UI as appropriate using the DOM or .innerHTML. Devs could move the <div> tags around on the page or omit ones that they didn't need. The reason I see this as more powerful is that we'd set up each class of js code to render a display component so that it could be sub-classed and replaced by your own control which not only looks different but behaves completely differently as well. This is arguably slower to load than a straight HTML version. Another distinct advantage is that this way you can actually remove display components that you don't want, as opposed to just hiding them. Harder to do, but ultimately more flexible.
Comments?
-LPD
I'd like to take this opportunity to offer our friends at Napster a musical welcome to the World Wide Web. At the same time I'll introduce a new web services technology that I expect many of you will find useful.
We have a simple URL format that lets you create instant playlist pages from a list of RCID values for tracks. This is the URL equivalent of calling the simple.js function RhapsodyPlayer.playTrack(...) with an array of tracks. It allows you to publish and share Rhapsody playlists without having to write the playlist into our database. I think one sample URL will explain everything about how it works:
Which opens this playlist:
Welcome to the World Wide Web, Napster. We're glad you're here.
-LPD
I spent the weekend at Seattle Mindcamp 2.0 and had a blast! Props out to Andru and Stuart and everybody else who helped make it happen. This was much better than the first one and I can't wait for 3.0.
It was great to get a chance to meet and talk to a bunch of smart creative passionate geeks about music web services. People who get it. People who care. People who want to put music on their websites but are frustrated by legal and logistical restrictions. I met a lot of people like this who understood how Rhapsody Web Services can solve their problems. Of course they had questions and concerns, and I just hope that I was able to address them satisfactorily. If not, y'all know how to get a hold of me.
We had some great discussions about mashups. We talked about mashing Rhapsody Web Services up against flickr, craigslist, del.icio.us, ticketmaster, S3, laszlo, even skype and google talk. My favorite idea though was a Rhapsody/Google Calendar mashup to build an alarm clock that plays your favorite music at a specified time. I'm really looking forward to that going live.
Also thanks to Dave Winer for opening my eyes to how we could use OPML for exposing meta-data.
Looking forward to Mindcamp 3.0...
-Leo Parker Dirac
I'm happy to share with you a new API for playing music on your site. We call it simple.js, because that's where you find it: http://www.rhapsody.com/simple.js. This API lets your web pages trigger music playback without requiring your visitors to leave your site. In places where you can include javascript, simple.js will start a track or album playing in the web popup player window without navigating off your page. Much like a RhapLink, it will re-use an existing web popup player window if it's already open, or open a new one if needed. Plugin detection/install and login are all handled for you. As the name implies, a goal of simple.js is to be as simple to use as possible. Consider this example:
<script src="http://www.rhapsody.com/simple.js" />
<a href="javascript:RhapsodyPlayer.playTrack(2899985);"> Listen to Cake's "Stickshifts and Safetybelts" on Rhapsody.com</a>
Which renders as:
Pretty straightforward, eh? The only tricky part is finding the RCID value of the track, in this case 2899985. We've been working hard to remove obscure database IDs from the site, and they're almost completely gone fom the URLs. But you can find them in the RSS feeds. In this case, open http://feeds.rhapsody.com/cake/fashionnugget/tracks.rss and look at the <guid> field -- that's the RCID value you need to pass to simple.js. We've got some other ways to find RCIDs in the works that you'll hear about soon.
As always, feedback on the API is most welcome.
-Leo Parker Dirac
We've got a new tool for generating RhapLinks. It also generates HTML codes for inserting into web pages, blog templates or social networking profile pages. It's not launched yet, but we'd love to get your feedback anyway. Check it out at http://www.rhapsody.com/rhaplinkTool and let us know what you think.
-LPD
Recent Comments