La sauvegarde des données

Façons d'enregistrer des données

METTRE Ecrire ou remplacer les données à un chemin défini, comme fireblog/users/user1/<data>
PIÈCE Mettez à jour certaines des clés pour un chemin défini sans remplacer toutes les données.
PUBLIER Ajouter à la liste des données dans notre base de données Firebase. Chaque fois que nous envoyons un POST demande, le client Firebase génère une clé unique, comme fireblog/users/<unique-id>/<data>
EFFACER Supprimez les données de la référence de base de données Firebase spécifiée.

Écrire des données avec PUT

L'opération d'écriture de base via l'API REST est PUT . Pour démontrer la sauvegarde des données, nous allons créer une application de blog avec des publications et des utilisateurs. Toutes les données de notre application seront stockées sous le chemin de `fireblog`, à l'URL de la base de données Firebase `https://docs-examples.firebaseio.com/fireblog`.

Commençons par enregistrer certaines données utilisateur dans notre base de données Firebase. Nous stockerons chaque utilisateur sous un nom d'utilisateur unique, et nous stockerons également son nom complet et sa date de naissance. Étant donné que chaque utilisateur aura un nom d' utilisateur unique, il est logique d'utiliser PUT ici au lieu de POST puisque nous avons déjà la clé et ne pas besoin de créer un.

En utilisant PUT , on peut écrire une chaîne, nombre, booléen, tableau ou un objet JSON à notre base de données Firebase. Dans ce cas, nous lui passerons un objet :

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

Lorsqu'un objet JSON est enregistré dans la base de données, les propriétés de l'objet sont automatiquement mappées aux emplacements enfants de manière imbriquée. Si nous naviguons vers le nœud nouvellement créé, nous verrons la valeur "Alan Turing". Nous pouvons également enregistrer des données directement dans un emplacement enfant :

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'

Les deux exemples ci-dessus (écrire la valeur en même temps qu'un objet et les écrire séparément dans les emplacements enfants) entraîneront l'enregistrement des mêmes données dans notre base de données Firebase :

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

Une demande réussie sera indiquée par un 200 OK code d'état HTTP et la réponse contiendra les données que nous avons écrit à la base de données. Le premier exemple ne déclenchera qu'un événement sur les clients qui surveillent les données, tandis que le deuxième exemple en déclenchera deux. Il est important de noter que si des données existaient déjà sur le chemin des utilisateurs, la première approche les écraserait, mais la deuxième méthode modifierait uniquement la valeur de chaque nœud enfant séparé tout en laissant les autres enfants inchangés. PUT équivaut à set() dans notre SDK JavaScript.

Mise à jour des données avec PATCH

L' utilisation d' un PATCH demande, nous pouvons mettre à jour les enfants spécifiques à un endroit sans écraser les données existantes. Ajoutons le surnom de ses données à Turing utilisateur avec une PATCH demande:

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

La demande ci - dessus écrire nickname à notre alanisawesome objet sans supprimer le name ou d' birthday des enfants. Notez que si nous avions publié une PUT demande ici au lieu, name et birthday auraient été supprimées car elles ne sont pas incluses dans la demande. Les données de notre base de données Firebase ressemblent maintenant à ceci :

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

Une demande réussie sera indiquée par un 200 OK code d'état HTTP et la réponse contiendra les données mises à jour par écrit à la base de données.

Firebase prend également en charge les mises à jour multi-chemins. Cela signifie que PATCH peut maintenant mettre à jour les valeurs à plusieurs endroits dans votre base de données Firebase en même temps, une fonctionnalité puissante qui permet vous aide à dénormaliser vos données . En utilisant les mises à jour multi-chemins, nous pouvons ajouter des surnoms à Alan et Grace en même temps :

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

Après cette mise à jour, Alan et Grace ont tous deux vu leurs surnoms ajoutés :

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

Notez qu'essayer de mettre à jour des objets en écrivant des objets avec les chemins inclus entraînera un comportement différent. Voyons ce qui se passe si nous essayons plutôt de mettre à jour Grace et Alan de cette façon :

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

Cela se traduit par un comportement différent, à savoir l'ensemble écrasant /fireblog/users noeud:

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

Mise à jour des données avec des requêtes conditionnelles

Vous pouvez utiliser des requêtes conditionnelles, l'équivalent REST des transactions, pour mettre à jour les données en fonction de leur état existant. Par exemple, si vous souhaitez augmenter un compteur de votes positifs et vous assurer que le nombre reflète avec précision plusieurs votes positifs simultanés, utilisez une demande conditionnelle pour écrire la nouvelle valeur dans le compteur. Au lieu de deux écritures qui modifient le compteur au même nombre, l'une des demandes d'écriture échoue et vous pouvez alors réessayer la demande avec la nouvelle valeur.
  1. Pour effectuer une demande conditionnelle à un emplacement, obtenez l'identifiant unique des données actuelles à cet emplacement, ou l'ETag. Si les données changent à cet emplacement, l'ETag change également. Vous pouvez demander un ETag avec une méthode autre que PATCH . L'exemple suivant utilise une GET demande.
    curl -i 'https://test.example.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
    
    appel Spécifiquement , le ETag dans les rendements d' en- tête de l'ETAG l'emplacement spécifié dans la réponse 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. Inclure le ETag retourné dans votre prochaine PUT ou DELETE demande de données de mise à jour qui correspond précisément cette valeur ETag. Dans notre exemple, de mettre à jour le compteur à 11, ou 1 supérieure à la valeur récupérée initiale de 10, et l' échec de la demande si la valeur ne correspond plus, utilisez le code suivant:
    curl -iX PUT -d '11' 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'if-match:[ETAG_VALUE]'
    
    Si la valeur des données à l' endroit spécifié l' emplacement est encore 10, le ETag dans les PUT matches de demande, et la demande parvient, l' écriture 11 à la base de données.
    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
    
    Si l'emplacement ne correspond plus au ETag, ce qui pourrait se produire si un autre utilisateur a écrit une nouvelle valeur à la base de données, la requête échoue sans écrire à l'emplacement. La réponse de retour inclut la nouvelle valeur et 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. Utilisez les nouvelles informations si vous décidez de réessayer la demande. Realtime Database ne réessaye pas automatiquement les requêtes conditionnelles qui ont échoué. Cependant, vous pouvez utiliser la nouvelle valeur et ETag pour créer une nouvelle demande conditionnelle avec les informations renvoyées par la réponse d'échec.

Demandes conditionnelles à base de REST mettre en œuvre le protocole HTTP si match standard. Cependant, ils diffèrent de la norme sur les points suivants :

  • Vous ne pouvez fournir qu'une seule valeur ETag pour chaque requête if-match, pas plusieurs.
  • Bien que la norme suggère que ETags être retournés avec toutes les demandes, la base de données en temps réel ne retourne que ETags avec des demandes dont le X-Firebase-ETag tête. Cela réduit les coûts de facturation pour les demandes standard.

Les requêtes conditionnelles peuvent également être plus lentes que les requêtes REST classiques.

Enregistrement de listes de données

Pour générer une clé unique par estampille pour chaque enfant ajouté à une référence de base de données Firebase nous pouvons envoyer un POST demande. Pour notre users chemin, il était logique de définir nos propres clés puisque chaque utilisateur dispose d' un nom d' utilisateur unique. Mais lorsque les utilisateurs ajoutent les messages de blog à l'application, nous allons utiliser un POST demande pour générer automatiquement une clé pour chaque billet de blog:

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

Notre posts chemin a maintenant les données suivantes:

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

Notez que la clé -JSOpn9ZC54A4P4RoqVa a été généré automatiquement pour nous parce que nous avons utilisé un POST demande. Une demande réussie sera indiquée par un 200 OK code d'état HTTP et la réponse contiendra la clé des nouvelles données qui ont été ajoutées:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

Suppression de données

Pour supprimer les données de la base de données, nous pouvons envoyer une DELETE demande avec l'URL du chemin à partir de laquelle nous aimerions supprimer des données. Ce qui suit supprimerait Alan de notre users chemin:

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

Un succès DELETE demande sera indiquée par un 200 OK code d'état HTTP avec une réponse contenant JSON null .

Paramètres d'URI

L'API REST accepte les paramètres URI suivants lors de l'écriture de données dans la base de données :

authentification

Le auth paramètre de requête permet d' accéder aux données protégées par Firebase en temps réel les règles de base de données , et est pris en charge par tous les types de demande. L'argument peut être notre secret d'application Firebase ou un jeton d' authentification, que nous allons couvrir dans la section d'autorisation de l' utilisateur . Dans l'exemple suivant , nous envoyons un POST demande avec un auth paramètre, où CREDENTIAL est soit notre secret d'application Firebase ou un jeton d' authentification:

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

imprimer

L' print paramètre nous permet de spécifier le format de notre réponse de la base de données. Ajout d' print=pretty à notre demande renverra les données dans un format lisible par l' homme. print=pretty est pris en charge par GET , PUT , POST , PATCH et DELETE demandes.

Pour supprimer la sortie du serveur lors de l' écriture des données, nous pouvons ajouter l' print=silent à notre demande. La réponse résultante sera vide et indiquée par un 204 No Content de 204 No Content code d'état HTTP si la demande est acceptée. L' print=silent est prise en charge par GET , PUT , POST et PATCH demandes.

Écriture de valeurs de serveur

Les valeurs de serveur peuvent être écrites à un emplacement en utilisant une valeur d'espace réservé, qui est un objet avec un seul ".sv" clé. La valeur de cette clé est le type de valeur de serveur que nous souhaitons définir. Par exemple, pour définir un horodatage lorsqu'un utilisateur est créé, nous pouvons procéder comme suit :

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

"timestamp" est la seule valeur de serveur pris en charge, et est le temps écoulé depuis l'époque UNIX en millisecondes.

Amélioration des performances d'écriture

Si nous écrivons de grandes quantités de données à la base de données, nous pouvons utiliser l' print=silent paramètre pour améliorer nos performances d'écriture et l' utilisation de la bande passante de diminution. Dans le comportement d'écriture normal, le serveur répond avec les données JSON qui ont été écrites. Lorsque l' print=silent est spécifié, le serveur ferme immédiatement la connexion une fois que les données sont reçues, ce qui réduit l' utilisation de la bande passante.

Dans les cas où nous faisons de nombreuses demandes de la base de données, nous pouvons réutiliser la connexion HTTPS en envoyant un Keep-Alive demande dans l' en- tête HTTP.

Conditions d'erreur

L'API REST renverra des codes d'erreur dans les circonstances suivantes :

Codes d'état HTTP
400 Bad Request

L'une des conditions d'erreur suivantes :

  • Impossible d'analyser PUT ou POST données.
  • Manquant PUT ou POST données.
  • Les tentatives de demande PUT ou POST données est trop grande.
  • L'appel de l'API REST contient des noms d'enfant non valides dans le chemin.
  • Le chemin d'appel de l'API REST est trop long.
  • La demande contient une valeur de serveur non reconnue.
  • L'indice de la requête n'est pas défini dans vos Firebase en temps réel les règles de base de données .
  • La demande ne prend pas en charge l'un des paramètres de requête spécifiés.
  • Les mélanges de demande des paramètres de requête avec une faible profondeur GET demande.
401 Unauthorized

L'une des conditions d'erreur suivantes :

  • Le jeton d'authentification a expiré.
  • Le jeton d'authentification utilisé dans la demande n'est pas valide.
  • L'authentification avec un access_token a échoué.
  • La demande viole vos Firebase en temps réel les règles de base de données.
404 Not Found La base de données Firebase spécifiée est introuvable.
500 Internal Server Error Le serveur a renvoyé une erreur. Voir le message d'erreur pour plus de détails.
503 Service Unavailable La base de données Firebase Realtime spécifiée est temporairement indisponible, ce qui signifie que la requête n'a pas été tentée.

Sécurisation des données

Firebase dispose d'un langage de sécurité qui nous permet de définir quels utilisateurs ont un accès en lecture et en écriture aux différents nœuds de nos données. Vous pouvez en lire davantage en temps réel les règles de base de données .

Maintenant que nous avons couvert l'enregistrement des données, nous pouvons apprendre à récupérer nos données de la base de données Firebase via l'API REST dans la section suivante.