Enregistrement des données

Écrire des données avec PUT

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

Commençons par enregistrer des données utilisateur dans notre base de données Firebase. Nous allons stocker chaque utilisateur par un nom d'utilisateur unique ainsi que son nom complet et sa date de naissance. Comme chaque utilisateur aura un nom d'utilisateur unique, il est logique d'utiliser PUT au lieu de POST, car nous disposons déjà de la clé et n'avons pas besoin d'en créer une.

Avec PUT, nous pouvons écrire une chaîne, un nombre, une valeur booléenne, un tableau ou n'importe quel objet JSON dans notre base de données Firebase. Dans ce cas, nous allons lui transmettre 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 sur des emplacements enfants de manière imbriquée. Si nous accédons au 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 (écriture de la valeur en même temps qu'un objet et écriture séparée dans des emplacements enfants) entraînent 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 requête réussie est indiquée par un code d'état HTTP 200 OK, et la réponse contient les données que nous avons écrites dans la base de données. Le premier exemple ne déclenche qu'un seul événement sur les clients qui surveillent les données, tandis que le second en déclenche deux. Il est important de noter que si des données existaient déjà dans le chemin d'accès des utilisateurs, la première approche les écraserait, mais la deuxième méthode ne modifierait que la valeur de chaque nœud enfant distinct sans modifier les autres enfants. PUT est équivalent à set() dans notre SDK JavaScript.

Mettre à jour des données avec PATCH

À l'aide d'une requête PATCH, nous pouvons mettre à jour des enfants spécifiques à un emplacement sans écraser les données existantes. Ajoutons le surnom de Turing à ses données utilisateur avec une PATCH requête :

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

La requête ci-dessus écrit nickname dans notre objet alanisawesome sans supprimer les enfants name ni birthday. Notez que si nous avions émis une requête PUT à la place, name et birthday auraient été supprimés, car ils n'étaient pas inclus dans la requête. Les données de notre base de données Firebase se présentent désormais comme suit :

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

Une requête réussie est indiquée par un code d'état HTTP 200 OK, et la réponse contient les données mises à jour écrites dans la base de données.

Firebase est également compatible avec les mises à jour multi-chemins. Cela signifie que PATCH peut désormais mettre à jour des valeurs à plusieurs emplacements de votre base de données Firebase en même temps. Il s'agit d'une fonctionnalité puissante qui vous permet de dénormaliser vos données. Grâce aux 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, les surnoms d'Alan et de Grace ont été 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 que si vous essayez de mettre à jour des objets en écrivant des objets avec les chemins d'accès inclus, le comportement sera différent. Voyons ce qui se passe si nous essayons de mettre à jour Grace et Alan de cette manière :

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

Le comportement est différent, à savoir l'écrasement de l'ensemble du nœud /fireblog/users :

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

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

1. Pour effectuer une requête 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 n'importe quelle méthode autre que PATCH. L'exemple suivant utilise une requête GET.

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

   L'appel spécifique de l'ETag dans l'en-tête renvoie l'ETag de 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. Incluez l'ETag renvoyé dans votre prochaine PUT ou DELETE requête pour mettre à jour les données qui correspondent spécifiquement à cette valeur ETag. En suivant notre exemple, pour mettre à jour le compteur sur 11, soit 1 de plus que la valeur initiale récupérée de 10, et faire échouer la requête 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'emplacement spécifié est toujours 10, l'ETag de la requête PUT correspond et la requête réussit, en écrivant 11 dans 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 à l'ETag, ce qui peut se produire si un autre utilisateur a écrit une nouvelle valeur dans la base de données, la requête échoue sans écrire dans l'emplacement. La réponse de retour inclut la nouvelle valeur et l'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 requête. Realtime Database ne retente pas automatiquement les requêtes conditionnelles qui ont échoué. Toutefois, vous pouvez utiliser la nouvelle valeur et l'ETag pour créer une requête conditionnelle avec les informations renvoyées par la réponse d'échec.

Les requêtes conditionnelles basées sur REST implémentent la norme HTTP if-match. Toutefois, elles diffèrent de la norme de la manière suivante :

• Vous ne pouvez fournir qu'une seule valeur ETag pour chaque requête if-match, et non plusieurs.
• Bien que la norme suggère que les ETag soient renvoyés avec toutes les requêtes, Realtime Database ne renvoie les ETag qu'avec les requêtes incluant l'en-tête X-Firebase-ETag Cela réduit les coûts de facturation pour les requêtes standards.

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

Enregistrer des listes de données

Pour générer une clé unique basée sur un horodatage pour chaque enfant ajouté à une référence de base de données Firebase nous pouvons envoyer une requête POST. Pour notre chemin d'accès users, il était logique de définir nos propres clés, car chaque utilisateur possède un nom d'utilisateur unique. Toutefois, lorsque les utilisateurs ajoutent des articles de blog à l' application, nous utilisons une requête POST pour générer automatiquement une clé pour chaque article de blog :

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

Notre chemin d'accès posts contient désormais les données suivantes :

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

Notez que la clé -JSOpn9ZC54A4P4RoqVa a été générée automatiquement, car nous avons utilisé une requête POST. Une requête réussie est indiquée par un code d'état 200 OK HTTP, et la réponse contient la clé des nouvelles données ajoutées :

{"name":"-JSOpn9ZC54A4P4RoqVa"}

Supprimer des données

Pour supprimer des données de la base de données, nous pouvons envoyer une DELETE requête avec l' URL du chemin d'accès à partir duquel nous souhaitons supprimer des données. La commande suivante supprime Alan de notre users chemin d'accès :

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

Une requête DELETE réussie est indiquée par un code d'état HTTP 200 OK avec une réponse contenant JSON null.

Paramètres d'URI

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

auth

Le paramètre de requête auth permet d'accéder aux données protégées par Firebase Realtime Database Security Rules et est compatible avec tous les types de requêtes. L'argument peut être le secret de notre application Firebase ou un jeton d'authentification, que nous aborderons dans la section sur l'autorisation des utilisateurs. Dans l'exemple suivant, nous envoyons une POST requête avec un auth paramètre, où CREDENTIAL est le secret de notre 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

Le paramètre print nous permet de spécifier le format de notre réponse à partir de la base de données. Si nous ajoutons print=pretty à notre requête, les données sont renvoyées dans un format lisible par un humain. print=pretty est compatible avec les requêtes GET, PUT, POST, PATCH et DELETE.

Pour supprimer la sortie du serveur lors de l'écriture de données, nous pouvons ajouter print=silent à notre requête. La réponse obtenue est vide et indiquée par un 204 No Content code d'état HTTP si la requête réussit. Le print=silent est compatible avec les requêtes GET, PUT, POST et PATCH.

Écrire des valeurs de serveur

Les valeurs de serveur peuvent être écrites à un emplacement à l'aide d'une valeur d'espace réservé, qui est un objet avec une seule ".sv" clé. La valeur de cette clé correspond au type de valeur de serveur que nous souhaitons définir. Par exemple, pour définir un horodatage lors de la création d'un utilisateur, 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 compatible. Il s'agit du temps écoulé depuis l'epoch UNIX en millisecondes.

Améliorer les performances d'écriture

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

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

Conditions d'erreur

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

Sécurisation des données

Firebase dispose d'un langage de sécurité qui nous permet de définir les utilisateurs qui ont accès en lecture et en écriture aux différents nœuds de nos données. Pour en savoir plus, consultez Realtime Database Security Rules.