Daten speichern

Daten mit PUT schreiben

Der grundlegende Schreibvorgang über die REST API ist PUT. Um das Speichern von Daten zu demonstrieren, erstellen wir eine Blogging-Anwendung mit Beiträgen und Nutzern. Alle Daten für unsere Anwendung werden unter dem Pfad „fireblog“ in der Firebase-Datenbank-URL „https://docs-examples.firebaseio.com/fireblog“ gespeichert.

Speichern wir zuerst einige Nutzerdaten in unserer Firebase-Datenbank. Wir speichern jeden Nutzer mit einem eindeutigen Nutzernamen sowie mit seinem vollständigen Namen und Geburtsdatum. Da jeder Nutzer einen eindeutigen Nutzernamen hat, ist es sinnvoll, hier PUT anstelle von POST zu verwenden, da wir den Schlüssel bereits haben und keinen erstellen müssen.

Mit PUT können wir einen String, eine Zahl, einen booleschen Wert, ein Array oder ein beliebiges JSON-Objekt in unsere Firebase-Datenbank schreiben. In diesem Fall übergeben wir ein Objekt:

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

Wenn ein JSON-Objekt in der Datenbank gespeichert wird, werden die Objekteigenschaften automatisch in einer verschachtelten Struktur untergeordneten Speicherorten zugeordnet. Wenn wir zum neu erstellten Knoten navigieren, sehen wir den Wert „Alan Turing“. Wir können Daten auch direkt an einem untergeordneten Speicherort speichern:

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'

Die beiden oben genannten Beispiele – den Wert gleichzeitig mit einem Objekt schreiben und ihn separat an untergeordnete Speicherorte schreiben – führen dazu, dass dieselben Daten in unserer Firebase-Datenbank gespeichert werden:

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

Eine erfolgreiche Anfrage wird durch einen 200 OK-HTTP-Statuscode angezeigt. Die Antwort enthält die Daten, die wir in die Datenbank geschrieben haben. Im ersten Beispiel wird nur ein Ereignis auf Clients ausgelöst, die die Daten beobachten, im zweiten Beispiel jedoch zwei. Wenn bereits Daten im Nutzerpfad vorhanden sind, werden sie beim ersten Ansatz überschrieben. Bei der zweiten Methode wird nur der Wert jedes einzelnen untergeordneten Knotens geändert, während andere untergeordnete Knoten unverändert bleiben. PUT entspricht set() in unserem JavaScript SDK.

Daten mit PATCH aktualisieren

Mit einer PATCH-Anfrage können wir bestimmte untergeordnete Elemente an einem Ort aktualisieren, ohne vorhandene Daten zu überschreiben. Wir fügen den Spitznamen von Turing mit einer PATCH-Anfrage zu seinen Nutzerdaten hinzu:

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

Mit der obigen Anfrage wird nickname in unser alanisawesome-Objekt geschrieben, ohne die untergeordneten Elemente name oder birthday zu löschen. Hätten wir stattdessen eine PUT-Anfrage gestellt, wären name und birthday gelöscht worden, da sie nicht in der Anfrage enthalten waren. Die Daten in unserer Firebase-Datenbank sehen jetzt so aus:

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

Eine erfolgreiche Anfrage wird durch einen 200 OK-HTTP-Statuscode angezeigt. Die Antwort enthält die aktualisierten Daten, die in die Datenbank geschrieben wurden.

Firebase unterstützt auch Updates mit mehreren Pfaden. Das bedeutet, dass PATCH jetzt Werte an mehreren Stellen in Ihrer Firebase-Datenbank gleichzeitig aktualisieren kann. Das ist eine leistungsstarke Funktion, mit der Sie Ihre Daten denormalisieren können. Mit Multi-Path-Updates können wir sowohl Alan als auch Grace gleichzeitig Spitznamen hinzufügen:

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

Nach diesem Update wurden die Spitznamen von Alan und Grace hinzugefügt:

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

Wenn Sie versuchen, Objekte zu aktualisieren, indem Sie Objekte mit den enthaltenen Pfaden schreiben, führt dies zu einem anderen Verhalten. Sehen wir uns an, was passiert, wenn wir Grace und Alan stattdessen so aktualisieren:

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

Dies führt zu einem anderen Verhalten, nämlich zum Überschreiben des gesamten /fireblog/users-Knotens:

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

Daten mit bedingten Anfragen aktualisieren

1. Wenn Sie eine bedingte Anfrage an einem Ort ausführen möchten, rufen Sie die eindeutige Kennung für die aktuellen Daten an diesem Ort ab, also das ETag. Wenn sich die Daten an diesem Speicherort ändern, ändert sich auch das ETag. Sie können ein ETag mit jeder Methode außer PATCH anfordern. Im folgenden Beispiel wird eine GET-Anfrage verwendet.

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

   Wenn Sie das ETag im Header aufrufen, wird das ETag des angegebenen Standorts in der HTTP-Antwort zurückgegeben.

   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. Fügen Sie das zurückgegebene ETag in Ihre nächste PUT- oder DELETE-Anfrage ein, um Daten zu aktualisieren, die genau diesem ETag-Wert entsprechen. Um den Zähler auf 11 zu aktualisieren (also um 1 zu erhöhen) und die Anfrage abzulehnen, wenn der Wert nicht mehr übereinstimmt, verwenden Sie den folgenden Code:

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

   Wenn der Wert der Daten am angegebenen Speicherort weiterhin 10 ist, stimmt das ETag in der PUT-Anfrage überein und die Anfrage ist erfolgreich. Der Wert 11 wird in die Datenbank geschrieben.

   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

   Wenn der Speicherort nicht mehr mit dem ETag übereinstimmt, was passieren kann, wenn ein anderer Nutzer einen neuen Wert in die Datenbank geschrieben hat, schlägt die Anfrage fehl, ohne dass etwas an den Speicherort geschrieben wird. Die Rückgabeantwort enthält den neuen Wert und das 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. Verwenden Sie die neuen Informationen, wenn Sie die Anfrage noch einmal senden. Realtime Database wiederholt fehlgeschlagene bedingte Anfragen nicht automatisch. Sie können den neuen Wert und das ETag jedoch verwenden, um eine neue bedingte Anfrage mit den Informationen zu erstellen, die in der Fehlerantwort zurückgegeben werden.

REST-basierte bedingte Anfragen implementieren den HTTP-Standard if-match. Sie weichen jedoch in folgenden Punkten vom Standard ab:

• Sie können für jede „If-Match“-Anfrage nur einen ETag-Wert angeben, nicht mehrere.
• Der Standard sieht vor, dass ETags mit allen Anfragen zurückgegeben werden. In der Realtime Database werden ETags jedoch nur mit Anfragen zurückgegeben, die den Header X-Firebase-ETag enthalten. Dadurch werden die Abrechnungskosten für Standardanfragen gesenkt.

Bedingte Anfragen können auch langsamer als typische REST-Anfragen sein.

Listen mit Daten speichern

Wenn wir für jedes untergeordnete Element, das einer Firebase-Datenbankreferenz hinzugefügt wird, einen eindeutigen, zeitstempelbasierten Schlüssel generieren möchten, können wir eine POST-Anfrage senden. Für unseren users-Pfad war es sinnvoll, eigene Schlüssel zu definieren, da jeder Nutzer einen eindeutigen Nutzernamen hat. Wenn Nutzer jedoch Blogbeiträge in der App hinzufügen, verwenden wir eine POST-Anfrage, um automatisch einen Schlüssel für jeden Blogbeitrag zu generieren:

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

Unser Pfad posts enthält jetzt die folgenden Daten:

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

Der Schlüssel -JSOpn9ZC54A4P4RoqVa wurde automatisch für uns generiert, da wir eine POST-Anfrage verwendet haben. Eine erfolgreiche Anfrage wird durch einen 200 OK-HTTP-Statuscode angezeigt. Die Antwort enthält den Schlüssel der neuen Daten, die hinzugefügt wurden:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

Daten entfernen

Um Daten aus der Datenbank zu entfernen, können wir eine DELETE-Anfrage mit der URL des Pfads senden, aus dem wir Daten löschen möchten. Mit dem folgenden Befehl würde Alan aus unserem users-Pfad gelöscht:

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

Eine erfolgreiche DELETE-Anfrage wird durch den HTTP-Statuscode 200 OK mit einer Antwort im JSON-Format null angezeigt.

URI-Parameter

Die REST API akzeptiert die folgenden URI-Parameter beim Schreiben von Daten in die Datenbank:

auth

Mit dem Anfrageparameter auth kann auf Daten zugegriffen werden, die durch Firebase Realtime Database Security Rules geschützt sind. Er wird von allen Anfragetypen unterstützt. Das Argument kann entweder unser Firebase-App-Secret oder ein Authentifizierungstoken sein, das wir im Abschnitt zur Nutzerautorisierung behandeln. Im folgenden Beispiel senden wir eine POST-Anfrage mit dem Parameter auth, wobei CREDENTIAL entweder unser Firebase-App-Secret oder ein Authentifizierungstoken ist:

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

ausgeben

Mit dem Parameter print können wir das Format unserer Antwort aus der Datenbank angeben. Wenn wir unserer Anfrage print=pretty hinzufügen, werden die Daten in einem für Menschen lesbaren Format zurückgegeben. print=pretty wird von GET-, PUT-, POST-, PATCH- und DELETE-Anfragen unterstützt.

Wenn wir die Ausgabe des Servers beim Schreiben von Daten unterdrücken möchten, können wir unserer Anfrage print=silent hinzufügen. Die resultierende Antwort ist leer und wird durch einen 204 No Content-HTTP-Statuscode angezeigt, wenn die Anfrage erfolgreich ist. Die print=silent wird von GET-, PUT-, POST- und PATCH-Anfragen unterstützt.

Serverwerte schreiben

Serverwerte können an einem Ort mit einem Platzhalterwert geschrieben werden. Das ist ein Objekt mit einem einzelnen ".sv"-Schlüssel. Der Wert für diesen Schlüssel ist der Typ des Serverwerts, den wir festlegen möchten. Wenn Sie beispielsweise einen Zeitstempel für die Erstellung eines Nutzers festlegen möchten, können Sie Folgendes tun:

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

"timestamp" ist der einzige unterstützte Serverwert und gibt die Zeit seit der UNIX-Epoche in Millisekunden an.

Schreibleistung verbessern

Wenn wir große Datenmengen in die Datenbank schreiben, können wir den Parameter print=silent verwenden, um die Schreibgeschwindigkeit zu verbessern und die Bandbreitennutzung zu verringern. Beim normalen Schreibvorgang antwortet der Server mit den geschriebenen JSON-Daten. Wenn print=silent angegeben ist, schließt der Server die Verbindung sofort nach dem Empfang der Daten, wodurch die Bandbreitennutzung reduziert wird.

Wenn wir viele Anfragen an die Datenbank senden, können wir die HTTPS-Verbindung wiederverwenden, indem wir eine Keep-Alive-Anfrage im HTTP-Header senden.

Fehlerbedingungen

Die REST API gibt unter folgenden Umständen Fehlercodes zurück:

Daten sichern

Firebase hat eine Sicherheitssprache, mit der wir definieren können, welche Nutzer Lese- und Schreibzugriff auf verschiedene Knoten unserer Daten haben. Weitere Informationen dazu finden Sie unter Realtime Database Security Rules.