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ą.- 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 żądaniaGET
. Konkretne wywołanie ETag w nagłówku zwraca ETag klucza określoną lokalizację w odpowiedzi HTTP.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
- Uwzględnij zwrócony ETag w następnych
PUT
lubDELETE
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: Jeśli wartość danych w określonej lokalizacji nadal wynosi 10, ETag w tagu Żądaniecurl -iX PUT -d '11' 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'if-match:[ETAG_VALUE]'
PUT
zostaje dopasowane i żądanie zostaje zrealizowane, w wyniku czego w bazie danych jest zapisywana wartość 11. 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 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
- 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:
|
401 Brak autoryzacji |
Jeden z tych warunków błędu:
|
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.