While this is correct for cases where you need to access a single ticket, there are two use cases where you need a deeper approach: 1) Entity relationships; ie

While this is correct for cases where you need to access a single ticket, there are two use cases where you need a deeper approach: 1) Entity relationships; ie., one-to-one, one-to-many and many-to-many relationships. For example, if you have a list of Task models, each with a "creator" property that references a User model, then you want to each creator to be loaded only once, and always refer to the same object. Last I checked, Backbone did not support relationships, so this becomes awkward. I solved it in my Backbone 0.5.2 app by preloading the complete /users collection; then for each Task model, I looked up the creator_id attribute in that collection. Luckily I don't currently have many relationships to juggle, but it's quite brittle and manual at the moment even with just a few. 2) Dynamic resource collections. For example, good REST practice dictates that server-side-filtered collections should be expressed with query strings: /tasks, /tasks?status=active and /tasks?status=completed are three different views on the same logical collection of tasks. For some apps, this kind of filtering can be done client-side; but what when the dataset is too big and the possible set of dimensions (eg., free text) is complex? Then you will need server-side ad-hoc querying. I haven't solved this one yet, and currently do some manual reloading whenever data changes, in order to keep collections in sync. But in my opinion, in order to solve this one, you will need an identity map solution. Unfortunately, Backbone's code seems to have been structured not for OO cleanness, but for size. It's all pretty tangled and ad hoc, and not really designed for extensibility. (I haven't looked at the code for prateekdayal's code, perhaps it can be accomplished cleanly.)