Verileri Kaydetme

Veri Kaydetme Yöntemleri

PUT Verileri fireblog/users/user1/<data> gibi tanımlı bir yola yazın veya değiştirin
YAMA Tüm verileri değiştirmeden, tanımlanmış bir yolun bazı anahtarlarını güncelleyin.
POST Firebase veritabanımızdaki veri listesine ekleme. Her POST isteği gönderdiğimizde Firebase istemcisi fireblog/users/<unique-id>/<data> gibi benzersiz bir anahtar oluşturur
DELETE Belirtilen Firebase veritabanı referansındaki verileri kaldırın.

PUT ile Veri Yazma

REST API üzerinden temel yazma işlemi PUT şeklindedir. Veri tasarrufunu göstermek için gönderiler ve kullanıcılar içeren bir blog uygulaması oluşturacağız. Uygulamamızın tüm verileri, "https://docs-examples.firebaseio.com/fireblog" Firebase veritabanı URL'sindeki "fireblog" yolunda depolanır.

Firebase veritabanımıza bazı kullanıcı verilerini kaydederek başlayalım. Her kullanıcıyı benzersiz bir kullanıcı adıyla kaydederiz. Ayrıca, kullanıcının tam adı ile doğum tarihini de kaydederiz. Her kullanıcının benzersiz bir kullanıcı adı olacağından ve anahtar elimizde zaten mevcut olduğundan ve bir kullanıcı adı oluşturmamız gerekmediğinden, burada POST yerine PUT kullanılması daha iyi olur.

PUT kullanarak Firebase veritabanımıza dize, sayı, boole, dizi veya herhangi bir JSON nesnesi yazabiliriz. Bu örnekte, öğeye bir nesne ileteceğiz:

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

Veritabanına bir JSON nesnesi kaydedildiğinde, nesne özellikleri iç içe yerleştirilmiş bir biçimde otomatik olarak alt konumlarla eşlenir. Yeni oluşturulan düğüme gittiğimizde "Alan Turing" değerini görürüz. Ayrıca, verileri doğrudan bir alt konuma kaydedebiliriz:

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'

Yukarıdaki iki örnekte, değerin bir nesne olarak aynı anda yazılması ve alt konumlara ayrı ayrı yazılması, aynı verilerin Firebase veritabanımıza kaydedilmesini sağlar:

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

Başarılı bir istek, 200 OK HTTP durum kodu ile gösterilir ve yanıt, veritabanına yazdığımız verileri içerir. İlk örnek, verileri izleyen müşteriler için yalnızca bir etkinliği tetiklerken ikinci örnek iki etkinliği tetikler. Kullanıcı yolunda zaten veri varsa ilk yaklaşım verilerin üzerine yazılır, ancak ikinci yöntem yalnızca her bir alt düğümün değerini değiştirirken diğer alt öğeleri değiştirmeden bırakır. PUT, JavaScript SDK'mızdaki set() öğesinin eşdeğeridir.

Verileri YAMA ile Güncelleme

PATCH isteği kullanarak mevcut verilerin üzerine yazmadan belirli bir konumdaki belirli alt öğeleri güncelleyebiliriz. PATCH isteğiyle Turing'in takma adını kullanıcı verilerine ekleyelim:

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

Yukarıdaki istek, name veya birthday alt öğelerini silmeden alanisawesome nesnemize nickname yazar. Bunun yerine burada bir PUT isteği gönderseydik name ve birthday isteğe dahil edilmediği için silinirdi. Firebase veritabanımızdaki veriler artık aşağıdaki gibi görünür:

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

Başarılı bir istek, 200 OK HTTP durum kodu ile gösterilir ve yanıt, veritabanına yazılan güncellenmiş verileri içerir.

Firebase, çok yollu güncellemeleri de destekler. Bu sayede, PATCH artık Firebase veritabanınızdaki birden fazla konumdaki değerleri aynı anda güncelleyebilir. Bu güçlü özellik, verilerinizi normalleştirmenize yardımcı olur. Çok yollu güncellemeleri kullanarak hem Ahmet hem de Gözde'ye aynı anda takma adlar ekleyebiliriz:

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

Bu güncellemeden sonra hem Ahmet hem de Gözde'nin takma adları eklendi:

{
  "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"
    }
  }
}

Yolları içeren nesneleri yazarak nesneleri güncellemeye çalışmanın farklı davranışlara yol açacağını unutmayın. Bunun yerine, Gözde ve Alan'ı şu şekilde güncellemeye çalışırsak neler olacağına bir bakalım:

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

Bu, farklı bir davranışa neden olur ve /fireblog/users düğümünün tamamının üzerine yazılır.

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

Koşullu İstekler İçeren Verileri Güncelleme

Verileri mevcut durumuna göre güncellemek için işlemlerin eşdeğeri olan koşullu istekleri kullanabilirsiniz. Örneğin, bir olumlu oy sayacını artırmak ve sayının aynı anda birden fazla olumlu oyu doğru şekilde yansıttığından emin olmak için yeni değeri sayaça yazmak için koşullu istek kullanın. Sayacı aynı sayıyla değiştiren iki yazma işlemi yerine, yazma isteklerinden biri başarısız olur ve daha sonra isteği yeni değerle yeniden deneyebilirsiniz.
  1. Bir konumda koşullu istek gerçekleştirmek için söz konusu konumdaki mevcut verilerin benzersiz tanımlayıcısını veya ETag'i alın. Bu konumda veriler değişirse ETag de değişir. PATCH dışında bir yöntemle ETag isteğinde bulunabilirsiniz. Aşağıdaki örnekte bir GET isteği kullanılmaktadır.
    curl -i 'https://test.example.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
    
    Özellikle başlıkta ETag'in çağrılması, HTTP yanıtında belirtilen konumun ETag'ini döndürür.
    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. Döndürülen ETag'i, özellikle bu ETag değeriyle eşleşen verileri güncellemek için bir sonraki PUT veya DELETE isteğinize ekleyin. Örneğimize göre, sayacı 11'e veya ilk getirilen 10 değerinden daha büyük olan 1 değerine güncellemek ve değer artık eşleşmiyorsa isteği başarısız olmak için şu kodu kullanın:
    curl -iX PUT -d '11' 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'if-match:[ETAG_VALUE]'
    
    Belirtilen konumdaki veri değeri hâlâ 10 ise PUT isteğindeki ETag eşleşir ve istek başarılı olur ve veritabanına 11 yazılır.
    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
    
    Konum artık ETag ile eşleşmiyorsa (başka bir kullanıcı veritabanına yeni bir değer yazarsa istek, konuma yazmadan başarısız olur). Döndürülen yanıt yeni değeri ve ETag'i içerir.
    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. İsteği yeniden denemeye karar verirseniz yeni bilgileri kullanın. Realtime Database, başarısız olan koşullu istekleri otomatik olarak yeniden denemez. Bununla birlikte, başarısız yanıtının döndürdüğü bilgileri kullanarak yeni bir koşullu istek oluşturmak için yeni değeri ve ETag'i kullanabilirsiniz.

REST tabanlı koşullu istekler, HTTP if-match standardını uygular. Bununla birlikte, standartlardan şu yönleriyle farklıdırlar:

  • Her if-match isteği için birden fazla değil, yalnızca bir ETag değeri sağlayabilirsiniz.
  • Standart, ETag'lerin tüm isteklerle döndürüleceğini önerse de Realtime Database, yalnızca X-Firebase-ETag başlığını içeren isteklerle birlikte ETag'leri döndürür. Bu, standart isteklerin faturalandırma maliyetlerini azaltır.

Koşullu istekler tipik REST isteklerinden daha yavaş da olabilir.

Veri Listelerini Kaydetme

Firebase veritabanı referansına eklenen her alt öğe için benzersiz, zaman damgası tabanlı bir anahtar oluşturmak amacıyla POST isteği gönderebiliriz. Her kullanıcının benzersiz bir kullanıcı adı olduğundan users yolumuz için kendi anahtarlarımızı tanımlamamız mantıklı oldu. Ancak, kullanıcılar uygulamaya blog yayınları eklediğinde her blog yayını için otomatik olarak anahtar oluşturmak üzere bir POST isteği kullanırız:

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

posts yolumuzda artık aşağıdaki veriler bulunuyor:

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

POST isteği kullandığımızdan -JSOpn9ZC54A4P4RoqVa anahtarının bizim için otomatik olarak oluşturulduğuna dikkat edin. Başarılı bir istek 200 OK HTTP durum kodu ile gösterilir ve yanıt, eklenen yeni verilerin anahtarını içerir:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

Verileri Kaldırma

Verileri veritabanından kaldırmak için verileri silmek istediğimiz yolun URL'sini içeren bir DELETE isteği gönderebiliriz. Aşağıdaki işlem Alan'ı users yolumuzdan siler:

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

Başarılı bir DELETE isteği, JSON null içeren bir yanıt içeren 200 OK HTTP durum koduyla gösterilir.

URI Parametreleri

REST API, veritabanına veri yazarken aşağıdaki URI parametrelerini kabul eder:

auth

auth istek parametresi, Firebase Realtime Database Güvenlik Kuralları tarafından korunan verilere erişime olanak tanır ve tüm istek türleri tarafından desteklenir. Bağımsız değişken, Firebase uygulama gizli anahtarımız veya bir kimlik doğrulama jetonu olabilir. Bu jetonu kullanıcı yetkilendirme bölümünde ele alacağız. Aşağıdaki örnekte auth parametresiyle bir POST isteği gönderiyoruz. Bu istekteki CREDENTIAL, Firebase uygulama gizli anahtarımız veya kimlik doğrulama jetonudur:

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

yazdır

print parametresi, veritabanından gelen yanıtın biçimini belirtmemize olanak tanır. İsteğimize print=pretty eklendiğinde veriler kullanıcılar tarafından okunabilecek bir biçimde döndürülür. print=pretty; GET, PUT, POST, PATCH ve DELETE istekleri tarafından desteklenir.

Veri yazarken sunucudan gelen çıkışı engellemek için isteğimize print=silent ekleyebiliriz. Sonuçta elde edilen yanıt boş olur ve istek başarılı olursa 204 No Content HTTP durum koduyla gösterilir. print=silent; GET, PUT, POST ve PATCH istekleri tarafından desteklenir.

Sunucu Değerleri Yazma

Sunucu değerleri, tek bir ".sv" anahtarına sahip nesne olan yer tutucu değeri kullanılarak bir konumda yazılabilir. Bu anahtarın değeri, ayarlamak istediğimiz sunucu değerinin türüdür. Örneğin, bir kullanıcı oluşturulduğunda zaman damgası ayarlamak için aşağıdakileri yapabiliriz:

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

"timestamp", desteklenen tek sunucu değeridir ve UNIX döneminden bu yana milisaniye cinsinden geçen süredir.

Yazma Performansını Geliştirme

Veritabanına büyük miktarda veri yazıyorsak yazma performansımızı iyileştirmek ve bant genişliği kullanımını azaltmak için print=silent parametresini kullanabiliriz. Normal yazma davranışında, sunucu yazılan JSON verileriyle yanıt verir. print=silent belirtildiğinde, veriler alındıktan sonra sunucu bağlantıyı hemen kapatarak bant genişliği kullanımını azaltır.

Veritabanına çok sayıda istek yaptığımız durumlarda HTTP üst bilgisinde Keep-Alive isteği göndererek HTTPS bağlantısını yeniden kullanabiliriz.

Hata Koşulları

REST API, şu durumlarda hata kodlarını döndürür:

HTTP Durum Kodları
400 Hatalı İstek

Aşağıdaki hata koşullarından biri:

  • PUT veya POST verileri ayrıştırılamıyor.
  • PUT veya POST verileri eksik.
  • İstek, çok büyük olan PUT veya POST verilerini işlemeye çalışıyor.
  • REST API çağrısı, yolun bir parçası olarak geçersiz alt adlar içeriyor.
  • REST API çağrısı yolu çok uzun.
  • İstek, tanınmayan bir sunucu değeri içeriyor.
  • Sorgu dizini, Firebase Realtime Database Güvenlik Kurallarınızda tanımlanmamış.
  • İstek, belirtilen sorgu parametrelerinden birini desteklemiyor.
  • İstek, sorgu parametrelerini yüzeysel bir GET isteğiyle karıştırıyor.
401 Yetkisiz

Aşağıdaki hata koşullarından biri:

404 Bulunamadı Belirtilen Firebase veritabanı bulunamadı.
500 Dahili Sunucu Hatası Sunucu hata döndürdü. Daha ayrıntılı bilgi için hata mesajına bakın.
503 Hizmet Kullanılamıyor Belirtilen Firebase Realtime Database geçici olarak kullanılamıyor. Bu nedenle, istekte bulunmaya çalışılmadı.

Verilerin Güvenliğini Sağlama

Firebase, verilerimizin farklı düğümlerine hangi kullanıcıların okuma ve yazma erişimine sahip olacağını tanımlamamızı sağlayan bir güvenlik diline sahiptir. Gerçek Zamanlı Veritabanı Güvenlik Kuralları bölümünde bu konu hakkında daha fazla bilgi edinebilirsiniz.

Veri tasarrufunu incelediğimize göre bir sonraki bölümde REST API aracılığıyla verilerimizi Firebase veritabanından nasıl alacağımızı öğrenebiliriz.