שמירת נתונים

דרכים לשמור נתונים

לָשִׂים כתוב או החלף נתונים לנתיב מוגדר , כמו fireblog/users/user1/<data>
תיקון עדכן חלק מהמפתחות עבור נתיב מוגדר מבלי להחליף את כל הנתונים.
הודעה הוסף לרשימת נתונים במסד הנתונים שלנו ב-Firebase. בכל פעם שאנו שולחים בקשת POST , לקוח Firebase מייצר מפתח ייחודי, כמו fireblog/users/<unique-id>/<data>
לִמְחוֹק הסר נתונים מהפניה שצוינה במסד הנתונים של Firebase.

כתיבת נתונים עם PUT

פעולת הכתיבה הבסיסית דרך REST API היא PUT . כדי להדגים שמירת נתונים, נבנה אפליקציית בלוגים עם פוסטים ומשתמשים. כל הנתונים עבור האפליקציה שלנו יאוחסנו תחת הנתיב של `fireblog`, בכתובת האתר של מסד הנתונים של Firebase `https://docs-examples.firebaseio.com/fireblog`.

נתחיל בשמירת נתוני משתמש במסד הנתונים שלנו ב-Firebase. אנו נאחסן כל משתמש לפי שם משתמש ייחודי, וכן נאחסן את שמו המלא ותאריך הלידה שלו. מכיוון שלכל משתמש יהיה שם משתמש ייחודי, הגיוני להשתמש ב- PUT כאן במקום ב- POST מכיוון שכבר יש לנו את המפתח ואין צורך ליצור אחד.

באמצעות PUT , נוכל לכתוב מחרוזת, מספר, בוליאני, מערך או כל אובייקט JSON למסד הנתונים שלנו ב-Firebase. במקרה זה נעביר לו אובייקט:

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

כאשר אובייקט JSON נשמר במסד הנתונים, מאפייני האובייקט ממופים אוטומטית למיקומי צאצא באופן מקונן. אם ננווט לצומת החדש שנוצר, נראה את הערך "אלן טיורינג". אנו יכולים גם לשמור נתונים ישירות למיקום ילד:

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'

שתי הדוגמאות שלמעלה - כתיבת הערך בו-זמנית כאובייקט וכתיבתם בנפרד למיקומי צאצא - תגרום לכך שאותם נתונים יישמרו במסד הנתונים של Firebase שלנו:

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

בקשה מוצלחת תצוין בקוד סטטוס 200 OK HTTP, והתגובה תכיל את הנתונים שכתבנו למסד הנתונים. הדוגמה הראשונה תפעיל רק אירוע אחד אצל לקוחות שצופים בנתונים, ואילו הדוגמה השנייה תפעיל שניים. חשוב לציין שאם נתונים כבר היו קיימים בנתיב המשתמשים, הגישה הראשונה תחליף אותם, אך השיטה השנייה רק ​​תשנה את הערך של כל צומת צאצא נפרד תוך השארת ילדים אחרים ללא שינוי. PUT שווה ערך ל- set() ב-JavaScript SDK שלנו.

עדכון נתונים עם PATCH

באמצעות בקשת PATCH , אנו יכולים לעדכן ילדים ספציפיים במיקום מבלי לדרוס נתונים קיימים. בואו נוסיף את הכינוי של טיורינג לנתוני המשתמש שלו עם בקשת PATCH :

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

הבקשה לעיל תכתוב nickname לאובייקט alanisawesome שלנו מבלי למחוק את name או ילדי birthday . שימו לב שאם היינו מוציאים כאן בקשת PUT במקום זאת, name ויום birthday היו נמחקים מכיוון שהם לא נכללו בבקשה. הנתונים במסד הנתונים של Firebase שלנו נראים כעת כך:

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

בקשה מוצלחת תצוין באמצעות קוד סטטוס 200 OK HTTP, והתגובה תכיל את הנתונים המעודכנים שנכתבו למסד הנתונים.

Firebase תומך גם בעדכונים מרובי נתיבים. המשמעות היא ש- PATCH יכול כעת לעדכן ערכים במספר מיקומים במסד הנתונים שלך ב-Firebase בו-זמנית, תכונה רבת עוצמה המאפשרת לעזור לך לבטל את הנורמליזציה של הנתונים שלך . באמצעות עדכונים מרובי-נתיבים, אנו יכולים להוסיף כינויים לאלן וגם לגרייס בו-זמנית:

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

לאחר העדכון הזה, גם לאלן וגם לגרייס נוספו הכינויים שלהם:

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

שימו לב שניסיון לעדכן אובייקטים על ידי כתיבת אובייקטים עם הנתיבים הכלולים יגרום להתנהגות שונה. בואו נסתכל מה קורה אם במקום זאת ננסה לעדכן את גרייס ואלן בדרך זו:

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

זה גורם להתנהגות שונה, כלומר החלפת כל /fireblog/users :

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

עדכון נתונים עם בקשות מותנות

אתה יכול להשתמש בבקשות מותנות, המקבילה ל-REST לטרנזקציות, כדי לעדכן נתונים בהתאם למצב הקיים שלהם. לדוגמה, אם ברצונך להגדיל את מונה ההצבעות כלפי מעלה, וברצונך לוודא שהספירה משקפת במדויק מספר הצבעות מעלה בו-זמנית, השתמש בבקשה מותנית כדי לכתוב את הערך החדש למונה. במקום שתי כתיבה שמשנות את המונה לאותו מספר, אחת מבקשות הכתיבה נכשלת ואז תוכל לנסות שוב את הבקשה עם הערך החדש.
  1. כדי לבצע בקשה מותנית במיקום, קבל את המזהה הייחודי של הנתונים הנוכחיים במיקום זה, או את ה-ETag. אם הנתונים משתנים במיקום זה, גם ה-ETag משתנה. אתה יכול לבקש ETag בכל שיטה מלבד PATCH . הדוגמה הבאה משתמשת בבקשת GET .
    curl -i 'https://test.example.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
    
    קריאה ספציפית ל-ETag בכותרת מחזירה את ה-ETag של המיקום שצוין בתגובת 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. כלול את ה-ETag המוחזר בבקשת PUT או DELETE הבאה שלך כדי לעדכן נתונים התואמים ספציפית את ערך ה-ETag הזה. בעקבות הדוגמה שלנו, כדי לעדכן את המונה ל-11, או ל-1 גדול מהערך המובא הראשוני של 10, ולהיכשל בבקשה אם הערך כבר לא תואם, השתמש בקוד הבא:
    curl -iX PUT -d '11' 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'if-match:[ETAG_VALUE]'
    
    אם הערך של הנתונים בנקודה שצוינה המיקום עדיין 10, ה-ETag בבקשת ה- PUT תואם, והבקשה מצליחה, כותבת 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
    
    אם המיקום אינו תואם יותר ל-ETag, מה שעלול להתרחש אם משתמש אחר כתב ערך חדש למסד הנתונים, הבקשה נכשלת מבלי לכתוב למיקום. תגובת ההחזרה כוללת את הערך החדש ו-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. השתמש במידע החדש אם תחליט לנסות שוב את הבקשה. מסד נתונים בזמן אמת אינו מנסה שוב אוטומטית בקשות מותנות שנכשלו. עם זאת, אתה יכול להשתמש בערך החדש וב-ETag כדי לבנות בקשה מותנית חדשה עם המידע שהוחזר על ידי תגובת הכשל.

בקשות מותנות מבוססות REST מיישמות את תקן HTTP if-match . עם זאת, הם שונים מהתקן בדרכים הבאות:

  • אתה יכול לספק ערך ETag אחד בלבד עבור כל בקשת if-match, לא מספר רב.
  • בעוד שהתקן מציע להחזיר ETags עם כל הבקשות, Realtime Database מחזיר רק ETags עם בקשות הכוללות את הכותרת X-Firebase-ETag . זה מפחית את עלויות החיוב עבור בקשות סטנדרטיות.

בקשות מותנות עשויות להיות איטיות יותר מבקשות REST טיפוסיות.

שמירת רשימות נתונים

כדי ליצור מפתח ייחודי, מבוסס חותמת זמן, עבור כל ילד שנוסף להפניה למסד נתונים של Firebase, נוכל לשלוח בקשת POST . עבור נתיב users שלנו, היה הגיוני להגדיר את המפתחות שלנו מכיוון שלכל משתמש יש שם משתמש ייחודי. אבל כאשר משתמשים מוסיפים פוסטים בבלוג לאפליקציה, נשתמש בבקשת POST כדי ליצור אוטומטית מפתח עבור כל פוסט בבלוג:

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

נתיב posts שלנו מכיל כעת את הנתונים הבאים:

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

שימו לב שהמפתח -JSOpn9ZC54A4P4RoqVa נוצר עבורנו באופן אוטומטי מכיוון שהשתמשנו בבקשת POST . בקשה מוצלחת תצוין באמצעות קוד מצב HTTP 200 OK , והתגובה תכיל את מפתח הנתונים החדשים שנוספו:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

הסרת נתונים

כדי להסיר נתונים ממסד הנתונים, אנו יכולים לשלוח בקשת DELETE עם כתובת האתר של הנתיב שממנו נרצה למחוק נתונים. הדבר הבא ימחק את אלן מנתיב users שלנו:

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

בקשת DELETE מוצלחת תצוין על ידי קוד מצב HTTP 200 OK עם תגובה המכילה JSON null .

פרמטרי URI

REST API מקבל את הפרמטרים הבאים של URI בעת כתיבת נתונים למסד הנתונים:

אישור

פרמטר בקשת auth מאפשר גישה לנתונים המוגנים על ידי Firebase Realtime Database Rules , והוא נתמך על ידי כל סוגי הבקשות. הטיעון יכול להיות סוד אפליקציית Firebase שלנו או אסימון אימות, אותו נעסוק בסעיף הרשאת משתמש . בדוגמה הבאה אנו שולחים בקשת POST עם פרמטר auth , כאשר CREDENTIAL הוא סוד אפליקציית Firebase שלנו או אסימון אימות:

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

הדפס

פרמטר print מאפשר לנו לציין את פורמט התגובה שלנו ממסד הנתונים. הוספת print=pretty לבקשתנו תחזיר את הנתונים בפורמט קריא אנושי. print=pretty נתמך על ידי בקשות GET , PUT , POST , PATCH ו- DELETE .

כדי לדכא את הפלט מהשרת בעת כתיבת נתונים, נוכל להוסיף לבקשתנו print=silent . התגובה שתתקבל תהיה ריקה ותצוין על ידי קוד סטטוס 204 No Content HTTP אם הבקשה תצליח. print=silent נתמך על ידי בקשות GET , PUT , POST ו- PATCH .

כתיבת ערכי שרת

ניתן לכתוב ערכי שרת במיקום באמצעות ערך מציין מיקום, שהוא אובייקט עם מפתח ".sv" יחיד. הערך עבור מפתח זה הוא סוג ערך השרת שאנו רוצים להגדיר. לדוגמה, כדי להגדיר חותמת זמן כאשר משתמש נוצר, נוכל לבצע את הפעולות הבאות:

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

"timestamp" הוא ערך השרת הנתמך היחיד, והוא הזמן מאז עידן UNIX באלפיות שניות.

שיפור ביצועי כתיבה

אם אנחנו כותבים כמויות גדולות של נתונים למסד הנתונים, נוכל להשתמש בפרמטר print=silent כדי לשפר את ביצועי הכתיבה שלנו ולהקטין את השימוש ברוחב הפס. בהתנהגות הכתיבה הרגילה, השרת מגיב עם נתוני ה-JSON שנכתבו. כאשר מצוין print=silent , השרת סוגר מיד את החיבור ברגע שהנתונים מתקבלים, מה שמפחית את השימוש ברוחב הפס.

במקרים בהם אנו שולחים בקשות רבות למסד הנתונים, אנו יכולים לעשות שימוש חוזר בחיבור ה-HTTPS על ידי שליחת בקשת Keep-Alive בכותרת ה-HTTP.

תנאי שגיאה

REST API יחזיר קודי שגיאה בנסיבות אלה:

קודי מצב HTTP
400 בקשה רעה

אחד מתנאי השגיאה הבאים:

  • לא ניתן לנתח נתוני PUT או POST .
  • חסרים נתוני PUT או POST .
  • הבקשה מנסה PUT או POST נתונים גדולים מדי.
  • הקריאה ל-REST API מכילה שמות צאצאים לא חוקיים כחלק מהנתיב.
  • נתיב הקריאה של REST API ארוך מדי.
  • הבקשה מכילה ערך שרת לא מזוהה.
  • האינדקס עבור השאילתה אינו מוגדר בכללי מסד הנתונים של Firebase בזמן אמת .
  • הבקשה אינה תומכת באחד מפרמטרי השאילתה שצוינו.
  • הבקשה מערבבת פרמטרים של שאילתה עם בקשת GET רדודה.
401 לא מורשה

אחד מתנאי השגיאה הבאים:

404 לא נמצא מסד הנתונים שצוין של Firebase לא נמצא.
500 שגיאת שרת פנימית השרת החזיר שגיאה. עיין בהודעת השגיאה לפרטים נוספים.
שירות 503 אינו זמין מסד הנתונים בזמן אמת של Firebase שצוין אינו זמין באופן זמני, מה שאומר שהבקשה לא נוסתה.

אבטחת נתונים

ל-Firebase יש שפת אבטחה המאפשרת לנו להגדיר לאילו משתמשים יש גישת קריאה וכתיבה לצמתים שונים של הנתונים שלנו. אתה יכול לקרוא עוד על זה ב- Realtime Database Rules .

כעת, לאחר שכיסינו את שמירת הנתונים, אנו יכולים ללמוד כיצד לאחזר את הנתונים שלנו ממסד הנתונים של Firebase דרך REST API בסעיף הבא.