Rdio: No REST for the wicked
developer.rdio.com
Rdio: No REST for the wicked
1–10 of 29 posts
Re: Rdio: No REST for the wicked
#2our API, like most of the popular "REST" APIs, is not REST as defined by Roy Fielding
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.
Re: Rdio: No REST for the wicked
#3I 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".
Unfortunately, the vernacular meaning of the word REST is "not SOAP".
Re: Rdio: No REST for the wicked
#4our API, like most of the popular "REST" APIs, is not REST as defined by Roy Fielding 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.
How is it any more inaccurate than: http://www.flickr.com/services/api/request.rest.html
Re: Rdio: No REST for the wicked
#5our API, like most of the popular "REST" APIs, is not REST as defined by Roy Fielding 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.
How is it any more inaccurate than: http://www.flickr.com/services/api/request.rest.html
Not to brag, but at least the Rdio API doesn't allow non-idempotent calls over GET.
Re: Rdio: No REST for the wicked
#6I 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". Unfortunately, the vernacular meaning of the word REST is "not SOAP".
Jens Alfke suggested PEST - Post Everything STyle:
http://jens.mooseyard.com/2011/03/dudes-this-is-so-not-rest/...
Re: Rdio: No REST for the wicked
#7When 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.
Hi Ian, if it's not too much trouble could you give an example of functionality that didn't work well with REST?
Re: Rdio: No REST for the wicked
#8If you are interested in music related APIs, my company (http://www.audiogalaxy.com) 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.
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
Re: Rdio: No REST for the wicked
#9When 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. Hi Ian, if it's not too much trouble could you give an example of functionality that didn't work well with REST?
Off the top of my head a couple of things that didn't map well were:
* search
* deleting songs from a playlist (safely)
* multidimentional stats queries (eg: http://developer.rdio.com/docs/read/rest/Methods#getHeavyRot...)
Perhaps we could have modelled these in a REST-like manner, but it seemed simpler to make the functionality available through an RPC protocol - simpler for us to implement and simpler for developers to integrate into their software.
Re: Rdio: No REST for the wicked
#10Kudos to the Rdio team for being responsive and thoughtful rather than defensive.