5 ms·

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:

by ianloic 16y ago

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#getHeavyRotation 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.

DougWebb 16y ago
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 they're not being used to specify which collection resource to retrieve. They're being used to alter the representation of the collection. This is just like using start and count query parameters to allow paging through a large collection. For your search, you would use a single query parameter, and for getHeavyRotation you would use one parameter for each field you can filter on. They'd be optional of course, and if none are specified you get the whole collection. Regarding deleting songs "safely", I'm not sure what you mean but I'm guessing you want some confirmation or recovery. I assume each song has a playlist attribute; instead of allowing a DELETE method on the song I would have a trashbin playlist, and allow the song resource to be updated with the playlist attribute changed to the trashbin uri. That allows the songs to be recovered if they are moved by mistake. To really clear it out, you could allow DELETE on /{trashbin uri}/{song id}. Eg: the song resource can only be deleted via the trashbin.
- tberman 16y ago
  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 /{trashbin uri}/{song id} doesn't provide 2 of the 3 required bits of information, and DELETE /playlist/{playlist id}/{song id}/{index} isn't very RESTful (imo).
  - smhinsey 16y ago
    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.
    - generalk 16y ago
      I'm confused, why would JSON vs. Atom make a difference in this case? What does Atom get you that you can't also do with JSON?
      - smhinsey 16y ago
        Atom has a well-defined way for expressing the content type of items in a feed. You can do this with JSON but you have to come up with your own system.
    - mnutt 16y ago
      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?
      - smhinsey 16y ago
        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.
  - davidmathers 16y ago
    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 playlist" is a function that could only exist in the client. Search on the other hand is just search. I don't think REST vs RPC has much to say about it. The only issue would be location: URL vs method.
megaman821 16y ago
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)

by ianloic 16y ago

DougWebb 16y ago

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 they're not being used to specify which collection resource to retrieve. They're being used to alter the representation of the collection. This is just like using start and count query parameters to allow paging through a large collection. For your search, you would use a single query parameter, and for getHeavyRotation you would use one parameter for each field you can filter on. They'd be optional of course, and if none are specified you get the whole collection. Regarding deleting songs "safely", I'm not sure what you mean but I'm guessing you want some confirmation or recovery. I assume each song has a playlist attribute; instead of allowing a DELETE method on the song I would have a trashbin playlist, and allow the song resource to be updated with the playlist attribute changed to the trashbin uri. That allows the songs to be recovered if they are moved by mistake. To really clear it out, you could allow DELETE on /{trashbin uri}/{song id}. Eg: the song resource can only be deleted via the trashbin.

tberman 16y ago
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 /{trashbin uri}/{song id} doesn't provide 2 of the 3 required bits of information, and DELETE /playlist/{playlist id}/{song id}/{index} isn't very RESTful (imo).
- smhinsey 16y ago
  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.
  - generalk 16y ago
    I'm confused, why would JSON vs. Atom make a difference in this case? What does Atom get you that you can't also do with JSON?
    - smhinsey 16y ago
      Atom has a well-defined way for expressing the content type of items in a feed. You can do this with JSON but you have to come up with your own system.
  - mnutt 16y ago
    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?
    - smhinsey 16y ago
      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.
- davidmathers 16y ago
  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 playlist" is a function that could only exist in the client. Search on the other hand is just search. I don't think REST vs RPC has much to say about it. The only issue would be location: URL vs method.

megaman821 16y ago

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)