Modi per risparmiare dati |
|
|---|---|
| PUT | Scrivere o sostituire i dati in un percorso definito, ad esempio fireblog/users/user1/<data> |
| PATCH | Aggiorna alcune delle chiavi per un percorso definito senza sostituire tutti i dati. |
| POST | Aggiungere elementi a un elenco di dati nel nostro database Firebase. Ogni volta che inviamo una richiesta POST, il client Firebase genera una chiave univoca, ad esempio fireblog/users/<unique-id>/<data> |
| ELIMINA | Rimuovi i dati dal riferimento al database Firebase specificato. |
Scrittura dei dati con PUT
L'operazione di scrittura di base tramite l'API REST è PUT. Per dimostrare il salvataggio dei dati, creeremo un'applicazione di blogging con post e utenti. Tutti i dati della nostra applicazione verranno archiviati nel percorso "fireblog", all'URL del database Firebase "https://docs-examples.firebaseio.com/fireblog".
Iniziamo salvando alcuni dati utente nel nostro database Firebase. Memorizzeremo ogni utente con un nome utente univoco, oltre al nome completo e alla data di nascita. Poiché ogni utente avrà un nome utente univoco, è opportuno utilizzare PUT qui anziché POST, poiché abbiamo già la chiave e non dobbiamo 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, 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 la scrittura del valore contemporaneamente a un oggetto e la scrittura separata nelle posizioni secondarie, comporteranno il salvataggio degli stessi dati nel nostro database Firebase:
{
"users": {
"alanisawesome": {
"date_of_birth": "June 23, 1912",
"full_name": "Alan Turing"
}
}
}
Una richiesta riuscita verrà indicata da un codice di stato HTTP 200 OK e la risposta conterrà i dati che abbiamo scritto nel database. Il primo esempio attiverà un solo evento sui client che osservano i dati, mentre il secondo ne attiverà due. È importante notare che se i dati esistevano già nel percorso degli utenti, il primo approccio li sovrascriverebbe, mentre 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 elementi secondari specifici in una posizione 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 precedente scriverà nickname nel nostro oggetto alanisawesome senza eliminare gli elementi secondari name o birthday. Tieni presente che se avessimo inviato una richiesta PUT, name e birthday sarebbero stati eliminati perché non erano inclusi nella richiesta. I dati nel nostro database Firebase ora hanno questo aspetto:
{
"users": {
"alanisawesome": {
"date_of_birth": "June 23, 1912",
"full_name": "Alan Turing",
"nickname": "Alan The Machine"
}
}
}
Una richiesta riuscita verrà indicata da un codice di stato HTTP 200 OK e la risposta conterrà i dati aggiornati scritti nel database.
Firebase supporta anche gli aggiornamenti multi-percorso. Ciò significa che PATCH ora può aggiornare i valori in più posizioni nel tuo database Firebase contemporaneamente, una potente funzionalità che ti aiuta a denormalizzare i tuoi dati. Utilizzando gli aggiornamenti multi-percorso, possiamo aggiungere nickname sia ad Alan che a Grace contemporaneamente:
curl -X PATCH -d '{
"alanisawesome/nickname": "Alan The Machine",
"gracehopper/nickname": "Amazing Grace"
}' \
'https://docs-examples.firebaseio.com/fireblog/users.json'
Dopo questo aggiornamento, ad Alan e Grace sono stati aggiunti i nickname:
{
"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 comporterà un comportamento diverso. Vediamo cosa succede se invece 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'
Questo comporta un comportamento diverso, ovvero la sovrascrittura dell'intero nodo /fireblog/users:
{
"users": {
"alanisawesome": {
"nickname": "Alan The Machine"
},
"gracehop": {
"nickname": "Amazing Grace"
}
}
}Aggiornamento dei dati con richieste condizionali
Puoi utilizzare le richieste condizionali, l'equivalente REST delle transazioni, per aggiornare i dati in base al loro stato esistente. Ad esempio, se vuoi aumentare un contatore di upvote e vuoi assicurarti che il conteggio rifletta accuratamente più upvote simultanei, utilizza una richiesta condizionale per scrivere il nuovo valore nel contatore. Anziché due scritture che modificano il contatore con lo stesso numero, una delle richieste di scrittura non va a buon fine e puoi riprovare la richiesta con il nuovo valore.- Per eseguire una richiesta condizionale in una posizione, ottieni 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 richiestaGET.curl -i 'https://test.example.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
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
- Includi l'ETag restituito nella richiesta
PUToDELETEsuccessiva per aggiornare i dati che corrispondono specificamente al valore dell'ETag. Seguendo il nostro esempio, per aggiornare il contatore a 11, ovvero 1 in più rispetto al valore iniziale recuperato di 10, e non riuscire a soddisfare 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]'
PUTcorrisponde 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
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
- Utilizza le nuove informazioni se decidi di riprovare a inviare la richiesta. Realtime Database non riprova automaticamente le richieste condizionali non andate a buon fine. 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 per i seguenti aspetti:
- 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, Realtime Database restituisce gli ETag solo con le richieste che includono l'intestazione
X-Firebase-ETag. In questo modo, i costi fatturati per le richieste standard vengono ridotti.
Le richieste condizionali potrebbero anche essere più lente delle tipiche richieste REST.
Salvataggio di elenchi di dati
Per generare una chiave univoca basata su timestamp per ogni elemento secondario aggiunto a un riferimento al 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 blog post all'app, utilizzeremo una richiesta POST per generare automaticamente una chiave per ogni blog post:
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 verrà 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 elimina Alan dal nostro percorso users:
curl -X DELETE \ 'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome.json'
Una richiesta DELETE riuscita verrà indicata da un codice di stato HTTP 200 OK con una risposta contenente il codice JSON null.
Parametri URI
L'API REST accetta i seguenti parametri URI durante la scrittura dei dati nel database:
autorizzazione
Il parametro di richiesta auth consente l'accesso ai dati protetti da
Firebase Realtime Database Security Rules ed è
supportato da tutti i tipi di richiesta. L'argomento può essere il secret dell'app Firebase o un token di autenticazione, che tratteremo nella sezione relativa all'autorizzazione utente. Nell'esempio seguente inviamo una richiesta POST con un parametro auth, dove CREDENTIAL è il 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 dal 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 dal 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 ha esito positivo.
print=silent è supportato dalle richieste GET, PUT,
POST e PATCH.
Scrittura dei 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 di questa chiave è il tipo di valore del server che vogliamo impostare.
Ad esempio, per impostare un timestamp quando viene creato un utente, possiamo 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 trascorso dall'epoca di Unix in millisecondi.
Miglioramento delle prestazioni di scrittura
Se scriviamo grandi quantità di dati nel database, possiamo utilizzare il parametro print=silent per migliorare le prestazioni di scrittura e ridurre l'utilizzo della larghezza di banda. Nel comportamento di scrittura normale, il server risponde con i dati JSON scritti.
Quando viene specificato print=silent, il server chiude immediatamente la connessione una volta ricevuti i dati, riducendo l'utilizzo della larghezza di banda.
Nei casi in cui effettuiamo molte richieste al database, possiamo riutilizzare la connessione HTTPS inviando una richiesta Keep-Alive nell'intestazione HTTP.
Condizioni di errore
In queste circostanze, l'API REST restituirà i codici di errore:
| Codici di stato HTTP | |
|---|---|
| 400 Richiesta non valida |
Una delle seguenti condizioni di errore:
|
| 401 Non autorizzato |
Una delle seguenti condizioni di errore:
|
| 404 - Non trovato | Il database Firebase specificato non è stato trovato. |
| 500 Errore interno del server | Il server ha restituito un errore. Per ulteriori dettagli, consulta il messaggio di errore. |
| 503 Servizio non disponibile | Il Firebase Realtime Database specificato non è temporaneamente disponibile, il che significa che la richiesta non è stata tentata. |
Protezione dei dati
Firebase ha un linguaggio di sicurezza che ci consente di definire quali utenti hanno accesso in lettura e scrittura ai diversi nodi dei nostri dati. Per saperne di più, consulta Realtime Database Security Rules.
Ora che abbiamo visto come salvare i dati, nella prossima sezione possiamo imparare a recuperarli dal database Firebase tramite l'API REST.