Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

Guardar datos

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Formas de guardar datos

PONER Escriba o reemplace datos en una ruta definida , como fireblog/users/user1/<data>
PARCHE Actualice algunas de las claves para una ruta definida sin reemplazar todos los datos.
CORREO Agregue a una lista de datos en nuestra base de datos de Firebase. Cada vez que enviamos una solicitud POST , el cliente de Firebase genera una clave única, como fireblog/users/<unique-id>/<data>
ELIMINAR Elimina datos de la referencia de base de datos de Firebase especificada.

Escritura de datos con PUT

La operación de escritura básica a través de la API REST es PUT . Para demostrar cómo guardar datos, crearemos una aplicación de blogs con publicaciones y usuarios. Todos los datos de nuestra aplicación se almacenarán en la ruta de `fireblog`, en la URL de la base de datos de Firebase `https://docs-examples.firebaseio.com/fireblog`.

Comencemos guardando algunos datos de usuario en nuestra base de datos de Firebase. Almacenaremos a cada usuario por un nombre de usuario único y también almacenaremos su nombre completo y fecha de nacimiento. Dado que cada usuario tendrá un nombre de usuario único, tiene sentido usar PUT aquí en lugar de POST , ya que ya tenemos la clave y no necesitamos crear una.

Usando PUT , podemos escribir una cadena, un número, un booleano, una matriz o cualquier objeto JSON en nuestra base de datos de Firebase. En este caso le pasaremos un objeto:

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

Cuando un objeto JSON se guarda en la base de datos, las propiedades del objeto se asignan automáticamente a ubicaciones secundarias de forma anidada. Si navegamos al nodo recién creado, veremos el valor "Alan Turing". También podemos guardar datos directamente en una ubicación secundaria:

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'

Los dos ejemplos anteriores (escribir el valor al mismo tiempo que un objeto y escribirlos por separado en ubicaciones secundarias) darán como resultado que se guarden los mismos datos en nuestra base de datos de Firebase:

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

Una solicitud exitosa se indicará con un código de estado HTTP 200 OK y la respuesta contendrá los datos que escribimos en la base de datos. El primer ejemplo solo activará un evento en los clientes que están viendo los datos, mientras que el segundo ejemplo activará dos. Es importante tener en cuenta que si los datos ya existían en la ruta de los usuarios, el primer enfoque los sobrescribiría, pero el segundo método solo modificaría el valor de cada nodo secundario por separado y dejaría a los demás elementos secundarios sin cambios. PUT es equivalente a set() en nuestro SDK de JavaScript.

Actualización de datos con PATCH

Usando una solicitud PATCH , podemos actualizar niños específicos en una ubicación sin sobrescribir los datos existentes. Agreguemos el apodo de Turing a sus datos de usuario con una solicitud PATCH :

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

La solicitud anterior escribirá un nickname para nuestro objeto alanisawesome sin eliminar el name o los niños que cumplen birthday . Tenga en cuenta que si hubiéramos emitido una solicitud PUT aquí, el name y el birthday se habrían eliminado ya que no estaban incluidos en la solicitud. Los datos en nuestra base de datos de Firebase ahora se ven así:

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

Una solicitud exitosa se indicará mediante un código de estado HTTP 200 OK y la respuesta contendrá los datos actualizados escritos en la base de datos.

Firebase también admite actualizaciones de rutas múltiples. Esto significa que PATCH ahora puede actualizar valores en varias ubicaciones en su base de datos de Firebase al mismo tiempo, una característica poderosa que le permite desnormalizar sus datos . Usando actualizaciones de rutas múltiples, podemos agregar apodos tanto a Alan como a Grace al mismo tiempo:

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

Después de esta actualización, tanto a Alan como a Grace se les agregaron sus apodos:

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

Tenga en cuenta que tratar de actualizar objetos escribiendo objetos con las rutas incluidas dará como resultado un comportamiento diferente. Echemos un vistazo a lo que sucede si, en cambio, intentamos actualizar a Grace y Alan de esta manera:

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

Esto da como resultado un comportamiento diferente, es decir, sobrescribir todo el /fireblog/users :

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

Actualización de datos con solicitudes condicionales

Puede utilizar solicitudes condicionales, el equivalente REST a las transacciones, para actualizar los datos de acuerdo con su estado actual. Por ejemplo, si desea aumentar un contador de votos a favor y quiere asegurarse de que el recuento refleje con precisión varios votos a favor simultáneos, utilice una solicitud condicional para escribir el nuevo valor en el contador. En lugar de dos escrituras que cambian el contador al mismo número, una de las solicitudes de escritura falla y luego puede volver a intentar la solicitud con el nuevo valor.
  1. Para realizar una solicitud condicional en una ubicación, obtenga el identificador único de los datos actuales en esa ubicación o la ETag. Si los datos cambian en esa ubicación, la ETag también cambia. Puede solicitar una ETag con cualquier método que no sea PATCH . El siguiente ejemplo utiliza una solicitud GET .
    curl -i 'https://test.example.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
    
    específicamente a la ETag en el encabezado devuelve la ETag de la ubicación especificada en la respuesta 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. Incluya la ETag devuelta en su próxima solicitud PUT o DELETE para actualizar los datos que coincidan específicamente con ese valor de ETag. Siguiendo nuestro ejemplo, para actualizar el contador a 11, o 1 mayor que el valor obtenido inicial de 10, y fallar la solicitud si el valor ya no coincide, use el siguiente código:
    curl -iX PUT -d '11' 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'if-match:[ETAG_VALUE]'
    
    Si el valor de los datos en el especificado la ubicación sigue siendo 10, la ETag en la solicitud PUT coincide y la solicitud tiene éxito, escribiendo 11 en la base de datos.
    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 la ubicación ya no coincide con la ETag, lo que podría ocurrir si otro usuario escribiera un nuevo valor en la base de datos, la solicitud falla sin escribir en la ubicación. La respuesta de retorno incluye el nuevo valor y la 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. Utilice la nueva información si decide volver a intentar la solicitud. Realtime Database no vuelve a intentar automáticamente las solicitudes condicionales que han fallado. Sin embargo, puede usar el nuevo valor y la ETag para crear una nueva solicitud condicional con la información devuelta por la respuesta fallida.

Las solicitudes condicionales basadas en REST implementan el estándar HTTP if-match . Sin embargo, se diferencian del estándar en los siguientes aspectos:

  • Solo puede proporcionar un valor de ETag para cada solicitud de coincidencia, no varias.
  • Si bien el estándar sugiere que se devuelvan ETags con todas las solicitudes, Realtime Database solo devuelve ETags con solicitudes que incluyan el encabezado X-Firebase-ETag . Esto reduce los costes de facturación de las solicitudes estándar.

Las solicitudes condicionales también pueden ser más lentas que las solicitudes REST típicas.

Guardar listas de datos

Para generar una clave única basada en una marca de tiempo para cada niño agregado a una referencia de base de datos de Firebase, podemos enviar una solicitud POST . Para la ruta de nuestros users , tenía sentido definir nuestras propias claves ya que cada usuario tiene un nombre de usuario único. Pero cuando los usuarios agreguen publicaciones de blog a la aplicación, usaremos una solicitud POST para generar automáticamente una clave para cada publicación de blog:

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

Nuestra ruta de posts ahora tiene los siguientes datos:

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

Tenga en cuenta que la clave -JSOpn9ZC54A4P4RoqVa se generó automáticamente para nosotros porque usamos una solicitud POST . Una solicitud exitosa se indicará con un código de estado HTTP 200 OK y la respuesta contendrá la clave de los nuevos datos que se agregaron:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

Eliminación de datos

Para eliminar datos de la base de datos, podemos enviar una solicitud DELETE con la URL de la ruta de la que nos gustaría eliminar los datos. Lo siguiente eliminaría a Alan de nuestra ruta de users :

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

Una solicitud de DELETE exitosa se indicará mediante un código de estado HTTP 200 OK con una respuesta que contiene JSON null .

Parámetros de URI

La API REST acepta los siguientes parámetros de URI al escribir datos en la base de datos:

autenticación

El parámetro de solicitud de auth permite el acceso a los datos protegidos por las reglas de base de datos en tiempo real de Firebase y es compatible con todos los tipos de solicitudes. El argumento puede ser nuestro secreto de la aplicación Firebase o un token de autenticación, que trataremos en la sección de autorización del usuario . En el siguiente ejemplo, enviamos una solicitud POST con un parámetro de auth , donde CREDENTIAL es nuestro secreto de aplicación de Firebase o un token de autenticación:

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

impresión

El parámetro de print nos permite especificar el formato de nuestra respuesta desde la base de datos. Agregar print=pretty a nuestra solicitud devolverá los datos en un formato legible por humanos. print=pretty es compatible con las solicitudes GET , PUT , POST , PATCH y DELETE .

Para suprimir la salida del servidor al escribir datos, podemos agregar print=silent a nuestra solicitud. La respuesta resultante estará vacía y se indicará con un código de estado HTTP 204 No Content si la solicitud es exitosa. print=silent es compatible con las solicitudes GET , PUT , POST y PATCH .

Escritura de valores del servidor

Los valores del servidor se pueden escribir en una ubicación mediante un valor de marcador de posición, que es un objeto con una única clave ".sv" . El valor de esa clave es el tipo de valor de servidor que deseamos establecer. Por ejemplo, para establecer una marca de tiempo cuando se crea un usuario, podríamos hacer lo siguiente:

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

"timestamp" es el único valor de servidor admitido y es el tiempo desde la época de UNIX en milisegundos.

Mejora del rendimiento de escritura

Si estamos escribiendo grandes cantidades de datos en la base de datos, podemos usar el parámetro print=silent para mejorar nuestro rendimiento de escritura y disminuir el uso de ancho de banda. En el comportamiento de escritura normal, el servidor responde con los datos JSON que se escribieron. Cuando se especifica print=silent , el servidor cierra inmediatamente la conexión una vez que se reciben los datos, lo que reduce el uso de ancho de banda.

En los casos en los que hacemos muchas solicitudes a la base de datos, podemos reutilizar la conexión HTTPS enviando una solicitud Keep-Alive en el encabezado HTTP.

Condiciones de error

La API REST devolverá códigos de error en estas circunstancias:

Códigos de estado HTTP
400 Solicitud incorrecta

Una de las siguientes condiciones de error:

  • No se pueden analizar los datos PUT o POST .
  • Faltan datos PUT o POST .
  • La solicitud intenta PUT o POST datos que son demasiado grandes.
  • La llamada a la API REST contiene nombres secundarios no válidos como parte de la ruta.
  • La ruta de llamada de la API REST es demasiado larga.
  • La solicitud contiene un valor de servidor no reconocido.
  • El índice de la consulta no está definido en las reglas de Firebase Realtime Database .
  • La solicitud no admite uno de los parámetros de consulta especificados.
  • La solicitud combina parámetros de consulta con una solicitud GET superficial.
401 no autorizado

Una de las siguientes condiciones de error:

404 No encontrado No se encontró la base de datos de Firebase especificada.
500 Error interno del servidor El servidor devolvió un error. Consulte el mensaje de error para obtener más detalles.
503 Servicio no disponible La base de datos en tiempo real de Firebase especificada no está disponible temporalmente, lo que significa que no se intentó realizar la solicitud.

Protección de datos

Firebase tiene un lenguaje de seguridad que nos permite definir qué usuarios tienen acceso de lectura y escritura a diferentes nodos de nuestros datos. Puede obtener más información al respecto en Reglas de la base de datos en tiempo real .

Ahora que hemos cubierto cómo guardar datos, podemos aprender cómo recuperar nuestros datos de la base de datos de Firebase a través de la API REST en la siguiente sección.