Zapisywanie danych

Sposoby oszczędzania danych
PUT Zapisz lub zastąp dane zdefiniowaną ścieżką, np. fireblog/users/user1/<data>
ŁADKA Zaktualizuj niektóre klucze zdefiniowanej ścieżki bez zastępowania wszystkich danych.
POST Dodaj do listy danych w naszej bazie danych Firebase. Za każdym razem, gdy wysyłamy żądanie POST, klient Firebase generuje unikalny klucz, np. fireblog/users/<unique-id>/<data>
USUŃ Usuń dane z określonego odwołania do bazy danych Firebase.

Zapisywanie danych za pomocą PUT

Podstawowa operacja zapisu za pomocą interfejsu API REST to PUT. Do zademonstrujemy oszczędzanie danych, utworzymy aplikację do blogowania z postami i użytkownikami. Wszystkie dane dla naszej aplikacji będą przechowywane pod ścieżką `fireblog`, pod adresem URL bazy danych Firebase „https://docs-examples.firebaseio.com/fireblog”.

Zacznijmy od zapisania w bazie danych Firebase części danych użytkowników. Przechowujemy dane każdego użytkownika według unikalnego identyfikatora nazwy użytkownika, a także ich pełne imię i nazwisko oraz datę urodzenia. Każdy użytkownik będzie mieć unikalną nazwę użytkownika, warto użyć tutaj nazwy PUT zamiast POST, ponieważ Mamy już klucz i nie musimy go tworzyć.

Za pomocą PUT można zapisać ciąg, liczbę, wartość logiczną, tablica lub dowolny obiekt JSON w w bazie danych Firebase. W tym przypadku przekażemy obiekt: 

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

Przy zapisywaniu obiektu JSON w bazie danych właściwości obiektu są automatycznie mapowane na lokalizacje podrzędne w sposób zagnieżdżony. Jeśli nawigacja do nowo utworzonego węzła, zobaczymy wartość „Alan Turing”. Możemy też zapisać dane bezpośrednio w lokalizacja dziecka: 

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'

Dwa powyższe przykłady – zapisywanie wartości w tym samym czasie co obiekt i zapisywanie ich niezależnie od lokalizacji podrzędnych – spowoduje to zapisanie tych samych danych w Firebase baza danych: 

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

Udane żądanie jest sygnalizowane kodem stanu HTTP 200 OK, a parametr będzie zawierać dane, które zapisaliśmy w bazie danych. W pierwszym przykładzie wywoła 1 zdarzenie na klientach, którzy oglądają dane, a drugi – dwa. Jeśli dane istniały już na ścieżce użytkownika, pierwszym podejściem zostałaby nadpisana, ale druga metoda modyfikuje tylko wartość każdego oddzielnego elementu podrzędnego bez zmian w pozostałych węzłach podrzędnych. PUT jest odpowiednikiem funkcji set() w naszym pakiecie SDK JavaScript.

Aktualizowanie danych za pomocą parametru PATCH

Za pomocą prośby PATCH możemy zaktualizować informacje o konkretnych dzieciach w lokalizacji bez i zastępowaniu istniejących danych. Dodajmy pseudonim Turinga do jego danych użytkownika za pomocą pola PATCH żądanie: 

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

Powyższe żądanie zapisze nickname w naszym obiekcie alanisawesome bez usuwania elementów podrzędnych name i birthday. Pamiętaj, że w przypadku przesyła prośbę o: PUT tutaj, name i birthday zostałyby usunięte, ponieważ nie były uwzględnione w żądaniu. Dane w Firebase baza danych wygląda teraz tak: 

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

Udane żądanie będzie oznaczone kodem stanu HTTP 200 OK, a parametr będzie zawierać zaktualizowane dane zapisane w bazie danych.

Firebase obsługuje też aktualizacje wielościeżkowe. Oznacza to, że usługa PATCH może teraz jednocześnie aktualizować wartości w wielu lokalizacjach w bazie danych Firebase. Jest to zaawansowana funkcja, która denormalizację danych. Dzięki aktualizacjom na wielu ścieżkach możemy dodawać pseudonimy zarówno Alanowi, jak i Grace jednocześnie: 

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

Po tej aktualizacji zarówno Alan, jak i Grace mają swoje pseudonimy: 

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

Pamiętaj, że próba zaktualizowania obiektów przez wpisanie obiektów z uwzględnionymi ścieżkami spowoduje inne zachowanie. Zobaczmy, co się stanie, jeśli spróbujemy zaktualizować Grace i Alana w ten sposób: 

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

Powoduje to inne zachowanie, czyli zastąpienie całego węzła /fireblog/users: 

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

Aktualizowanie danych za pomocą żądań warunkowych

Do aktualizowania za pomocą żądań warunkowych, które są odpowiednikiem transakcji typu REST, zgodnie z jej obecnym stanem. Dla: Jeśli na przykład chcesz zwiększyć licznik głosów za i chcesz się upewnić, dokładnie odzwierciedla wiele jednoczesnych głosów za, użyj funkcji warunkowej, żądanie zapisu nowej wartości w liczniku. Zamiast dwóch zapisów jeśli licznik zdarzeń zostanie zmieniony na tę samą liczbę, jedno z żądań zapisu zakończy się niepowodzeniem, możesz wysłać żądanie z nową wartością.
  1. Aby wykonać żądanie warunkowe w lokalizacji, uzyskaj unikalny identyfikator dla bieżących danych w tej lokalizacji lub ETag. Jeśli dane zmienią się lokalizacji, zmienia się też ETag. Możesz poprosić o tag ETag z dowolnym inną niż PATCH. Poniższy przykład korzysta z żądania GET. 
    curl -i 'https://test.example.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
    Konkretne wywołanie ETag w nagłówku zwraca ETag klucza określoną lokalizację w odpowiedzi 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. Uwzględnij zwrócony ETag w następnych PUT lub DELETE poproś o aktualizację które dokładnie pasują do tej wartości ETag. Kierując się naszym przykładem, zaktualizuj licznik do 11 lub 1 większego od pierwotnie pobranej wartości 10, i nie powiedzie się, jeśli wartość nie będzie już pasująca, użyj tego kodu: 
    curl -iX PUT -d '11' 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'if-match:[ETAG_VALUE]'
    Jeśli wartość danych w określonej lokalizacji nadal wynosi 10, ETag w tagu Żądanie PUT zostaje dopasowane i żądanie zostaje zrealizowane, w wyniku czego w bazie danych jest zapisywana wartość 11. 
    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
    Jeśli lokalizacja nie jest już zgodna z ETag, może się to zdarzyć, jeśli inny użytkownik zapisze nową wartość w bazie danych, żądanie zakończy się niepowodzeniem bez zapisu w lokalizacji. Odpowiedź zwrotna zawiera nową wartość i 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. Jeśli zdecydujesz się jeszcze raz przesłać prośbę, użyj nowych informacji. Realtime Database nie ponawia automatycznie żądań warunkowych, które zakończyły się niepowodzeniem. Pamiętaj jednak: możesz użyć nowej wartości i ETag do utworzenia nowego żądania warunkowego, informacje zwrócone w odpowiedzi o niepowodzeniu.

Żądania warunkowe oparte na REST implementują protokół HTTP jeśli-dopasowanie standardowy. Różnią się jednak od standardu pod kilkoma względami:

  • Możesz podać tylko jedną wartość ETag dla każdego żądania dopasowania, a nie kilka.
  • Zgodnie z normą standard ETag powinien być zwracany ze wszystkimi żądaniami, Baza danych czasu rzeczywistego zwraca tylko tagi ETag z żądaniami zawierającymi Nagłówek X-Firebase-ETag. Zmniejsza to koszty rozliczeń za żądania standardowe.

Żądania warunkowe mogą też działać wolniej niż typowe żądania REST.

Zapisywanie list danych

Aby generować unikalny klucz oparty na sygnaturze czasowej dla każdego elementu podrzędnego dodanego do bazy danych Firebase możemy wysłać prośbę o POST. Jeśli chodzi o ścieżkę users, warto definiują własne klucze, ponieważ każdy użytkownik ma unikalną nazwę. Gdy jednak użytkownicy dodadzą posty na blogu do sekcji aplikacji, użyjemy żądania POST do automatycznego wygenerowania klucza dla każdego posta na blogu: 

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

Nasza ścieżka posts zawiera teraz te dane: 

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

Zwróć uwagę, że klucz -JSOpn9ZC54A4P4RoqVa został dla nas automatycznie wygenerowany, ponieważ użyliśmy prośby POST. Żądanie zakończone powodzeniem jest oznaczone ikoną 200 OK kodu stanu HTTP, a odpowiedź będzie zawierać klucz nowych dodanych danych: 

{"name":"-JSOpn9ZC54A4P4RoqVa"}

Usuwanie danych

Aby usunąć dane z bazy danych, możemy wysłać żądanie DELETE z parametrem Adres URL ścieżki, z której chcemy usunąć dane. To spowoduje usunięcie Alana z Ścieżka users: 

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

Udane żądanie DELETE będzie sygnalizowane kodem stanu HTTP 200 OK wraz z odpowiedzią zawierającą null JSON.

Parametry URI

Podczas zapisywania danych w bazie danych interfejs API REST akceptuje te parametry identyfikatora URI:

uwierzytelnienie

Parametr żądania auth umożliwia dostęp do danych chronionych przez Firebase Realtime Database Security Rules i to obsługiwane przez wszystkie typy żądań. Może to być tajny klucz aplikacji Firebase lub uwierzytelniania, które omówimy w procesie autoryzacji użytkownika . W poniższym przykładzie wysyłamy żądanie POST z parametrem auth, gdzie CREDENTIAL to tajny klucz aplikacji Firebase lub token uwierzytelniania: 

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

drukuj

Parametr print pozwala nam określić format odpowiedzi na podstawie szablonu w bazie danych. Dodanie atrybutu print=pretty do żądania spowoduje zwrócenie danych w pliku zrozumiałego dla człowieka. Usługa print=pretty jest obsługiwana przez usługę GET, Żądania PUT, POST, PATCH i DELETE.

Aby wyłączyć dane wyjściowe z serwera podczas zapisu danych, możemy dodać print=silent. Otrzymana odpowiedź będzie pusta i oznaczona symbolem kod stanu HTTP 204 No Content, jeśli żądanie zostanie zrealizowane. Pole print=silent jest obsługiwane przez usługi GET, PUT, POST i PATCH prośby.

Zapisywanie wartości serwera

Wartości serwera można zapisywać w lokalizacji za pomocą wartości zmiennej, czyli obiektu z atrybutem pojedynczy klawisz ".sv". Wartość tego klucza to typ wartości serwera, którą chcemy ustawić. Aby na przykład ustawić sygnaturę czasową tworzenia użytkownika, możemy wykonać te czynności: 

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

"timestamp" to jedyna obsługiwana wartość serwera. Jest to czas od momentu, gdy system UNIX epoki w milisekundach.

Poprawianie wydajności zapisu

Jeśli zapisujemy w bazie danych duże ilości danych, możemy użyć funkcji print=silent parametr pozwalający zwiększyć wydajność zapisu i zmniejszyć przepustowość i ich wykorzystaniu. W normalnym trybie zapisu serwer odpowiada, przesyłając zapisane dane JSON. Jeśli podasz print=silent, serwer natychmiast zamyka połączenie po odebraniu danych, zmniejszając w ten sposób przepustowość.

Jeśli otrzymujemy wiele żądań do bazy danych, możemy ponownie użyć protokołu HTTPS wysyłając żądanie Keep-Alive w nagłówku HTTP.

Warunki błędu

Interfejs API REST zwraca kody błędów w tych sytuacjach:

Kody stanu HTTP
400 Nieprawidłowe żądanie

Jeden z tych warunków błędu:

  • Nie udało się przeanalizować danych PUT ani POST.
  • Brak danych: PUT lub POST.
  • Żądanie próbuje użyć danych PUT lub POST, które jest za duży.
  • Wywołanie interfejsu API REST zawiera w ścieżce nieprawidłowe nazwy podrzędne.
  • Ścieżka wywołania interfejsu API REST jest za długa.
  • Żądanie zawiera nierozpoznaną wartość serwera.
  • Indeks zapytania nie jest zdefiniowany w Twojej Firebase Realtime Database Security Rules
  • Żądanie nie obsługuje jednego ze podanych parametrów zapytania.
  • Żądanie łączy parametry zapytania z płytkim żądaniem GET.
401 Brak autoryzacji

Jeden z tych warunków błędu:

  • Token uwierzytelniania wygasł.
  • Token uwierzytelniania użyty w żądaniu jest nieprawidłowy.
  • Nie udało się uwierzytelnić przy użyciu tokena access_token.
  • Ta prośba narusza Twoje Firebase Realtime Database Security Rules.
404 Nie znaleziono Nie znaleziono określonej bazy danych Firebase.
500 – wewnętrzny błąd serwera Serwer zwrócił błąd. Więcej informacji znajdziesz w komunikacie o błędzie.
503 Usługa niedostępna Podana Baza danych czasu rzeczywistego Firebase jest tymczasowo niedostępna, co oznacza, że nie podjęto próby wykonania żądania.

Zabezpieczanie danych

Firebase oferuje język zabezpieczeń, który pozwala nam określać, którzy użytkownicy mają uprawnienia do odczytu i zapisu. w różnych węzłach danych. Więcej informacji na ten temat znajdziesz w Realtime Database Security Rules

Omówiliśmy już zapisywanie danych, więc możemy dowiedzieć się, jak pobierać dane z Firebase za pomocą interfejsu API REST.