Yes. In this case, it makes an enormous difference. Your application can't just go to rdio/api/1/artist/whatever to look up the tracks for an artist; it has to make a SOAP-style request for the tracks for a given artist. This isn't a style nit.
In trying to prove you wrong and show you how easy it would be to make a similar call with the rdio API, I found out how not easy it would be to make a similar call with the rdio API. :)
No, it's not REST, and it's stupid to call it that, but if you think that posting a few arguments makes something "SOAP-style", I find it hard to believe you've interacted with a SOAP web service recently..
Note: Requiring that the call are OAuth'ed, doesn't affect its RESTness.
It can probably be argued to be: you can't just go to rdio/api/1/artist/whatever, but you can get the exact same thing via RPC calls.
I often think that, via REST APIs and content negotiations, API can become browseable and self-descriptive but I've yet to see any example of such a thing. Furthermore, just because an API is restful doesn't mean it's well-designed, and doesn't mean it has descriptive APIs (the artist's track could just as well be in rdio/api/64D89CAC?q=42, that wouldn't inherently make the API non-restful)
> I often think that, via REST APIs and content negotiations, API can become browseable and self-descriptive but I've yet to see any example of such a thing.
It should be trivial with AtomPub/GData/OData APIs. REST itself is not specific enough for that.
