The NFL (http://www.nfl.com) is looking for great software engineers to help build out its fan facing web, mobile and backend services. The NFL properties see hundreds of millions of users worldwide and its mobile applications are installed on tens of millions of devices.
We are primarily hiring iOS, Android, Web and Backend engineers (with a lean to people with an interest in full stack development). Currently we are building (and rebuilding) a lot of our core architecture. Our new iOS app is written entirely in Swift, our Android application using RxAndroid and our new web platform is based on React.js. On the backend we are in the middle of rebuilding many of our services experimenting with different technologies generally with an eye on immutable data and functional programming. We are very comfortable relocating talented people to Los Angeles.
If you are interested, please email me at todd.berman@nfl.com
The NFL (http://www.nfl.com) is looking for great software engineers to help build out its fan facing web, mobile and backend services. The NFL properties see hundreds of millions of users worldwide and its mobile applications are installed on tens of millions of devices.
We are primarily hiring iOS, Android, Web and Backend engineers (with a bit of a lean to people with an interest in full stack development). Currently we are building (and rebuilding) a lot of our core architecture. Our new iOS app is written entirely in Swift, our Android application using RxAndroid and our new web platform is based on React.js. On the backend we are in the middle of rebuilding many of our services experimenting with different technologies generally with an eye on immutable data and functional programming.
If you are interested, please email me at todd.berman@nfl.com
The NFL (http://www.nfl.com) is looking for great software engineers to help build out its fan facing web, mobile and backend services. The NFL properties see hundreds of millions of users worldwide and its mobile applications are installed on tens of millions of devices.
We are primarily hiring iOS, Android, Web and Backend engineers (with a bit of a lean to people with an interest in full stack development). Currently we are building (and rebuilding) a lot of our core architecture. Our new iOS app is written entirely in Swift, our Android application using RxAndroid and our new web platform is based on React.js. On the backend we are in the middle of rebuilding many of our services experimenting with different technologies generally with an eye on immutable data and functional programming.
If you are interested, please email me at todd.berman@nfl.com
The NFL (http://www.nfl.com) is looking for great software engineers to help build out its fan facing web, mobile and backend services. The NFL properties see hundreds of millions of users worldwide and its mobile applications are installed on tens of millions of devices.
We are primarily hiring iOS, Android, Web and Backend engineers (with a bit of a lean to people with an interest in full stack development). Currently we are building (and rebuilding) a lot of our core architecture. Our new iOS app is written entirely in Swift, our Android application using RxAndroid and our new web platform is based on React.js. On the backend we are in the middle of rebuilding a lot of our services experimenting with a lot of different technologies generally with an eye on immutable data and functional programming.
If you are interested, please email me at todd.berman@nfl.com
As the guy who wrote the first bits of the Rdio code in question, it seems worth mentioning that the part in question has nothing to do with Backbone, or Ember, or anything else. That code is a cleanup function on an object that helps to abstract HTML5 <audio> vs our Flash fallback.
No matter what framework you are using, if you are solving the problems that we are solving, you are going to end up with that code.
Now, that said, I agree that learning all of the frameworks out there is advantageous, but you can't assume that the code in the blog post is indicative of anything having to do with Backbone or any other framework.
Is this entirely true? Clearly cleanup of event names like "loadedmetadata" is related to the audio element but '_bubbleProfilingEvent', '_logEvent', and general .unbind calls are on backbone-related objects, yeah?
The only backbone related code in that snippet is the .unbind() call and the .trigger call. This is needed because this is our wrapper around the media element; it is an event emitter. If you're going to make something emit custom events, you'll need code to emit them and clean them up when you're done.
One area where backbone is lacking is lifecycle management. You do sometimes have to unbind things in order to prevent leaks. Backbone is very minimal in this regard. At Rdio, we've built our own tools on top of Backbone to abstract lifecycle away from the developer as much as possible. That being said, that weakness isn't illustrated in the code example picked by the blog post.
Thanks for the comment. Before reading it, I admit to being lured into thinking the code in TFA was there to clean up after Backbone. Sneaky bit of writing...
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).
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.
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.
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 resource needs to be deleted.
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.
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.
Agreed that it is possible, but it sucks to implement for the developer, which is Ian's original point. Its absolutely possible to do it, but we felt it was suboptimal, and opted to do something else.
Urm, I thought I was agreeing that it's not possible. But I think we're in agreement.
In short: you want to offer functions on the server that REST would push on to the client (or would require making architectural changes).
REST definitely requires a larger upfront investment vs RPC. Part of what I'm curious about is how much larger in real world cases, and this is a good example. So I appreciate you taking the time to respond.
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.
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.
The NFL (http://www.nfl.com) is looking for great software engineers to help build out its fan facing web, mobile and backend services. The NFL properties see hundreds of millions of users worldwide and its mobile applications are installed on tens of millions of devices.
We are primarily hiring iOS, Android, Web and Backend engineers (with a lean to people with an interest in full stack development). Currently we are building (and rebuilding) a lot of our core architecture. Our new iOS app is written entirely in Swift, our Android application using RxAndroid and our new web platform is based on React.js. On the backend we are in the middle of rebuilding many of our services experimenting with different technologies generally with an eye on immutable data and functional programming. We are very comfortable relocating talented people to Los Angeles.
If you are interested, please email me at todd.berman@nfl.com