Question

In Backbone, it seems to be encouraged that collection resources return bare arrays. This seems to be driven by the Rails model of doing things, which isn’t a good reason at all to do something. I have a few problems with this:

1. Often, a ‘collection’ resource also needs context around it. At the very least, I like the convention of including the URI of the resource in the response. Other things, like paging, subtotal (in a shopping cart, for example), etc. mean that collections are rarely “bare”.
2. Bare Arrays supposedly have security issues. I’ve heard this in a few places, but need some references to confirm it.

On the other hand, I can see how “bare” arrays would make an API more natural:

1. The format of each object in the collection would tend to be the same as the format when creating/updating an object in that collection.
2. A ‘collection’ semantically maps well to the idea of, well, a collection of items.

Disclaimer: the premise here may be totally flawed. I realize that REST is about much, much more than HTTP Verbs and JSON.

Answer 1

The security issue you cite is a CSRF vulnerability caused by the fact that JSON arrays requested by script includes can be evaluated by overriding the native javascript Array type. Here’s a good explanation of the vulnerability. AFAIK, this is not possible with plain JSON objects.

However, Backbone doesn’t stop you from wrapping your collection responses. You can override Backbone.Collection.parse to “unwrap” or otherwise modify the raw response before the collection is populated.

var MyCollection = Backbone.Collection.extend({
  model:MyModel,
  parse: function(response) {
    //Assume the response looks like { "data": [ ... ] }
    return response.data;
  }
});

I typically prefer to wrap the collection responses, not only for security reasons, but also because it allows for greater flexibility and change-resilience in the API.