שמירת נתונים

כתיבת נתונים עם 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"
    }
  }
}

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

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

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

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, לא מספר רב.
• בעוד שהתקן מציע להחזיר ETtags עם כל הבקשות, 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 Security Rules Database , והוא נתמך על ידי כל סוגי הבקשות. הטיעון יכול להיות סוד אפליקציית 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 יחזיר קודי שגיאה בנסיבות אלה:

אבטחת נתונים

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