Fondamentalement, les Modèles ont une propriété appelée attributs qui sont les différentes valeurs d'un certain modèle. Épine dorsale utilise des objets JSON comme un moyen simple pour remplir ces valeurs à l'aide de diverses méthodes qui prennent des objets JSON. Exemple:
Donuts = Backbone.Model.extend({
defaults: {
flavor: 'Boston Cream', // Some string
price: '0.50' // Dollars
}
});
Pour alimenter le modèle, il existe quelques façons de le faire. Par exemple, vous pouvez configurer votre modèle exemple par passage dans un JSON OU utiliser la méthode set() qui prend en paramètre un objet JSON d'attributs.
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'}
Donc, cela nous amène jusqu'à enregistrer des modèles et persistante à un serveur. Il y a tout un tas de détails sur "Ce qui est au REPOS et Reposante?" Et il est un peu difficile d'expliquer tout cela dans un court texte de présentation ici. En ce qui concerne spécifiquement le REPOS et la colonne vertébrale de l'épargne, de la chose pour envelopper votre tête autour de est la sémantique de requêtes HTTP et de ce que vous faites avec vos données.
Vous êtes probablement habitué à deux types de requêtes HTTP. GET et POST. Dans un cadre apaisant, ces verbes ont une signification particulière pour les usages spécifiques que épine Dorsale suppose. Lorsque vous voulez obtenir une certaine ressource sur le serveur (par exemple donut modèle que j'ai sauvé la dernière fois, une entrée de blog, une spécification informatique) et que la ressource existe, tu fais une requête GET. A l'inverse, lorsque vous voulez créer une nouvelle ressource POST.
Avant que je sois dans épine Dorsale, je n'ai jamais touché à la suite de deux méthodes de demande de HTTP. PUT et DELETE. Ces deux verbes ont aussi un sens particulier à la colonne vertébrale. Lorsque vous souhaitez mettre à jour une ressource, par exemple Changer la saveur de citron beignet de limon beignets, etc.) vous utilisez une requête PUT. Lorsque vous voulez supprimer ce modèle à partir du serveur tous ensemble, vous utilisez une demande de SUPPRESSION.
Ces bases sont très importantes, car avec votre Réparateur application, vous aurez probablement une URI de désignation qui va faire la tâche appropriée en fonction du type de demande verbe que vous utilisez. Par exemple:
// The URI pattern
http://localhost:8888/donut/:id
// My URI call
http://localhost:8888/donut/17
Si je fais un GET d'URI, il se beigne modèle avec un ID de 17. L' :id dépend de la façon dont vous êtes le sauvegarder côté serveur. Ce pourrait être simplement l'ID de votre donut ressource dans votre table de base de données.
Si je fais une mise à URI avec de nouvelles données, je serais la mise à jour, de l'enregistrer sur elle. Et si je supprime cette URI, alors il serait la purge de mon système.
Avec POST, puisque vous n'avez pas créé une ressource encore de ne pas avoir mis en place un ID de ressource. Peut-être que l'URI de la cible, je veux créer des ressources est simplement ceci:
http://localhost:8888/donut
Pas d'ID de fragment dans l'URI. L'ensemble de ces URI dessins sont de vous et de la façon dont vous pensez à vos ressources. Mais en matière de conception Reposant, ma compréhension, c'est que vous voulez garder les verbes de vos actions à votre requête HTTP et les ressources comme des noms qui font Uri facile à lire et conviviale.
Êtes-vous toujours avec moi? :-)
Revenons donc à la réflexion sur la colonne vertébrale. La dorsale est merveilleux parce que c'est beaucoup de travail pour vous. Pour sauver notre beignet et secondHelping, nous avons simplement faire ceci:
myDonut.save();
mySecondHelping.save();
La dorsale est intelligent. Si vous venez de créer un beignet de ressources, il ne sera pas un ID à partir du serveur. Il a quelque chose qui s'appelle un cID qui est ce que l'épine Dorsale utilise en interne mais comme il ne dispose pas d'une pièce d'identité officielle, il sait qu'il doit créer une nouvelle ressource et il envoie une requête POST. Si vous avez obtenu votre modèle à partir du serveur, il sera probablement un ID si tout était bien. Dans ce cas, lorsque vous enregistrez() épine Dorsale suppose que vous voulez mettre à jour le serveur et il enverra un PUT. Pour obtenir une ressource spécifique, vous pouvez utiliser l'épine Dorsale de la méthode .fetch() et il envoie une requête GET. Lorsque vous appelez .destroy() sur un modèle il va envoyer le SUPPRIMER.
Dans les exemples précédents, je n'ai jamais dit explicitement épine Dorsale où l'URI est. Faisons-le dans l'exemple suivant.
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
Épine dorsale obtiendrez la thirdHelping en http://localhost:8888/donut/15 Il suffit simplement d'y ajouter /donut de la tige à la racine de votre site.
Si vous êtes TOUJOURS avec moi, bon. Je pense que. Sauf si vous êtes confus. Mais nous allons aller de toute façon. La deuxième partie de ce est le côté SERVEUR. Nous avons parlé des différents verbes de HTTP et de la sémantique des significations derrière ces verbes. Les significations que vous, de la colonne vertébrale, ET que votre serveur doit partager.
Votre serveur doit comprendre la différence entre un GET, POST, PUT et DELETE demande. Comme vous l'avez vu dans les exemples ci-dessus, GET, PUT et DELETE pourrait tout point à la même URI http://localhost:8888/donut/07 Sauf si votre serveur peut faire la différence entre ces requêtes HTTP, il sera très confus quant à ce faire avec cette ressource.
C'est quand vous commencez à penser à votre serveur RESTful le code de fin. Certaines personnes comme le Rubis, certaines personnes aiment .net, j'ai comme PHP. En particulier j'aime SLIM PHP micro-framework. SLIM PHP est un micro-framework qui a un très élégant et simple ensemble d'outils pour traiter Reposant activités. Vous pouvez définir des itinéraires (Uri) comme dans les exemples ci-dessus et selon que l'appel est GET, POST, PUT ou DELETE il va exécuter le bon code. Il y a d'autres solutions similaires à SLIM comme la Récréation, la Tonique. Je crois que plus les cadres comme les gâteaux et CodeIgniter aussi faire des choses similaires, bien que j'aime minime. Ai-je dire que j'aime la Slim? ;-)
C'est ce que l'extrait de code sur le serveur pourrait ressembler (c'est à dire en ce qui concerne spécifiquement les routes.)
$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));
});
Ici, il est important de noter que la Dorsale s'attend à un objet JSON. Ayez toujours votre serveur de désigner le content-type "application/json" et de l'encoder au format json si vous le pouvez. Puis, lorsque le Squelette reçoit l'objet JSON, il sait comment faire pour remplir le modèle qui l'a demandé.
Avec SLIM PHP, les routes fonctionner assez similaire à celle ci-dessus.
$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
});
Donc, vous avez presque fait le tour complet du voyage! Aller chercher une canette de soda. J'aime Diet Mountain Dew. Obtenir un pour moi aussi.
Une fois que votre serveur traite une demande, fait quelque chose avec la base de données et de ressources, prépare une réponse (qu'il soit un simple http statut de nombre ou à plein JSON de ressources), puis les données revient à la colonne vertébrale pour le traitement final.
Avec votre save(), fetch(), etc. méthodes - vous pouvez ajouter des rappels sur la réussite et l'erreur. Voici un exemple de comment j'ai configuré ce gâteau:
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'
Il ya un couple de différentes choses à propos de cet exemple que. Vous verrez que pour mon gâteau, au lieu de set() ing les attributs avant de l'enregistrer, j'ai simplement passé dans les nouveaux attributs pour enregistrer mon appel. La dorsale est assez ninja à la prise de données JSON tous sur la place et le traitant comme un champion. Si je veux sauver mon gâteau à la noix de coco et les noix. (Est-ce que les 2 écrous?) De toute façon, je suis passé dans deux objets de mon enregistrer. Les attributs de l'objet JSON ET quelques options. La première, {attendre:true} les moyens de ne pas mettre à jour mon côté client modèle jusqu'à ce que le côté serveur de voyage est un succès. La réussite de retour d'appel va se produire lorsque le serveur renvoie une réponse. Cependant, puisque cet exemple conduit à une erreur (un statut autre que 200 indiquera à l'épine Dorsale à utiliser l'erreur de rappel), nous obtenons une représentation du modèle, sans les modifications. Il devrait toujours être simple et sans noix. Nous avons aussi accès à l'objet d'erreur que le serveur a envoyé en retour. Nous avons renvoyé un string, mais il pourrait être JSON erreur de l'objet avec plus de propriétés. Il est situé dans l'erreur.responseText attribut. Ouais, on n'aime pas les noix.'
Félicitations. Vous avez fait votre première assez complet aller-retour à partir de la mise en place d'un modèle, en l'enregistrant côté serveur, et à l'arrière. J'espère que cette réponse épique vous donne une IDÉE de la façon dont tout cela s'assemble. Il y a de sûr, beaucoup de détails que je suis croisière passé, mais les idées de base de l'épine Dorsale enregistrer, de détente, des verbes, des actions côté Serveur, la Réponse est ici. Continuez à travers l'épine Dorsale de la documentation (qui est super facile à lire par rapport à d'autres docs), mais il suffit de garder à l'esprit que cela prend du temps pour envelopper votre tête autour de. Le plus vous gardez à elle le plus à l'aise que vous serez. J'apprends quelque chose de nouveau avec de l'épine Dorsale de tous les jours et c'est vraiment amusant que vous commencez à faire des sauts et de voir votre aisance dans ce cadre croissante. :-)
Amusez-vous bien!
EDIT: les Ressources qui peuvent être utiles:
D'autres Réponses Semblables sur de SORTE que:
Comment générer des Id de modèle avec Dorsale
Sur le RESTE:
http://rest.elkstein.org/
http://www.infoq.com/articles/rest-introduction
http://www.recessframework.org/page/towards-restful-php-5-basic-tips
