Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rdio: No REST for the wicked

developer.rdio.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Rdio: No REST for the wicked

#21

Post by davidmathers »

generalk wrote: post #16
davidmathers wrote: post #15

Earlier quoted context omitted.

DELETE /playlist/{playlist id}/{song id}/{index} isn't very RESTful (imo) Your opinion is a fact, imo. Songs can't be deleted from playlists using REST, full stop. Songs-in-playlists are values, not identities, so they can't be resources. I see it as analogue to words in a text file. A REST client would have to construct the updated playlist value and PUT the whole thing to the playlist resource. So "delete song from…

> Your opinion is a fact, imo This doesn't parse very well to me. As far as your main point, I disagree. The /playlist/:playlist_id/:song_id/:index thing doesn't seem very good, no. But, if you kept an id that mapped songs to playlists, you could easily do DELETE /playlists/:playlist_id/:song_playlist_id and be done with it. REST doesn't say you have to update the entire resource just because a member of that resourc…

I agree with you hypothetically. But my question was about their real world issues.

They could, in theory, have ids for songs-in-playlists. But they don't in fact have them and their RPC api doesn't require them. That's what I'm interested in. Not how they could change their architecture to make REST work.

Re: Rdio: No REST for the wicked

#22

Post by megaman821 »

ianloic wrote: post #9
davidmathers wrote: post #7

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. 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 develope…

search - I have always used query strings, since it will return a subset of some resource.

deleting songs from a playlist - the way it is worded makes you think you should use DELETE but if I said, deleting words from a blog post you wouldn't think of using DELETE. Use PUT for this operation.

multidimensional stats queries - this one is hard if you don't create some umbrella resource that contains the possible resources that may be returned (and most likely I would just make it multiple calls instead of one)

Re: Rdio: No REST for the wicked

#23

Post by mnutt »

smhinsey wrote: post #14
tberman wrote: post #13

Earlier quoted context omitted.

Given then, how would you map a search that returns multiple types? As far as deleting songs "safely", what Ian means is that for any given playlist (of which a user has an unlimited number) any given song can be in it any number of times. So when you delete a song, we generally ask for song_id and index to make sure that a) the playlist hasn't mutated (much), and b) we are dropping the right song. The DELETE on /{tr…

A search with multiple return types is a good question when the results are JSON, but if the result is something like Atom, it's not really an issue at all because each entity in the resulting feed can contain its own type descriptors. Unfortunately it's since been replaced by a new CMS after I left several years ago, but the search for newsweek.com used to work like this.

The larger problem I see with regards to REST is: what resource are you hitting that would give you multiple types? Meta resources like /media, /things, etc aren't ideal; is there a better way to do it?

Re: Rdio: No REST for the wicked

#24

Post by smhinsey »

mnutt wrote: post #23
smhinsey wrote: post #14

Earlier quoted context omitted.

A search with multiple return types is a good question when the results are JSON, but if the result is something like Atom, it's not really an issue at all because each entity in the resulting feed can contain its own type descriptors. Unfortunately it's since been replaced by a new CMS after I left several years ago, but the search for newsweek.com used to work like this.

The larger problem I see with regards to REST is: what resource are you hitting that would give you multiple types? Meta resources like /media, /things, etc aren't ideal; is there a better way to do it?

I am not sure that this is the canonical approach, but the way I did it was to model my search index as the resource. Requesting it with no parameters returned the entire index in its natural sort. Additional parameters filtered/sorted/paged/etc.

Re: Rdio: No REST for the wicked

#25

Post by garethr »

tberman wrote: post #4
TillE wrote: post #2

our 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

It's not. But that doesn't make either of them right. I called Flickr on this 3 years ago before anyone actually visited my blog: http://morethanseven.net/2008/02/21/sorry-but-the-flickr-api...

Re: Rdio: No REST for the wicked

#26

Post by rue »

davidmathers wrote: post #15
tberman wrote: post #13

Earlier quoted context omitted.

Given then, how would you map a search that returns multiple types? As far as deleting songs "safely", what Ian means is that for any given playlist (of which a user has an unlimited number) any given song can be in it any number of times. So when you delete a song, we generally ask for song_id and index to make sure that a) the playlist hasn't mutated (much), and b) we are dropping the right song. The DELETE on /{tr…

DELETE /playlist/{playlist id}/{song id}/{index} isn't very RESTful (imo) Your opinion is a fact, imo. Songs can't be deleted from playlists using REST, full stop. Songs-in-playlists are values, not identities, so they can't be resources. I see it as analogue to words in a text file. A REST client would have to construct the updated playlist value and PUT the whole thing to the playlist resource. So "delete song from…

I wish people'd stop using explicit URLs to describe what's REST an what isn't. “Pretty” URLs are incidental, at best.

I'm not certain DELETE is completely inappropriate here[1], but if you feel strongly about it, probably the best/REST way to “delete” a song from a playlist would be to PUT the playlist without the song included.

[1] It is just an ordered list of songs, after all.

Re: Rdio: No REST for the wicked

#27

Post by AffableSpatula »

davidmathers wrote: post #21
generalk wrote: post #16

Earlier quoted context omitted.

> Your opinion is a fact, imo This doesn't parse very well to me. As far as your main point, I disagree. The /playlist/:playlist_id/:song_id/:index thing doesn't seem very good, no. But, if you kept an id that mapped songs to playlists, you could easily do DELETE /playlists/:playlist_id/:song_playlist_id and be done with it. REST doesn't say you have to update the entire resource just because a member of that resourc…

I agree with you hypothetically. But my question was about their real world issues. They could, in theory , have ids for songs-in-playlists. But they don't in fact have them and their RPC api doesn't require them. That's what I'm interested in. Not how they could change their architecture to make REST work.

if it's a big deal to make that change then their underlying architecture needs a review.

Re: Rdio: No REST for the wicked

#28

Post by DougWebb »

tberman wrote: post #13
DougWebb wrote: post #11

Earlier quoted context omitted.

When I design RESTful APIs, I tyypically wind up with a collection resource for each of my resource types. (This is a common pattern, I think.) Searching and your getHeavyRotation are examples of "GET the collection resource, but filter the resources to include in the list". For this I use the path to identify the collection and query parameters to specify the filtering. Query parameters are appropriate here because…

Given then, how would you map a search that returns multiple types? As far as deleting songs "safely", what Ian means is that for any given playlist (of which a user has an unlimited number) any given song can be in it any number of times. So when you delete a song, we generally ask for song_id and index to make sure that a) the playlist hasn't mutated (much), and b) we are dropping the right song. The DELETE on /{tr…

A search that returns multiple types of resources is just retrieving a representation of a collection resource which can contain multiple types of resources. Canonical example: a typical web page resource is a collection of links to other pages, links to css files, links to js files, links to images, etc.

Each item in the list is going to have a URI for the item, probably some text that briefly describes the item, and if necessary it can have a value that identifies the type of item.

If I'm understanding correctly, your playlist resource is an ordered list of song identifiers, the song identifiers can appear more than once, and when you "delete a song" you're removing a single one of those identifiers. That sounds to me like an update of the playlist resource. The simplest model would be:

GET /playlist/{playlist id} ... client modifies representation ... PUT /playlist/{playlist id}

That's not atomic and it puts some application-logic burden on the client, but you _are_ writing an API to allow others to develop full-featured clients, and maybe the burden also provides flexibility for operations you haven't thought of.

Another approach would be for the representation of the playlist to include a unique id for each item in the list: your song id + index. You're not using a DELETE method here though, because you're not deleting a resource. You would use POST to update the playlist resource:

POST /playlist/{playlist id} operation=removeitem&songid={song id}&index={index}

This is the general RESTful pattern for doing a partial update of a resource, so the client doesn't have to GET and PUT the complete resource.

Re: Rdio: No REST for the wicked

#29

Post by pbreit »

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.
Post reply on HN