שמירת נתונים

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

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

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

פעולת הכתיבה הבסיסית באמצעות 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() ב SDK JavaScript שלנו.

עדכון נתונים עם 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 אם-התאמה סטנדרטית. עם זאת, הם שונים מהסטנדרט בדרכים הבאות:

  • אתה יכול לספק ערך ETag אחד בלבד עבור כל בקשת אם-התאמה, ולא מספר רב.
  • בעוד שהתקן עולה כי ETags יוחזר עם כל הבקשות, מסד זמן אמת רק מחזירה 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 בקשה. בקשה מוצלחת תסומן על ידי 200 OK קוד מצב HTTP, ואת התגובה תכיל את המפתח של הנתונים החדשים שהוסף:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

הסרת נתונים

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

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

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

פרמטרים של URI

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

אימות

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

תנאי שגיאה

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

קודי מצב HTTP
400 בקשה שגויה

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

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

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

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

אבטחת נתונים

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

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