<i>our API, like most of the popular "REST" APIs, is not REST as defined by Roy Fielding</i><p>Other APIs may be imperfect implementations of the ideal, but Rdio's made no attempt to look anything like REST. The complaint wasn't about adhering to a spec, but simply inaccurate nomenclature.
<i>When I started working on the Rdio API I struggled to work out how to effectively expose our API through a more classically REST model, but ultimately there was too much functionality that would be significantly more ugly when forced into a document-oriented REST model than exposed through an RPC model.</i><p>Hi Ian, if it's not too much trouble could you give an example of functionality that didn't work well with REST?
I'm working on an RPC API that works with XML over HTTP. I'll be calling it an XML API. If it did JSON I'd call it a JSON API. Some customers seem to want to call it a REST API, but it would pain me to call it that when it isn't.
If you are interested in music related APIs, my company (<a href="http://www.audiogalaxy.com" rel="nofollow">http://www.audiogalaxy.com</a>) has a draft API that lets you browse and play your music collection remotely. We support mp3, aac, flac, wma, vorbis, and get your playlists out of iTunes.<p>We haven't publicized the API quite yet, but we would love get feedback from anybody who might be interested in it. Send me an email if you are: twk@audiogalaxy.com
REST is totally useless since no one really knows wha it means and there are few if any APIs that come close to being "RESTful". REST's proponents, including Roy, have done a dreadful job educating on what REST is. As I commented on the Rdio thread, it would be nice if the complainers actually suggested how the API in question could be designed more RESTfully.
I like the term POX, except, like AJAX, that has an X that can be mistaken for "XML" although it can also be X for "Unknown".<p>Unfortunately, the vernacular meaning of the word REST is "not SOAP".