I think I would probably use a custom override of fetch. Something like this:

fetch: function(options) {
  if (options && options.id) options.url = this.url() + '/' + id;
  return Collection.__super__.fetch.call(this, options);
}

It strikes me that perhaps it would be nice if options was passed to url. That way no override of fetch is necessary.

url: function(options) {
  var url = '...';
  return (options && options.id) ? url + '/' + id : url;
}

Thoughts?

I'm not a big fan of passing the id in the options to fetch, as it's the URL that needs to be changed, which properly lives in the url() function -- really this is just highlighting that collection.fetch() is about fetching the contents of the collection -- not about loading an individual model.

What we really want here is something like:

var holmesBook = Book.fetch("102-hound-of-the-baskervilles");

Right? Or perhaps passing in the entire URL?

For me, specifying an ID doesn't feel that different than specifying a page number - in both cases you're specifying a subset of the collection to load (in fact, I just realized I could even munge up the server side code to check the querystring for the ID as a third approach). But I also get where you're coming from on the intent of collections.

The Book.fetch approach could work too, but URL handling seems a bit tricky. Just passing an ID may not be enough, as a Book could be a resource nested in different parents, so how would you know the URL to construct? So yeah, seems like you'd have to pass a complete URL, or maybe a collection as well as an ID (in my app I generally haven't used urlRoot on models, but have the models inherit their URL from the collection). Of course, if you have to construct the whole URL yourself, then there isn't much difference from my original solution of specify the url on the collection fetch options.

Yep -- let's leave this be. That, combined with the fact that the fetch is necessarily asynchronous, means that you wouldn't have a reference to the complete model until the server came back. At that point, I think you're just as well off writing:

var holmesBook = new Book({id: "102-hound-of-the-baskervilles"});
holmesBook.fetch();

... and either listening for change, or using the success callback.

Again, the big problem with new/fetch approach is the sequencing issue between initialize and parse in the two cases, described in the original post. Not sure if that can be fixed, but if it was that would also solve my problem.