שיפור הביצועים

במסמך הזה מפורטות כמה טכניקות שיעזרו לכם לשפר את הביצועים של האפליקציה. בחלק מהמקרים, נעשה שימוש בדוגמאות מממשקי API אחרים או מממשקי API כלליים כדי להמחיש את הרעיונות שמוצגים. עם זאת, אותם מושגים רלוונטיים גם ל-Android Over The Air API.

דחיסה באמצעות gzip

דרך קלה ונוחה לצמצם את רוחב הפס הדרוש לכל בקשה היא להפעיל דחיסת נתונים מסוג gzip. על אף שהפעולה הזו דורשת זמן CPU (מעבד) נוסף כדי לבטל את הדחיסה של התוצאות, היא משתלמת מאוד בזכות הצמצום בעלויות של הרשת.

כדי לקבל תשובה עם קידוד gzip, צריך לבצע שני דברים: להגדיר כותרת Accept-Encoding ולשנות את סוכן המשתמש כך שיכיל את המחרוזת gzip. דוגמה לכותרות HTTP שנוצרו בצורה תקינה כדי להפעיל דחיסת gzip:

Accept-Encoding: gzip
User-Agent: my program (gzip)

עבודה עם משאבים חלקיים

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

יש שני סוגים של בקשות חלקיות:

• תגובה חלקית: בקשה שבה מציינים אילו שדות לכלול בתגובה (משתמשים בפרמטר הבקשה fields).
• ‫Patch: בקשת עדכון שבה שולחים רק את השדות שרוצים לשנות (משתמשים בפועל HTTP ‏PATCH).

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

תשובה חלקית

כברירת מחדל, השרת שולח בחזרה את הייצוג המלא של משאב אחרי עיבוד הבקשות. כדי לשפר את הביצועים, אפשר לבקש מהשרת לשלוח רק את השדות שבאמת צריכים ולקבל במקום זאת תגובה חלקית.

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

שימו לב שהפרמטר fields משפיע רק על נתוני התגובה, ולא על הנתונים שאתם צריכים לשלוח, אם יש כאלה. כדי להקטין את כמות הנתונים שאתם שולחים כשאתם משנים משאבים, כדאי להשתמש בבקשת patch.

תיקון (עדכון חלקי)

בנוסף, אפשר להימנע משליחת נתונים מיותרים כשמשנים משאבים. כדי לשלוח נתונים מעודכנים רק לשדות הספציפיים שאתם משנים, משתמשים בפועל HTTP PATCH. הסמנטיקה של תיקוני ה-patch שמתוארת במסמך הזה שונה (ופשוטה יותר) מזו שהייתה בגרסה הקודמת של GData, שבה נעשה שימוש בעדכון חלקי.

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

דוגמה

טיפול בתשובה לתיקון

אחרי עיבוד של בקשת תיקון תקינה, ה-API מחזיר קוד תגובת HTTP‏ 200 OK יחד עם הייצוג המלא של המשאב ששונה. אם ה-API משתמש ב-ETag, השרת מעדכן את ערכי ה-ETag כשהוא מעבד בהצלחה בקשת תיקון, בדיוק כמו שהוא עושה עם PUT.

בקשת התיקון מחזירה את כל ייצוג המשאב, אלא אם משתמשים בפרמטר fields כדי לצמצם את כמות הנתונים שהיא מחזירה.

אם בקשת תיקון מובילה למצב חדש של משאב שהוא לא חוקי מבחינת תחביר או סמנטיקה, השרת מחזיר קוד סטטוס HTTP מסוג 400 Bad Request או 422 Unprocessable Entity, ומצב המשאב נשאר ללא שינוי. לדוגמה, אם מנסים למחוק את הערך של שדה חובה, השרת מחזיר שגיאה.

סימון חלופי כשפועל ה-HTTP‏ PATCH לא נתמך

אם חומת האש לא מאפשרת בקשות HTTP PATCH, צריך לשלוח בקשת HTTP POST ולהגדיר את כותרת ההחלפה ל- PATCH, כמו שמוצג בהמשך:

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

ההבדל בין תיקון לבין עדכון

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

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