Risparmio di dati

Scrittura dei dati con PUT

L'operazione di scrittura di base tramite l'API REST è PUT. Per dimostrare come salvare i dati, creeremo un'applicazione di blogging con post e utenti. Tutti i dati della nostra applicazione verranno archiviati nel percorso di "fireblog", all'URL del database Firebase "https://docs-examples.firebaseio.com/fireblog".

Iniziamo salvando alcuni dati utente nel nostro database Firebase. Memorizzeremo ogni utente tramite un nome utente unico, nonché il nome completo e la data di nascita. Poiché ogni utente avrà un nome utente unico, ha senso utilizzare PUT qui anziché POST poiché abbiamo già la chiave e non è necessario crearne una.

Utilizzando PUT, possiamo scrivere una stringa, un numero, un valore booleano, un array o qualsiasi oggetto JSON nel nostro database Firebase. In questo caso, gli passeremo un oggetto:

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

Quando un oggetto JSON viene salvato nel database, le proprietà dell'oggetto vengono mappate automaticamente alle posizioni secondarie in modo nidificato. Se andiamo al nodo appena creato, vedremo il valore "Alan Turing". Possiamo anche salvare i dati direttamente in una posizione secondaria:

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'

I due esempi precedenti, ovvero scrivere il valore contemporaneamente a un oggetto e scriverli separatamente nelle posizioni secondarie, faranno sì che gli stessi dati vengano salvati nel nostro database Firebase:

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

Una richiesta andata a buon fine sarà indicata da un codice di stato HTTP 200 OK e la risposta conterrà i dati che abbiamo scritto nel database. Il primo esempio attiverà solo un evento sui client che monitorano i dati, mentre il secondo attiverà due eventi. È importante notare che se i dati esistevano già nel percorso dell'utente, il primo approccio li sovrascriverebbe, ma il secondo metodo modificherebbe solo il valore di ogni nodo secondario separato lasciando invariati gli altri nodi secondari. PUT equivale a set() nel nostro SDK JavaScript.

Aggiornamento dei dati con PATCH

Utilizzando una richiesta PATCH, possiamo aggiornare bambini specifici in una località senza sovrascrivere i dati esistenti. Aggiungiamo il nickname di Turing ai suoi dati utente con una richiesta PATCH:

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

La richiesta riportata sopra scrive nickname nell'oggetto alanisawesome senza eliminare gli elementi secondari name o birthday. Tieni presente che se avessero emesso una richiesta PUT, name e birthday sarebbero stati eliminati poiché non erano inclusi nella richiesta. I dati nel nostro database Firebase ora sono così:

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

Una richiesta riuscita sarà indicata da un codice di stato HTTP 200 OK e la risposta conterrà i dati aggiornati scritti nel database.

Firebase supporta anche gli aggiornamenti multipath. Ciò significa che PATCH ora può aggiornare contemporaneamente i valori in più posizioni del database Firebase, una funzionalità potente che ti consente di denormalizzare i dati. Utilizzando gli aggiornamenti multipath, possiamo aggiungere contemporaneamente i nickname sia ad Alan che a Grace:

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

Dopo questo aggiornamento, sono stati aggiunti i nickname di Alan e Grace:

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

Tieni presente che il tentativo di aggiornare gli oggetti scrivendoli con i percorsi inclusi avrà un comportamento diverso. Vediamo cosa succede se proviamo ad aggiornare Grace e Alan in questo modo:

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

Il risultato è un comportamento diverso, ovvero l'intera sovrascrittura del nodo /fireblog/users:

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

Aggiornamento dei dati con richieste condizionali

1. Per eseguire una richiesta condizionale in una posizione, recupera l'identificatore univoco per i dati correnti in quella posizione o l'ETag. Se i dati cambiano in quella posizione, cambia anche l'ETag. Puoi richiedere un ETag con qualsiasi metodo diverso da PATCH. L'esempio seguente utilizza una richiesta GET.

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

   Nello specifico, la chiamata all'ETag nell'intestazione restituisce l'ETag della posizione specificata nella risposta 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. Includi l'ETag restituito nella prossima richiesta PUT o DELETE per aggiornare i dati che corrispondono specificamente a quel valore ETag. Seguendo il nostro esempio, per aggiornare il contatore su 11, ovvero 1 in più rispetto al valore iniziale recuperato di 10, e interrompere la richiesta se il valore non corrisponde più, utilizza il seguente codice:

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

   Se il valore dei dati nella posizione specificata è ancora 10, l'ETag nella PUT richiesta corrisponde e la richiesta va a buon fine, scrivendo 11 nel database.

   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
   

   Se la posizione non corrisponde più all'ETag, il che potrebbe verificarsi se un altro utente ha scritto un nuovo valore nel database, la richiesta non va a buon fine senza scrivere nella posizione. La risposta di ritorno include il nuovo valore e 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. Utilizza le nuove informazioni se decidi di riprovare a inviare la richiesta. Realtime Database non tenta automaticamente di nuovo le richieste condizionali non riuscite. Tuttavia, puoi utilizzare il nuovo valore e l'ETag per creare una nuova richiesta condizionale con le informazioni restituite dalla risposta di errore.

Le richieste condizionali basate su REST implementano lo standard HTTP if-match. Tuttavia, differiscono dallo standard nei seguenti modi:

• Puoi fornire un solo valore ETag per ogni richiesta if-match, non più di uno.
• Sebbene lo standard suggerisca di restituire gli ETag con tutte le richieste, il database in tempo reale restituisce gli ETag solo con le richieste che includono l'intestazione X-Firebase-ETag. In questo modo, i costi di fatturazione per le richieste standard vengono ridotti.

Inoltre, le richieste condizionali potrebbero essere più lente delle normali richieste REST.

Salvare elenchi di dati

Per generare una chiave univoca basata su timestamp per ogni elemento secondario aggiunto a un riferimento del database Firebase, possiamo inviare una richiesta POST. Per il nostro percorso users, aveva senso definire le nostre chiavi poiché ogni utente ha un nome utente univoco. Tuttavia, quando gli utenti aggiungono post del blog all'app, utilizzeremo una richiesta POST per generare automaticamente una chiave per ogni post del blog:

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

Il nostro percorso posts ora contiene i seguenti dati:

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

Tieni presente che la chiave -JSOpn9ZC54A4P4RoqVa è stata generata automaticamente per noi perché abbiamo utilizzato una richiesta POST. Una richiesta andata a buon fine sarà indicata da un codice di stato HTTP 200 OK e la risposta conterrà la chiave dei nuovi dati aggiunti:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

Rimozione dei dati

Per rimuovere i dati dal database, possiamo inviare una richiesta DELETE con l'URL del percorso da cui vogliamo eliminare i dati. Il seguente comando eliminerà Alan dal nostro percorso users:

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

Una richiesta DELETE riuscita sarà indicata da un codice di stato HTTP 200 OK con una risposta contenente JSON null.

Parametri URI

L'API REST accetta i seguenti parametri URI durante la scrittura dei dati nel database:

auth

Il parametro di richiesta auth consente di accedere ai dati protetti da Firebase Realtime Database Security Rules ed è supportato da tutti i tipi di richiesta. L'argomento può essere il nostro segreto dell'app Firebase o un token di autenticazione, che tratteremo nella sezione sull'autorizzazione degli utenti. Nell'esempio seguente inviamo una richiesta POST con un parametro auth, dove CREDENTIAL è il nostro secret dell'app Firebase o un token di autenticazione:

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

stampa

Il parametro print ci consente di specificare il formato della risposta del database. L'aggiunta di print=pretty alla nostra richiesta restituirà i dati in un formato leggibile. print=pretty è supportato dalle richieste GET, PUT, POST, PATCH e DELETE.

Per eliminare l'output del server durante la scrittura dei dati, possiamo aggiungere print=silent alla nostra richiesta. La risposta risultante sarà vuota e indicata da un codice di stato HTTP 204 No Content se la richiesta va a buon fine. print=silent è supportato dalle richieste GET, PUT, POST e PATCH.

Scrivere i valori del server

I valori del server possono essere scritti in una posizione utilizzando un valore segnaposto, ovvero un oggetto con una singola chiave ".sv". Il valore della chiave è il tipo di valore del server che vogliamo impostare. Ad esempio, per impostare un timestamp quando viene creato un utente, potremmo procedere nel seguente modo:

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

"timestamp" è l'unico valore del server supportato ed è il tempo in millisecondi dall'epoca UNIX.

Migliorare le prestazioni di scrittura

Se stiamo scrivendo grandi quantità di dati nel database, possiamo utilizzare il parammetro print=silent per migliorare le prestazioni di scrittura e ridurre l'utilizzo della larghezza di banda. Nel normale comportamento di scrittura, il server risponde con i dati JSON che sono stati scritti. Quando viene specificato print=silent, il server chiude immediatamente la connessione al termine della ricezione dei dati, riducendo l'utilizzo della larghezza di banda.

Se inviamo molte richieste al database, possiamo riutilizzare la connessione HTTPS inviando una richiesta Keep-Alive nell'intestazione HTTP.

Condizioni di errore

L'API REST restituirà codici di errore nelle seguenti circostanze:

Protezione dei dati

Firebase dispone di un linguaggio di sicurezza che ci consente di definire quali utenti hanno accesso in lettura e scrittura a diversi nodi dei nostri dati. Per saperne di più, consulta Realtime Database Security Rules.