YottaMusic and the Limits of APIs

John Musser, January 4th, 2008

Web APIs rarely do everything the underlying site or service does. They are typically a defined subset of the total functionality. While understandable from a business strategy and resource perspective, these limits can be frustrating for developers. Sometimes this leads them to find a solution using undocumented APIs, often services used by the UI of the site, that provides them enough functionality to meet their needs (which was essentially the case with the original Google Maps, an undocumented JavaScript API until Paul Rademacher reverse engineered them and built HousingMaps.com).

In a similar vein, there was a bit of stir this week when the small music web site YottaMusic had to shut down because they were no longer allowed to use undocumented Rhapsody APIs. Created in 2006, YottaMusic used these undocumented APIs to build a new web interface on top of the underlying Rhapsody music subscription service. But as TechCrunch reports “This past May, however, Rhapsody contacted YottaMusic and asked them to start using its public APIs exclusively or shut down the service entirely. Since YottaMusic depended on the non-public API for its Rhapsody interface, and since adopting the standard Rhapsody player would have erased most of the application’s value, the startup ultimately felt forced to fold and shut down operations…While founder Luke Matkins says that he understands Rhapsody was perfectly within its rights to take such actions, it’s obviously an unfortunate turn of events for YottaMusic’s 10,000 visitors per day.” The screenshot below is what you see on the site today:

yotta.png

Undocumented APIs are notorious for changing or being removed, thus part of the reason they’re undocumented in the first place. In this case you can learn more in a well articulated TechCrunch comment from Rhapsody GM Ben Rotholtz, who notes that:

Despite progress and refinements over the past two years, our APIs are not exhaustive and unlimited: As was the case with Yotta, the breadth and depth of our APIs won’t match the needs of every developer. Additionally, we have guidelines and terms of use for our APIs to protect the legal reuse of our content and perhaps even more importantly to honor our contracts and obligations with the labels. We simply don’t have the rights to enable every music experience since we don’t own the content that is played through Rhapsody. We do feel strongly – and the market has demonstrated – that it’s possible to create a deep Rhapsody integration that is fully within our terms of use (again, see MOG) and we actively encourage developers to party on our code to create new online music experiences.

And to his point we continue to see new Rhapsody-based mashups get added to our directory here, and at the moment there are 14 listed, including the recent popular entry KEXPlorer.

As a side note, there are exceptions to the APIs being just a subset of a broader site’s service: take for example some of the Amazon services like S3 or EC2, where the API is the service, or the case where the most or all of the service is built on their APIs, as with Flickr and Eventful.

Both comments and pings are currently closed.

4 Responses to “YottaMusic and the Limits of APIs”

January 20th, 2008
at 3:25 am
Comment by: Relying on Others’ APIs » The Productologist

[...] can read their write up and check out other [...]

September 15th, 2010
at 5:46 am
Comment by: liuqingwu

how to get this api?

October 5th, 2011
at 12:32 pm
Comment by: Leonid Mirsky

I think that everyone will agree that it isn’t safe to build your service entirely on an unofficial API, however a more serious problem, in my opinion, is when companies decide to close some functionality of their documented API, and leave the API users with no time to find alternatives.

February 9th, 2012
at 10:45 pm
Comment by: MBT

This practically makes the widget a Social Worm. Unlike many social worms, the “Secret Crush” propagation strategy does not rely on phishing or any sort of user-space

Follow the PW team on Twitter

ProgrammableWeb
APIs, mashups and code. Because the world's your programmable oyster.

John Musser
Founder, ProgrammableWeb

Adam DuVander
Executive Editor, ProgrammableWeb. Author, Map Scripting 101. Lover, APIs.