Sto progettando un'API e la sto consumando anche con Backbone.js. Parte dell'API includerà le operazioni di ricerca. Per esempio durante la ricerca per le auto, potrei avere qualcosa di simile:Come progettare una ricerca REST con backbone
http://api.mysite.com/search/cars?q=volvo
Con spina dorsale, posso vedere due opzioni per consumare i risultati.
Opzione 1: Una ricerca è una collezione
var CarSearch = Backbone.Collection.extend({
model: Car,
initialize : function(models, options){
this.query = options.query;
},
url: function(){
return "http://api.mysite.com/search/cars?q="+this.query;
}
});
var volvos = new CarSearch([], {query:'volvo'});
volvos.fetch();
Opzione 2: Una ricerca è un modello, ed i risultati sono una raccolta
var CarSearchResults = Backbone.Collection.extend({
model: Car
});
var CarSearch = Backbone.Model.extend({
defaults: {
"query":"",
"carSearchResults":null
},
url: function(){
return "http://api.mysite.com/search/cars?q="+this.get('query');
},
parse: function(resp,xhr){
resp.carSearchResults = new CarSearchResults(resp.carSearchResults);
return resp;
}
});
var volvoSearch = new CarSearch();
volvoSearch.set({query:'volvo'});
volvoSearch.save();
Quali sono i vantaggi/svantaggi di queste opzioni ? C'è un modo dorsale per progettare questo?
Sono inclinato verso l'opzione 2 perché sembra più semplice aggiungere elementi alla risposta come i dettagli di impaginazione o un prossimo URL. Ma l'opzione 2 sembra pacchiana in un paio di modi. Ad esempio, dovrei generare un ID sul server per il modello di ricerca quando viene salvato? Non penso di aver bisogno di ottenere quel modello per ID, cancellarlo o aggiornarlo non ha davvero senso, perché non lo sto perseverando.
questo è in realtà la risposta corretta. –