במאמר הזה נסביר איך לקבץ באצווה קריאות ל-API כדי לצמצם את מספר החיבורים שהלקוח צריך לבצע. הוספת פעולות לאצווה יכולה לשפר את היעילות של אפליקציה על ידי הקטנת מספר הלוך ושוב ברשת והגדלת קצב העברת הנתונים.
סקירה כללית
כל חיבור שהלקוח יוצר מגדיל במידה מסוימת את התקורה. ה-API של Google Docs תומך בקיבוץ באצווה של קריאות כדי לאפשר ללקוח לבצע מספר אובייקטים של בקשות, שכל אחד מהם מציין סוג יחיד של בקשה לביצוע, בבקשה אחת באצווה. בקשה לאצווה יכולה לשפר את הביצועים על ידי שילוב של כמה בקשות משנה לקריאה אחת לשרת, ואז אחזור של תשובה אחת.
מומלץ תמיד לשלוח כמה בקשות יחד באצווה. הנה כמה דוגמאות למצבים שבהם אפשר להשתמש בקיבוץ באצווה של קריאות:
- רק התחלתם להשתמש ב-API ויש לכם הרבה נתונים להעלות.
- צריך לעדכן מטא-נתונים או מאפיינים, כמו עיצוב, בכמה אובייקטים.
- צריך למחוק הרבה אובייקטים.
שיקולים לגבי מגבלות, הרשאות ותלות
ריכזנו כאן רשימה של פריטים נוספים שכדאי לקחת בחשבון כשמשתמשים בעדכון אצווה:
- כל בקשת אצווה, כולל כל בקשות המשנה, נספרת כבקשת API אחת במגבלת השימוש.
- בקשה קבוצתית מאומתת פעם אחת. האימות הזה חל על כל האובייקטים של עדכון באצ' בבקשה.
- השרת מעבד את בקשות המשנה באותו סדר שבו הן מופיעות בבקשה מרובת הפעולות. בקשות משנה מאוחרות יותר יכולות להיות תלויות בפעולות שבוצעו במהלך בקשות משנה קודמות. לדוגמה, באותה בקשת אצווה, המשתמשים יכולים להוסיף טקסט למסמך קיים ואז להחיל עליו סגנון.
פירוט לגבי בקשות באצווה
בקשה באצווה מורכבת מקריאה אחת לשיטת batchUpdate עם כמה בקשות משנה, למשל להוספה ואז לעיצוב של מסמך.
כל בקשה עוברת אימות לפני שהיא מיושמת. כל בקשות המשנה בעדכון הקבוצתי מוחלות באופן אטומי. כלומר, אם בקשה כלשהי לא תהיה תקפה, העדכון כולו ייכשל ואף אחד מהשינויים (שעשויים להיות תלויים זה בזה) לא יחול.
חלק מהבקשות מספקות תשובות עם מידע על הבקשות שהוגשו. לדוגמה, כל הבקשות לעדכון באצווה להוספת אובייקטים מחזירות תגובות, כך שאפשר לגשת למטא-נתונים של האובייקט שנוסף, כמו המזהה או השם.
בגישה הזו, אפשר ליצור מסמך שלם ב-Google באמצעות בקשת עדכון באצווה של API עם כמה בקשות משנה.
הפורמט של בקשה באצווה
בקשה היא בקשת JSON אחת שמכילה כמה בקשות משנה מקוננות עם מאפיין חובה אחד: requests. הבקשות מורכבות במערך של בקשות נפרדות. כל בקשה משתמשת ב-JSON כדי לייצג את אובייקט הבקשה וכדי להכיל את המאפיינים שלו.
הפורמט של תשובה לבקשה באצווה
הפורמט של תשובה לבקשה באצווה דומה לפורמט של הבקשה. התשובה של השרת מכילה תשובה מלאה של אובייקט תשובה יחיד.
המאפיין של אובייקט ה-JSON הראשי נקרא replies. התשובות מוחזרות במערך, וכל תשובה לאחת מהבקשות תופסת את אותו סדר אינדקס כמו הבקשה התואמת. יש בקשות שלא מקבלות תשובות, והתשובה באינדקס הזה במערך ריקה.
דוגמה
בדוגמת הקוד הבאה אפשר לראות איך משתמשים באוסף בקשות עם Docs API.
בקשה
בדוגמה הזו לבקשת אצווה אפשר לראות איך:
תכניס את הטקסט 'Hello World' לתחילת מסמך קיים, עם אינדקס
locationשל1, באמצעותInsertTextRequest.תעדכן את המילה 'Hello' באמצעות התג
UpdateTextStyleRequest. התגיםstartIndexו-endIndexמגדירים אתrangeשל טקסט מעוצב בתוך הפלח.באמצעות
textStyle, מגדירים את סגנון הגופן למודגש ואת הצבע לכחול רק למילה Hello.באמצעות השדה
WriteControl, אתם יכולים לקבוע איך בקשות כתיבה יבוצעו. מידע נוסף זמין במאמר איך יוצרים עקביות במצב באמצעות WriteControl.
{ "requests":[ { "insertText":{ "location":{ "index":1, "tabId":TAB_ID }, "text":"Hello World" } }, { "updateTextStyle":{ "range":{ "startIndex":1, "endIndex":6 }, "textStyle":{ "bold":true, "foregroundColor":{ "color":{ "rgbColor":{ "blue":1 } } } }, "fields":"bold,foreground_color" } } ], "writeControl": { "requiredRevisionId": "REQUIRED_REVISION_ID" } }
מחליפים את TAB_ID ו-REQUIRED_REVISION_ID במזהה הכרטיסייה ובמזהה הגרסה, בהתאמה, של המסמך שהבקשה לכתיבה מופנית אליו.
תשובה
בדוגמה הזו של תשובה לבקשה באצווה מוצג מידע על האופן שבו כל בקשת משנה בתוך הבקשה באצווה הוחלה. אף אחת מהן, InsertTextRequest או UpdateTextStyleRequest, לא מכילה תגובה, ולכן ערכי האינדקס של המערך במיקומים [0] ו-[1] מורכבים מסוגריים מסולסלים ריקים. בבקשה באצווה מוצג האובייקט WriteControl, שבו אפשר לראות איך הבקשות בוצעו.
{ "replies":[ {}, {} ], "writeControl":{ "requiredRevisionId":`REQUIRED_REVISION_ID` }, "documentId":`DOCUMENT_ID` }