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

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

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

תשובה חלקית

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

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

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

דוגמה

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

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

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

דוגמה

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

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

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

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

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

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

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

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

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

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