Pada dasarnya Model memiliki properti yang disebut atribut yang merupakan berbagai nilai yang mungkin dimiliki model tertentu. Backbone menggunakan objek JSON sebagai cara sederhana untuk mengisi nilai-nilai ini menggunakan berbagai metode yang mengambil objek JSON. Contoh:
Donuts = Backbone.Model.extend({
defaults: {
flavor: 'Boston Cream',
price: '0.50'
}
});
Untuk mengisi model, ada beberapa cara untuk melakukannya. Misalnya, Anda dapat menyiapkan instance model dengan meneruskan JSON ATAU menggunakan metode yang disebut set () yang mengambil objek atribut JSON.
myDonut = new Donut({'flavor':'lemon', 'price':'0.75'});
mySecondHelping = new Donut();
mySecondHelping.set({'flavor':'plain', 'price':'0.25'});
console.log(myDonut.toJSON());
console.log(mySecondHelping.toJSON());
Jadi ini membawa kita pada model penyimpanan dan menyimpannya baik ke server. Ada banyak detail tentang "Apa itu REST / RESTful?" Dan agak sulit untuk menjelaskan semua ini dalam uraian singkat di sini. Secara khusus berkaitan dengan REST dan penyimpanan Backbone, hal yang perlu diperhatikan adalah semantik permintaan HTTP dan apa yang Anda lakukan dengan data Anda.
Anda mungkin terbiasa dengan dua jenis permintaan HTTP. DAPATKAN dan POSKAN. Dalam lingkungan yang tenang, kata kerja ini memiliki arti khusus untuk penggunaan khusus yang diasumsikan oleh Backbone. Ketika Anda ingin mendapatkan sumber daya tertentu dari server, (misalnya model donat yang saya simpan terakhir kali, entri blog, spesifikasi komputer) dan sumber daya tersebut ada, Anda melakukan permintaan GET. Sebaliknya, ketika Anda ingin membuat sumber daya baru, Anda menggunakan POST.
Sebelum saya masuk ke Backbone, saya bahkan tidak pernah menyentuh dua metode permintaan HTTP berikut. PUT dan HAPUS. Kedua kata kerja ini juga memiliki arti khusus untuk Backbone. Saat Anda ingin memperbarui sumber daya, (mis. Mengubah rasa donat lemon menjadi donat limon, dll.) Anda menggunakan permintaan PUT. Saat Anda ingin menghapus model itu dari server secara bersamaan, Anda menggunakan permintaan DELETE.
Dasar-dasar ini sangat penting karena dengan aplikasi RESTful Anda, Anda mungkin akan memiliki sebutan URI yang akan melakukan tugas yang sesuai berdasarkan jenis kata kerja permintaan yang Anda gunakan. Sebagai contoh:
http:
http:
Jika saya membuat GET ke URI itu, model tersebut akan mendapatkan model donat dengan ID 17.: id bergantung pada cara Anda menyimpannya di sisi server. Ini hanya bisa menjadi ID sumber daya donat Anda di tabel database Anda.
Jika saya membuat PUT ke URI itu dengan data baru, saya akan memperbaruinya, menyimpannya. Dan jika saya MENGHAPUS ke URI itu, maka itu akan menghapusnya dari sistem saya.
Dengan POST, karena Anda belum membuat sumber daya, itu tidak akan memiliki ID sumber daya yang mapan. Mungkin target URI yang ingin saya buat sumber daya hanyalah ini:
http:
Tidak ada fragmen ID di URI. Semua desain URI ini terserah Anda dan bagaimana Anda memikirkan resource Anda. Tetapi terkait dengan desain RESTful, pemahaman saya adalah Anda ingin menyimpan kata kerja tindakan Anda ke permintaan HTTP dan sumber daya sebagai kata benda yang membuat URI mudah dibaca dan ramah manusia.
Apakah Anda masih dengan saya? :-)
Jadi mari kita kembali memikirkan tentang Backbone. Backbone sangat bagus karena melakukan banyak pekerjaan untuk Anda. Untuk menyimpan donat dan secondHelping kami, kami cukup melakukan ini:
myDonut.save();
mySecondHelping.save();
Tulang punggung itu cerdas. Jika Anda baru saja membuat sumber daya donat, itu tidak akan memiliki ID dari server. Ini memiliki sesuatu yang disebut cID yang digunakan oleh Backbone secara internal tetapi karena tidak memiliki ID resmi, ia tahu bahwa ia harus membuat sumber daya baru dan mengirimkan permintaan POST. Jika Anda mendapatkan model Anda dari server, model itu mungkin akan memiliki ID jika semuanya benar. Dalam kasus ini, ketika Anda menyimpan () Backbone mengasumsikan Anda ingin memperbarui server dan itu akan mengirim PUT. Untuk mendapatkan sumber daya tertentu, Anda akan menggunakan metode Backbone .fetch () dan mengirimkan permintaan GET. Ketika Anda memanggil .destroy () pada model itu akan mengirim DELETE.
Dalam contoh sebelumnya, saya tidak pernah secara eksplisit memberi tahu Backbone di mana URI berada. Mari kita lakukan itu di contoh berikutnya.
thirdHelping = Backbone.Model.extend({
url: 'donut'
});
thirdHelping.set({id:15});
thirdHelping.fetch();
Backbone akan MENDAPATKAN Bantuan ketiga di http://localhost:8888/donut/15Itu hanya akan menambahkan / donat batang ke root situs Anda.
Jika Anda MASIH bersamaku, bagus. Kupikir. Kecuali Anda sedang bingung. Tapi kita akan terus berjalan dengan susah payah. Bagian kedua dari ini adalah sisi SERVER. Kami telah berbicara tentang berbagai kata kerja HTTP dan arti semantik di balik kata kerja tersebut. Arti yang harus Anda, Backbone, DAN server Anda bagikan.
Server Anda perlu memahami perbedaan antara permintaan GET, POST, PUT, dan DELETE. Seperti yang Anda lihat pada contoh di atas, GET, PUT, dan DELETE semuanya dapat mengarah ke URI yang sama http://localhost:8888/donut/07Kecuali server Anda dapat membedakan antara permintaan HTTP ini, akan sangat bingung tentang apa yang harus dilakukan dengan sumber daya tersebut.
Ini adalah saat Anda mulai memikirkan kode akhir server RESTful Anda. Beberapa orang suka Ruby, beberapa orang suka .net, saya suka PHP. Terutama saya suka kerangka mikro PHP SLIM. SLIM PHP adalah kerangka kerja mikro yang memiliki seperangkat alat yang sangat elegan dan sederhana untuk menangani aktivitas RESTful. Anda dapat menentukan rute (URI) seperti pada contoh di atas dan bergantung pada apakah panggilan itu GET, POST, PUT, atau DELETE, ia akan mengeksekusi kode yang benar. Ada solusi lain yang mirip dengan SLIM seperti Recess, Tonic. Saya percaya framework yang lebih besar seperti Cake dan CodeIgniter juga melakukan hal serupa meskipun saya suka minimal. Apakah saya mengatakan saya suka Slim? ;-)
Inilah yang mungkin terlihat dari kode kutipan di server (yaitu secara khusus mengenai rute.)
$app->get('/donut/:id', function($id) use ($app) {
$donut = ...
$response = $app->response();
$response['Content-Type'] = 'application/json';
$response->body(json_encode($donut));
});
Di sini penting untuk dicatat bahwa Backbone mengharapkan objek JSON. Selalu minta server Anda menetapkan jenis konten sebagai 'application / json' dan menyandikannya dalam format json jika Anda bisa. Kemudian saat Backbone menerima objek JSON, ia tahu bagaimana mengisi model yang memintanya.
Dengan SLIM PHP, rute beroperasi sangat mirip dengan di atas.
$app->post('/donut', function() use ($app) {
});
$app->put('/donut/:id', function($id) use ($app) {
$response = $app->response();
$response->status(200);
});
$app->delete('/donut/:id', function($id) use ($app) {
});
Jadi, Anda hampir melakukan perjalanan pulang pergi penuh! Dapatkan soda. Saya suka Diet Mountain Dew. Dapatkan satu untukku juga.
Setelah server Anda memproses permintaan, melakukan sesuatu dengan database dan sumber daya, menyiapkan tanggapan (apakah itu nomor status http sederhana atau sumber daya JSON penuh), kemudian data kembali ke Backbone untuk pemrosesan akhir.
Dengan metode save (), fetch (), dll. - Anda dapat menambahkan callback opsional jika berhasil dan error. Berikut adalah contoh bagaimana saya menyiapkan kue khusus ini:
Cake = Backbone.Model.extend({
defaults: {
type: 'plain',
nuts: false
},
url: 'cake'
});
myCake = new Cake();
myCake.toJSON()
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');
}
});
Ada beberapa hal berbeda tentang contoh ini. Anda akan melihat itu untuk kue saya, alih-alih menyetel atribut sebelum menyimpan, saya hanya meneruskan atribut baru ke panggilan simpan saya. Backbone adalah ninja yang bagus dalam mengambil data JSON di semua tempat dan menanganinya seperti seorang juara. Jadi saya ingin menyimpan kue saya dengan kelapa dan kacang. (Apa itu 2 kacang?) Pokoknya, aku menyerahkan dua benda untuk menyelamatkanku. Atribut objek JSON DAN beberapa opsi. Yang pertama, {tunggu: true} berarti jangan perbarui model sisi klien saya hingga perjalanan sisi server berhasil. Panggilan balik yang berhasil akan terjadi ketika server berhasil mengembalikan respons. Namun, karena contoh ini menghasilkan kesalahan (status selain 200 akan menunjukkan ke Backbone untuk menggunakan panggilan balik kesalahan) kami mendapatkan representasi model tanpa perubahan. Ini harus tetap polos dan tanpa kacang. Kami juga memiliki akses ke objek kesalahan yang dikirim kembali oleh server. Kami mengirim kembali string tetapi itu bisa jadi objek kesalahan JSON dengan lebih banyak properti. Ini terletak di atribut error.responseText. Ya, 'kami tidak suka kacang.'
Selamat. Anda telah melakukan perjalanan pulang-pergi pertama yang cukup lengkap dari menyiapkan model, menyimpannya di sisi server, dan sebaliknya. Saya harap jawaban epik ini memberi Anda IDEA tentang bagaimana semua ini bersatu. Tentu saja, ada banyak detail yang saya jelajahi tetapi ide dasar dari penyimpanan Backbone, kata kerja RESTful, Tindakan sisi server, Respon ada di sini. Teruskan membaca dokumentasi Backbone (yang sangat mudah dibaca dibandingkan dengan dokumen lain) tetapi perlu diingat bahwa ini membutuhkan waktu untuk menyelesaikannya. Semakin Anda terus melakukannya, Anda akan semakin lancar. Saya belajar sesuatu yang baru dengan Backbone setiap hari dan itu menjadi sangat menyenangkan saat Anda mulai membuat lompatan dan melihat kefasihan Anda dalam kerangka kerja ini berkembang. :-)
Selamat membuat kode!
EDIT: Sumber daya yang mungkin berguna:
Jawaban Serupa Lainnya di SO:
Bagaimana menghasilkan ID model dengan Backbone
Di REST:
http://rest.elkstein.org/
http://www.infoq.com/articles/rest-introduction
http://www.recessframework.org/page/towards-restful-php-5-basic- tips