4

I asked a question a while back i.e. "How save an entire backbone collection?". However what intrigues me is that why is a save method not offered? Is it unRESTful to save (PUT/POST) entire collections or is it uncommon to do so in the REST-land?

GET:  /MySite/Collections - allowed by collection.fetch()
POST: /MySite/Collections - for the model(s) in the collection to be Posted when calling model.save()
PUT:  /MySite/Collections/{id} - for the model(s) to be updated individually
GET:  /MySite/Collections/{id} - to fetch an individual model throuth model.fetch()

So why not allow for POST/PUT an entire collection of resources? It is convenient sometimes and although one can wrap/hack out some code using collection.toJSON why not include it? I'm just curious about its absence and the rationale for the same. Frameworks not having the capability of a few things usually implies bad programming/design and are thus left out. Is saving an entire collection 'bad practice'?

Community
  • 1
  • 1
PhD
  • 11,202
  • 14
  • 64
  • 112

1 Answers1

3

The wikipedia article about REST does mention CRUD verbs for collection.

But, in my opinion, a Collection is not a resource, it is not an entity, and it has not state. It is, instead, a bunch of resources. And if there would be an UPDATE command for a Collection it would be nothing else but a multiple UPDATE commands over multiple Models. Having the possibility of multiple UPDATE commands in only one request would be helpful but I think this is not a job for the REST implementation.

Also there will be problems of ambiguity, for example in a Collection that contains already saved Models with id and so on, and others that not, what will a POST command mean?... or an UPDATE command?...

No talking about the increase of the complexity in the server side where, if this Collection REST support should be taken like standard, we should to work the double to accomplish the casuistic.

Summarizing: I don't see any case where the need of a Collection REST command can't be solved with the actual, simpler, only-Model REST commands, so keeping the things as simple as possible I think is a good habit.

fguillen
  • 36,125
  • 23
  • 149
  • 210
  • 4
    I beg to differ. For example an *album* (songs/pics) is a legitimate collection/resource! The REST verbs make perfect sense on an album. Although internally they maybe per song/pic/element, that's a different issue altogether. – PhD Aug 05 '12 at 21:12
  • 1
    Agreed, overwriting an album is deleting/creating individual elements in bulk but that is the intent IMHO. So if I have /Album/{item-id} in theory I should have all verbs supported on each of the elements in the URL hierarchy and they should make sense. – PhD Aug 05 '12 at 21:14
  • @PhD in your example _Album_ has a behavior closer to a Model than a Collection, it has state (attributes), _name_ and _year_ for example, this is because it looks proper to have REST verbs. It differs from a common Backbone.Collection. – fguillen Aug 06 '12 at 12:07
  • And how does it differ from Backbone.Collection? Maybe I'm misunderstanding something... – PhD Aug 11 '12 at 20:56
  • @PhD an Album would a model that has a Collection property, when saving this "Model", you really only save the attributes, and then modify the collection elements independently. – hnafar Feb 18 '13 at 17:55