Grundsätzlich haben Modelle eine Eigenschaft namens Attribute, die die verschiedenen Werte sind, die ein bestimmtes Modell haben kann. Backbone verwendet JSON-Objekte als einfache Möglichkeit, diese Werte mit verschiedenen Methoden zu füllen, die JSON-Objekte verwenden. Beispiel:
Donuts = Backbone.Model.extend({
defaults: {
flavor: 'Boston Cream', // Some string
price: '0.50' // Dollars
}
});
Um das Modell zu füllen, gibt es verschiedene Möglichkeiten. Sie können Ihre Modellinstanz beispielsweise einrichten, indem Sie eine JSON-Methode übergeben ODER die Methode set () verwenden, die ein JSON-Objekt mit Attributen verwendet.
myDonut = new Donut({'flavor':'lemon', 'price':'0.75'});
mySecondHelping = new Donut();
mySecondHelping.set({'flavor':'plain', 'price':'0.25'});
console.log(myDonut.toJSON());
// {'flavor':'lemon', 'price':'0.75'}
console.log(mySecondHelping.toJSON());
// {'flavor':'plain', 'price':'0.25'}
Dies bringt uns dazu, Modelle zu speichern und sie entweder auf einem Server zu speichern. Es gibt eine ganze Reihe von Details zu "Was ist REST / RESTful?" Und es ist schwierig, das alles hier in einem kurzen Klappentext zu erklären. Insbesondere im Hinblick auf das Speichern von REST und Backbone sollten Sie sich mit der Semantik von HTTP-Anforderungen und dem, was Sie mit Ihren Daten tun, auseinandersetzen.
Sie sind wahrscheinlich an zwei Arten von HTTP-Anforderungen gewöhnt. GET und POST. In einer RESTful-Umgebung haben diese Verben eine besondere Bedeutung für bestimmte Verwendungszwecke, die Backbone annimmt. Wenn Sie eine bestimmte Ressource vom Server abrufen möchten (z. B. das zuletzt gespeicherte Donut-Modell, einen Blogeintrag, eine Computerspezifikation) und diese Ressource vorhanden ist, führen Sie eine GET-Anforderung aus. Umgekehrt verwenden Sie POST, wenn Sie eine neue Ressource erstellen möchten.
Bevor ich zu Backbone kam, habe ich noch nie die folgenden zwei HTTP-Anforderungsmethoden berührt. PUT und DELETE. Diese beiden Verben haben auch eine spezifische Bedeutung für Backbone. Wenn Sie eine Ressource aktualisieren möchten (z. B. den Geschmack von Zitronendonut in Limonendonut ändern usw.), verwenden Sie eine PUT-Anforderung. Wenn Sie dieses Modell insgesamt vom Server löschen möchten, verwenden Sie eine DELETE-Anforderung.
Diese Grundlagen sind sehr wichtig, da Sie mit Ihrer RESTful-App wahrscheinlich eine URI-Bezeichnung haben, die die entsprechende Aufgabe basierend auf der Art des von Ihnen verwendeten Anforderungsverbs ausführt. Beispielsweise:
// The URI pattern
http://localhost:8888/donut/:id
// My URI call
http://localhost:8888/donut/17
Wenn ich ein GET für diesen URI mache, erhält es ein Donut-Modell mit einer ID von 17. Die ID hängt davon ab, wie Sie es serverseitig speichern. Dies kann nur die ID Ihrer Donut-Ressource in Ihrer Datenbanktabelle sein.
Wenn ich einen PUT für diesen URI mit neuen Daten mache, würde ich ihn aktualisieren und darüber speichern. Und wenn ich diesen URI lösche, wird er von meinem System gelöscht.
Da Sie mit POST noch keine Ressource erstellt haben, wird keine Ressourcen-ID eingerichtet. Vielleicht ist das URI-Ziel, das ich Ressourcen erstellen möchte, einfach folgendes:
http://localhost:8888/donut
Kein ID-Fragment in der URI. Alle diese URI-Designs liegen bei Ihnen und wie Sie über Ihre Ressourcen denken. In Bezug auf RESTful Design ist mein Verständnis jedoch, dass Sie die Verben Ihrer Aktionen für Ihre HTTP-Anforderung und die Ressourcen als Substantive beibehalten möchten, die URIs leicht lesbar und menschenfreundlich machen.
Sind Sie noch da? :-)
Kommen wir also zurück zu Backbone. Backbone ist wunderbar, weil es viel Arbeit für Sie erledigt. Um unseren Donut und SecondHelping zu retten, machen wir einfach Folgendes:
myDonut.save();
mySecondHelping.save();
Backbone ist schlau. Wenn Sie gerade eine Donut-Ressource erstellt haben, hat diese keine ID vom Server. Es hat eine sogenannte CID, die Backbone intern verwendet. Da es jedoch keine offizielle ID hat, weiß es, dass es eine neue Ressource erstellen sollte, und sendet eine POST-Anfrage. Wenn Sie Ihr Modell vom Server erhalten haben, hat es wahrscheinlich eine ID, wenn alles in Ordnung ist. In diesem Fall geht Backbone beim Speichern von () davon aus, dass Sie den Server aktualisieren möchten, und es wird ein PUT gesendet. Um eine bestimmte Ressource abzurufen, verwenden Sie die Backbone-Methode .fetch () und sie sendet eine GET-Anforderung. Wenn Sie .destroy () für ein Modell aufrufen, wird DELETE gesendet.
In den vorherigen Beispielen habe ich Backbone nie explizit mitgeteilt, wo sich der URI befindet. Lassen Sie uns das im nächsten Beispiel tun.
thirdHelping = Backbone.Model.extend({
url: 'donut'
});
thirdHelping.set({id:15}); // Set the id attribute of model to 15
thirdHelping.fetch(); // Backbone assumes this model exists on server as ID 15
Das Backbone erhält die dritte Hilfe bei http://localhost:8888/donut/15Es wird einfach / Donut-Stamm zu Ihrer Site-Wurzel hinzugefügt.
Wenn du immer noch bei mir bist, gut. Meiner Ansicht nach. Es sei denn, Sie sind verwirrt. Aber wir stapfen trotzdem weiter. Der zweite Teil davon ist die SERVER-Seite. Wir haben über verschiedene Verben von HTTP und die semantischen Bedeutungen hinter diesen Verben gesprochen. Bedeutungen, die Sie, Backbone UND Ihr Server teilen müssen.
Ihr Server muss den Unterschied zwischen einer GET-, POST-, PUT- und DELETE-Anforderung verstehen. Wie Sie in den obigen Beispielen gesehen haben, können GET, PUT und DELETE alle auf denselben URI verweisen. http://localhost:8888/donut/07Wenn Ihr Server nicht zwischen diesen HTTP-Anforderungen unterscheiden kann, ist es sehr verwirrend, was mit dieser Ressource zu tun ist.
Dies ist der Zeitpunkt, an dem Sie über Ihren RESTful-Serverendcode nachdenken. Einige Leute mögen Ruby, andere mögen .net, ich mag PHP. Besonders gut gefällt mir das SLIM PHP Micro-Framework. SLIM PHP ist ein Mikro-Framework mit einem sehr eleganten und einfachen Toolset für den Umgang mit RESTful-Aktivitäten. Sie können Routen (URIs) wie in den obigen Beispielen definieren. Je nachdem, ob der Aufruf GET, POST, PUT oder DELETE ist, wird der richtige Code ausgeführt. Es gibt andere SLIM-ähnliche Lösungen wie Recess, Tonic. Ich glaube, dass größere Frameworks wie Cake und CodeIgniter ähnliche Dinge tun, obwohl ich Minimal mag. Habe ich gesagt, ich mag Slim? ;-);
So könnte der Auszugscode auf dem Server aussehen (dh speziell in Bezug auf die Routen).
$app->get('/donut/:id', function($id) use ($app) {
// get donut model with id of $id from database.
$donut = ...
// Looks something like this maybe:
// $donut = array('id'=>7, 'flavor'=>'chocolate', 'price'=>'1.00')
$response = $app->response();
$response['Content-Type'] = 'application/json';
$response->body(json_encode($donut));
});
Hierbei ist zu beachten, dass Backbone ein JSON-Objekt erwartet. Lassen Sie Ihren Server den Inhaltstyp immer als 'application / json' festlegen und ihn im json-Format codieren, wenn Sie können. Wenn Backbone dann das JSON-Objekt empfängt, weiß es, wie das Modell, das es angefordert hat, gefüllt wird.
Mit SLIM PHP funktionieren die Routen ziemlich ähnlich wie oben.
$app->post('/donut', function() use ($app) {
// Code to create new donut
// Returns a full donut resource with ID
});
$app->put('/donut/:id', function($id) use ($app) {
// Code to update donut with id, $id
$response = $app->response();
$response->status(200); // OK!
// But you can send back other status like 400 which can trigger an error callback.
});
$app->delete('/donut/:id', function($id) use ($app) {
// Code to delete donut with id, $id
// Bye bye resource
});
Sie haben also fast die volle Rundreise gemacht! Hol dir ein Soda. Ich mag Diet Mountain Dew. Hol mir auch eins.
Sobald Ihr Server eine Anforderung verarbeitet, etwas mit der Datenbank und der Ressource tut, eine Antwort vorbereitet (ob es sich um eine einfache http-Statusnummer oder eine vollständige JSON-Ressource handelt), werden die Daten zur endgültigen Verarbeitung an Backbone zurückgegeben.
Mit Ihren Methoden save (), fetch () usw. können Sie optionale Rückrufe für Erfolg und Fehler hinzufügen. Hier ist ein Beispiel, wie ich diesen speziellen Kuchen aufgebaut habe:
Cake = Backbone.Model.extend({
defaults: {
type: 'plain',
nuts: false
},
url: 'cake'
});
myCake = new Cake();
myCake.toJSON() // Shows us that it is a plain cake without nuts
myCake.save({type:'coconut', nuts:true}, {
wait:true,
success:function(model, response) {
console.log('Successfully saved!');
},
error: function(model, error) {
console.log(model.toJSON());
console.log('error.responseText');
}
});
// ASSUME my server is set up to respond with a status(403)
// ASSUME my server responds with string payload saying 'we don't like nuts'
Es gibt ein paar verschiedene Dinge an diesem Beispiel, die. Sie werden sehen, dass ich für meinen Kuchen, anstatt die Attribute vor dem Speichern festzulegen (), einfach die neuen Attribute an meinen Speicheraufruf übergeben habe. Backbone ist ein ziemlicher Ninja, wenn es darum geht, JSON-Daten überall zu erfassen und wie ein Champion zu behandeln. Also möchte ich meinen Kuchen mit Kokosnüssen und Nüssen retten. (Sind das 2 Nüsse?) Wie auch immer, ich habe zwei Objekte an meine Rettung übergeben. Das Attribut JSON-Objekt UND einige Optionen. Das erste {wait: true} bedeutet, dass mein clientseitiges Modell erst aktualisiert wird, wenn der serverseitige Trip erfolgreich ist. Der erfolgreiche Rückruf erfolgt, wenn der Server erfolgreich eine Antwort zurückgibt. Da dieses Beispiel jedoch zu einem Fehler führt (ein anderer Status als 200 zeigt Backbone an, dass der Fehlerrückruf verwendet werden soll), erhalten wir eine Darstellung des Modells ohne die Änderungen. Es sollte immer noch glatt und ohne Nüsse sein. Wir haben auch Zugriff auf das Fehlerobjekt, das der Server zurückgesendet hat. Wir haben eine Zeichenfolge zurückgesendet, aber es könnte sich um ein JSON-Fehlerobjekt mit mehr Eigenschaften handeln. Dies befindet sich im Attribut error.responseText. Ja, wir mögen keine Nüsse.
Herzliche Glückwünsche. Sie haben Ihre erste ziemlich vollständige Rundreise gemacht, indem Sie ein Modell eingerichtet, es serverseitig gespeichert und zurück. Ich hoffe, dass dieses Antwort-Epos Ihnen eine Vorstellung davon gibt, wie das alles zusammenkommt. Es gibt natürlich viele Details, an denen ich vorbeikomme, aber die Grundideen von Backbone Save, RESTful-Verben, serverseitigen Aktionen und Response sind hier. Lesen Sie weiter die Backbone-Dokumentation (die im Vergleich zu anderen Dokumenten sehr einfach zu lesen ist), aber denken Sie daran, dass dies einige Zeit in Anspruch nimmt, um Ihren Kopf herumzureißen. Je mehr Sie daran festhalten, desto fließender werden Sie. Ich lerne jeden Tag etwas Neues mit Backbone und es macht wirklich Spaß, wenn Sie anfangen, Sprünge zu machen und sehen, wie fließend Sie dieses Framework beherrschen. :-)
Viel Spaß beim Codieren!
BEARBEITEN: Ressourcen, die nützlich sein können:
Andere ähnliche Antworten zu SO:
So generieren Sie Modell-IDs mit Backbone
Auf REST:
http://rest.elkstein.org/
http://www.infoq.com/articles/rest-introduction
http://www.recessframework.org/page/towards-restful-php-5-basic- Tipps