Menyimpan Data

Menulis Data dengan PUT

Operasi penulisan dasar melalui REST API adalah PUT . Untuk mendemonstrasikan penghematan data, kami akan membuat aplikasi blog dengan postingan dan pengguna. Semua data untuk aplikasi kita akan disimpan di bawah jalur `fireblog`, di URL database Firebase `https://docs-examples.firebaseio.com/fireblog`.

Mari kita mulai dengan menyimpan beberapa data pengguna ke database Firebase kita. Kami akan menyimpan setiap pengguna dengan nama pengguna yang unik, dan kami juga akan menyimpan nama lengkap dan tanggal lahir mereka. Karena setiap pengguna akan memiliki nama pengguna yang unik, masuk akal untuk menggunakan PUT di sini daripada POST karena kita sudah memiliki kuncinya dan tidak perlu membuatnya.

Menggunakan PUT , kita dapat menulis string, angka, boolean, array, atau objek JSON apa pun ke database Firebase kita. Dalam hal ini kita akan memberikannya sebuah objek:

curl -X PUT -d '{
  "alanisawesome": {
    "name": "Alan Turing",
    "birthday": "June 23, 1912"
  }
}' 'https://docs-examples.firebaseio.com/fireblog/users.json'

Saat objek JSON disimpan ke database, properti objek secara otomatis dipetakan ke lokasi anak dalam mode bersarang. Jika kita menavigasi ke node yang baru dibuat, kita akan melihat nilai "Alan Turing". Kami juga dapat menyimpan data langsung ke lokasi anak:

curl -X PUT -d '"Alan Turing"' \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome/name.json'

curl -X PUT -d '"June 23, 1912"' \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome/birthday.json'

Dua contoh di atas—menulis nilai pada saat yang sama sebagai objek dan menuliskannya secara terpisah ke lokasi turunan—akan menghasilkan data yang sama yang disimpan ke database Firebase kami:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing"
    }
  }
}

Permintaan yang berhasil akan ditunjukkan oleh kode status HTTP 200 OK , dan responsnya akan berisi data yang kami tulis ke database. Contoh pertama hanya akan memicu satu peristiwa pada klien yang menonton data, sedangkan contoh kedua akan memicu dua. Penting untuk dicatat bahwa jika data sudah ada di jalur pengguna, pendekatan pertama akan menimpanya, tetapi metode kedua hanya akan mengubah nilai setiap simpul anak yang terpisah sambil membiarkan anak-anak lain tidak berubah. PUT setara dengan set() di JavaScript SDK kami.

Memperbarui Data dengan PATCH

Menggunakan permintaan PATCH , kami dapat memperbarui anak-anak tertentu di lokasi tanpa menimpa data yang ada. Mari tambahkan nama panggilan Turing ke data penggunanya dengan permintaan PATCH :

curl -X PATCH -d '{
  "nickname": "Alan The Machine"
}' \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome.json'

Permintaan di atas akan menulis nickname ke objek alanisawesome kita tanpa menghapus name atau birthday anak. Perhatikan bahwa jika kami telah mengeluarkan permintaan PUT di sini, name dan tanggal birthday akan dihapus karena tidak disertakan dalam permintaan. Data di database Firebase kami sekarang terlihat seperti ini:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing",
      "nickname": "Alan The Machine"
    }
  }
}

Permintaan yang berhasil akan ditunjukkan oleh kode status HTTP 200 OK , dan responsnya akan berisi data terbaru yang ditulis ke database.

Firebase juga mendukung pembaruan multi-jalur. Ini berarti PATCH sekarang dapat memperbarui nilai di beberapa lokasi di database Firebase Anda secara bersamaan, sebuah fitur canggih yang memungkinkan Anda mendenormalisasi data Anda . Menggunakan pembaruan multi-jalur, kami dapat menambahkan nama panggilan ke Alan dan Grace secara bersamaan:

curl -X PATCH -d '{
  "alanisawesome/nickname": "Alan The Machine",
  "gracehopper/nickname": "Amazing Grace"
}' \
  'https://docs-examples.firebaseio.com/fireblog/users.json'

Setelah pembaruan ini, nama panggilan Alan dan Grace ditambahkan:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing",
      "nickname": "Alan The Machine"
    },
    "gracehop": {
      "date_of_birth": "December 9, 1906",
      "full_name": "Grace Hopper",
      "nickname": "Amazing Grace"
    }
  }
}

Perhatikan bahwa mencoba memperbarui objek dengan menulis objek dengan jalur yang disertakan akan menghasilkan perilaku yang berbeda. Mari kita lihat apa yang terjadi jika kita mencoba memperbarui Grace dan Alan dengan cara ini:

curl -X PATCH -d '{
  "alanisawesome": {"nickname": "Alan The Machine"},
  "gracehopper": {"nickname": "Amazing Grace"}
}' \
  'https://docs-examples.firebaseio.com/fireblog/users.json'

Ini menghasilkan perilaku yang berbeda, yaitu menimpa seluruh /fireblog/users node:

{
  "users": {
    "alanisawesome": {
      "nickname": "Alan The Machine"
    },
    "gracehop": {
      "nickname": "Amazing Grace"
    }
  }
}

Memperbarui Data dengan Permintaan Bersyarat

1. Untuk melakukan permintaan bersyarat di suatu lokasi, dapatkan pengidentifikasi unik untuk data saat ini di lokasi itu, atau ETag. Jika data berubah di lokasi itu, ETag juga berubah. Anda dapat meminta ETag dengan metode apa pun selain PATCH . Contoh berikut menggunakan permintaan GET .

   curl -i 'https://test.example.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
   

   Secara khusus memanggil ETag di header mengembalikan ETag dari lokasi yang ditentukan dalam respons HTTP.

   HTTP/1.1 200 OK
   Content-Length: 6
   Content-Type: application/json; charset=utf-8
   Access-Control-Allow-Origin: *
   ETag: [ETAG_VALUE]
   Cache-Control: no-cache
   
   10 // Current value of the data at the specified location
   

2. Sertakan ETag yang dikembalikan dalam permintaan PUT atau DELETE Anda berikutnya untuk memperbarui data yang secara khusus cocok dengan nilai ETag tersebut. Mengikuti contoh kami, untuk memperbarui penghitung ke 11, atau 1 lebih besar dari nilai awal yang diambil 10, dan gagal permintaan jika nilainya tidak lagi cocok, gunakan kode berikut:

   curl -iX PUT -d '11' 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'if-match:[ETAG_VALUE]'
   

   Jika nilai data pada yang ditentukan lokasi masih 10, ETag dalam permintaan PUT cocok, dan permintaan berhasil, menulis 11 ke database.

   HTTP/1.1 200 OK
   Content-Length: 6
   Content-Type: application/json; charset=utf-8
   Access-Control-Allow-Origin: *
   Cache-Control: no-cache
   
   11 // New value of the data at the specified location, written by the conditional request
   

   Jika lokasi tidak lagi cocok dengan ETag, yang mungkin terjadi jika pengguna lain menulis nilai baru ke database, permintaan gagal tanpa menulis ke lokasi. Respons pengembalian mencakup nilai baru dan ETag.

   HTTP/1.1 412 Precondition Failed
   Content-Length: 6
   Content-Type: application/json; charset=utf-8
   Access-Control-Allow-Origin: *
   ETag: [ETAG_VALUE]
   Cache-Control: no-cache
   
   12 // New value of the data at the specified location
   

3. Gunakan informasi baru jika Anda memutuskan untuk mencoba kembali permintaan tersebut. Realtime Database tidak secara otomatis mencoba kembali permintaan bersyarat yang gagal. Namun, Anda dapat menggunakan nilai baru dan ETag untuk membuat permintaan bersyarat baru dengan informasi yang dikembalikan oleh respons gagal.

Permintaan bersyarat berbasis REST menerapkan standar HTTP if-match . Namun, mereka berbeda dari standar dengan cara berikut:

• Anda hanya dapat memberikan satu nilai ETag untuk setiap permintaan if-match, bukan beberapa.
• Sementara standar menyarankan agar ETag dikembalikan dengan semua permintaan, Realtime Database hanya mengembalikan ETag dengan permintaan termasuk header X-Firebase-ETag . Ini mengurangi biaya penagihan untuk permintaan standar.

Permintaan bersyarat mungkin juga lebih lambat dari permintaan REST biasa.

Menyimpan Daftar Data

Untuk menghasilkan kunci berbasis stempel waktu yang unik untuk setiap turunan yang ditambahkan ke referensi database Firebase, kami dapat mengirim permintaan POST . Untuk jalur users kami, masuk akal untuk menentukan kunci kami sendiri karena setiap pengguna memiliki nama pengguna yang unik. Tetapi ketika pengguna menambahkan posting blog ke aplikasi, kami akan menggunakan permintaan POST untuk membuat kunci secara otomatis untuk setiap posting blog:

curl -X POST -d '{
  "author": "alanisawesome",
  "title": "The Turing Machine"
}' 'https://docs-examples.firebaseio.com/fireblog/posts.json'

Jalur posts kami sekarang memiliki data berikut:

{
  "posts": {
    "-JSOpn9ZC54A4P4RoqVa": {
      "author": "alanisawesome",
      "title": "The Turing Machine"
    }
  }
}

Perhatikan bahwa kunci -JSOpn9ZC54A4P4RoqVa dibuat secara otomatis untuk kami karena kami menggunakan permintaan POST . Permintaan yang berhasil akan ditunjukkan oleh kode status HTTP 200 OK , dan responsnya akan berisi kunci dari data baru yang ditambahkan:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

Menghapus Data

Untuk menghapus data dari database, kita dapat mengirim permintaan DELETE dengan URL jalur dari mana kita ingin menghapus data. Berikut ini akan menghapus Alan dari jalur users kami:

curl -X DELETE \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome.json'

Permintaan DELETE yang berhasil akan ditunjukkan oleh kode status HTTP 200 OK dengan respons yang berisi JSON null .

Parameter URI

REST API menerima parameter URI berikut saat menulis data ke database:

auth

Parameter permintaan auth memungkinkan akses ke data yang dilindungi oleh Aturan Firebase Realtime Database , dan didukung oleh semua jenis permintaan. Argumennya bisa berupa rahasia aplikasi Firebase atau token autentikasi, yang akan kita bahas di bagian otorisasi pengguna . Dalam contoh berikut, kami mengirim permintaan POST dengan parameter auth , di mana CREDENTIAL adalah rahasia aplikasi Firebase kami atau token autentikasi:

curl -X POST -d '{"Authenticated POST request"}' \
  'https://docs-examples.firebaseio.com/auth-example.json?auth=CREDENTIAL'

mencetak

Parameter print memungkinkan kita menentukan format respon kita dari database. Menambahkan print=pretty ke permintaan kami akan mengembalikan data dalam format yang dapat dibaca manusia. print=pretty didukung oleh permintaan GET , PUT , POST , PATCH , dan DELETE .

Untuk menekan output dari server saat menulis data, kita dapat menambahkan print=silent ke permintaan kita. Respons yang dihasilkan akan kosong dan ditunjukkan dengan kode status HTTP 204 No Content jika permintaan berhasil. print=silent didukung oleh permintaan GET , PUT , POST , dan PATCH .

Menulis Nilai Server

Nilai server dapat ditulis di lokasi menggunakan nilai placeholder, yang merupakan objek dengan satu kunci ".sv" . Nilai untuk kunci itu adalah jenis nilai server yang ingin kita tetapkan. Misalnya, untuk menetapkan stempel waktu saat pengguna dibuat, kita dapat melakukan hal berikut:

curl -X PUT -d '{".sv": "timestamp"}' \
  'https://docs-examples.firebaseio.com/alanisawesome/createdAt.json'

"timestamp" adalah satu-satunya nilai server yang didukung, dan merupakan waktu sejak zaman UNIX dalam milidetik.

Meningkatkan Performa Tulis

Jika kita menulis data dalam jumlah besar ke database, kita dapat menggunakan parameter print=silent untuk meningkatkan kinerja penulisan dan mengurangi penggunaan bandwidth. Dalam perilaku penulisan normal, server merespons dengan data JSON yang ditulis. Ketika print=silent ditentukan, server segera menutup koneksi setelah data diterima, mengurangi penggunaan bandwidth.

Jika kita membuat banyak permintaan ke database, kita dapat menggunakan kembali koneksi HTTPS dengan mengirimkan permintaan Keep-Alive di header HTTP.

Kondisi Kesalahan

REST API akan mengembalikan kode kesalahan dalam keadaan berikut:

Mengamankan Data

Firebase memiliki bahasa keamanan yang memungkinkan kami menentukan pengguna mana yang memiliki akses baca dan tulis ke berbagai node data kami. Anda dapat membaca lebih lanjut tentangnya di Aturan Database Realtime .