דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

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

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

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

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

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

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

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

תשובה חלקית

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

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

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

דוגמה

בדוגמה הבאה ניתן לראות את השימוש בפרמטר fields עם "הדגמה" כללי (פיקטיבי) API.

בקשה פשוטה: בקשת ה-HTTP הזו GET משמיטה את הפרמטר fields ומחזירה את המשאב המלא.

https://www.googleapis.com/demo/v1

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

{
  "kind": "demo",
  ...
  "items": [
  {
    "title": "First title",
    "comment": "First comment.",
    "characteristics": {
      "length": "short",
      "accuracy": "high",
      "followers": ["Jo", "Will"],
    },
    "status": "active",
    ...
  },
  {
    "title": "Second title",
    "comment": "Second comment.",
    "characteristics": {
      "length": "long",
      "accuracy": "medium"
      "followers": [ ],
    },
    "status": "pending",
    ...
  },
  ...
  ]
}

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

https://www.googleapis.com/demo/v1?fields=kind,items(title,characteristics/length)

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

200 OK

{
  "kind": "demo",
  "items": [{
    "title": "First title",
    "characteristics": {
      "length": "short"
    }
  }, {
    "title": "Second title",
    "characteristics": {
      "length": "long"
    }
  },
  ...
  ]
}

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

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

סיכום התחביר של הפרמטרים של השדות

הפורמט של ערך הפרמטר של הבקשה fields מבוסס באופן חלש על תחביר XPath. מידע לגבי התחביר הנתמך מופיע בהמשך, ודוגמאות נוספות מופיעות בקטע הבא.

משתמשים ברשימה שמופרדת בפסיקים כדי לבחור כמה שדות.
אפשר להשתמש ב-a/b כדי לבחור שדה b שנמצא בתוך השדה a; צריך להשתמש בפונקציה a/b/c כדי לבחור שדה c שנמצא בתוך b.

חריג לכלל הזה: תשובות מ-API שמשתמשות ב-"data" [נתונים] רכיבי wrapper, שבהם התגובה מוצבת בתוך אובייקט data שנראה כמו data: { ... }, לא כוללים את "data" במפרט fields. הכללת אובייקט הנתונים עם מפרט שדות כמו data/a/b תגרום לשגיאה. במקום זאת, צריך פשוט להשתמש במפרט fields כמו a/b.
משתמשים בבורר משנה כדי לבקש קבוצה של שדות משנה ספציפיים של מערכים או אובייקטים על ידי הוספת ביטויים בסוגריים "( )".
לדוגמה: fields=items(id,author/email) מחזירה רק את מזהה הפריט ואת כתובת האימייל של המחבר עבור כל רכיב במערך הפריטים. אפשר גם לציין שדה משנה יחיד, שבו fields=items(id) שווה ל-fields=items/id.
אם צריך, משתמשים בתווים כלליים לחיפוש של שדות.
לדוגמה: fields=items/pagemap/* בוחר את כל האובייקטים במפת דפים.

דוגמאות נוספות לשימוש בפרמטר של השדות

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

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

מזהים את השדות שרוצים להחזיר, או בוחרים את השדות שנבחרו.

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

הנה כמה דוגמאות ברמת האוסף:

דוגמאות	השפעה
`items`	מחזירה את כל הרכיבים במערך הפריטים, כולל כל השדות בכל רכיב, אבל לא שדות אחרים.
`etag,items`	הפונקציה מחזירה את השדה `etag` וגם את כל הרכיבים במערך הפריטים.
`items/title`	הפונקציה מחזירה רק את השדה `title` לכל הרכיבים במערך הפריטים. כשמוחזר שדה מקונן, התגובה כוללת את האובייקטים המצורפים של ההורה. שדות ההורה לא כוללים שדות צאצא אחרים, אלא אם הם גם נבחרו באופן מפורש.
`context/facets/label`	מחזירה רק את השדה `label` לכל האיברים במערך `facets`, שממוקם בעצמו מתחת לאובייקט `context`.
`items/pagemap/*/title`	לכל רכיב במערך הפריטים, הפונקציה מחזירה רק את השדה `title` (אם קיים) של כל האובייקטים שהם צאצאים של `pagemap`.

הנה כמה דוגמאות ברמת המשאב:

דוגמאות	השפעה
`title`	הפונקציה מחזירה את השדה `title` של המשאב המבוקש.
`author/uri`	מחזירה את שדה המשנה `uri` של האובייקט `author` במשאב המבוקש.
`links/*/href`	מחזירה את השדה `href` של כל האובייקטים שהם צאצאים של `links`.

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

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

דוגמה	השפעה
`items(title,author/uri)`	מחזירה רק את הערכים של `title` ושל `uri` של המחבר לכל רכיב במערך הפריטים.

טיפול בתשובות חלקיות

אחרי ששרת מעבד בקשה חוקית שכוללת את פרמטר השאילתה fields, הוא שולח חזרה את קוד הסטטוס 200 OK של HTTP, יחד עם הנתונים המבוקשים. אם בפרמטר השאילתה fields יש שגיאה או שהוא לא תקין מסיבה אחרת, השרת מחזיר קוד הסטטוס 400 Bad Request של HTTP, יחד עם הודעת שגיאה שמפרטת למשתמשים מה הבעיה בבחירת השדות (לדוגמה, "Invalid field selection a/b").

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

https://www.googleapis.com/demo/v1?fields=kind,items(title,characteristics/length)

התשובה החלקית נראית כך:

200 OK

{
  "kind": "demo",
  "items": [{
    "title": "First title",
    "characteristics": {
      "length": "short"
    }
  }, {
    "title": "Second title",
    "characteristics": {
      "length": "long"
    }
  },
  ...
  ]
}

הערה: לממשקי API שתומכים בפרמטרים של שאילתה לעימוד נתונים (לדוגמה, maxResults ו-nextPageToken), אפשר להשתמש בפרמטרים האלה כדי לצמצם את התוצאות של כל שאילתה לגודל שאפשר לנהל. אחרת, ייתכן שהביצועים יהיו טובים יותר אם נקבל תגובה חלקית.

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

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

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

דוגמה

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

PATCH https://www.googleapis.com/demo/v1/324
Authorization: Bearer your_auth_token
Content-Type: application/json

{
  "title": "New title"
}

תשובה:

200 OK

{
  "title": "New title",
  "comment": "First comment.",
  "characteristics": {
    "length": "short",
    "accuracy": "high",
    "followers": ["Jo", "Will"],
  },
  "status": "active",
  ...
}

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

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

הסמנטיקה של בקשת התיקון

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

הוספה: כדי להוסיף שדה שלא קיים כבר, מציינים את השדה החדש ואת הערך שלו.
שינוי: כדי לשנות את הערך של שדה קיים, מציינים את השדה ומגדירים אותו לערך החדש.
מחיקה: כדי למחוק שדה, מציינים את השדה ומגדירים אותו לערך null. לדוגמה, "comment": null. אפשר גם למחוק אובייקט שלם (אם ניתן לשנות אותו) על ידי הגדרתו ל-null. אם משתמשים בספריית הלקוח של Java API, צריך להשתמש ב-Data.NULL_STRING במקום זאת. עבור לפרטים, ראו JSON null.

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

שימוש בתיקון במחזור של קריאה-שינוי-כתיבה

מומלץ להתחיל באחזור תגובה חלקית עם הנתונים שרוצים לשנות. זה חשוב במיוחד למשאבים שמשתמשים ב-ETags, כי צריך לציין את ערך ה-ETag הנוכחי בכותרת ה-HTTP If-Match כדי לעדכן את המשאב בהצלחה. אחרי שתקבלו את הנתונים, תוכלו לשנות את הערכים שרוצים לשנות ולשלוח חזרה את הייצוג החלקי שהשתנה עם בקשת תיקון. הנה דוגמה שמניחה שמשאב ההדגמה משתמש ב-ETags:

GET https://www.googleapis.com/demo/v1/324?fields=etag,title,comment,characteristics
Authorization: Bearer your_auth_token

זו תגובה חלקית:

200 OK

{
  "etag": "ETagString"
  "title": "New title"
  "comment": "First comment.",
  "characteristics": {
    "length": "short",
    "level": "5",
    "followers": ["Jo", "Will"],
  }
}

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

PATCH https://www.googleapis.com/demo/v1/324?fields=etag,title,comment,characteristics
Authorization: Bearer your_auth_token
Content-Type: application/json
If-Match: "ETagString"

{
  "etag": "ETagString"
  "title": "",                  /* Clear the value of the title by setting it to the empty string. */
  "comment": null,              /* Delete the comment by replacing its value with null. */
  "characteristics": {
    "length": "short",
    "level": "10",              /* Modify the level value. */
    "followers": ["Jo", "Liz"], /* Replace the followers array to delete Will and add Liz. */
    "accuracy": "high"          /* Add a new characteristic. */
  },
}

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

200 OK

{
  "etag": "newETagString"
  "title": "",                 /* Title is cleared; deleted comment field is missing. */
  "characteristics": {
    "length": "short",
    "level": "10",             /* Value is updated.*/
    "followers": ["Jo" "Liz"], /* New follower Liz is present; deleted Will is missing. */
    "accuracy": "high"         /* New characteristic is present. */
  }
}

פיתוח של בקשת תיקון באופן ישיר

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

הערה: אפשר להשתמש בכותרת HTTP של "If-Match: *" כדי לאלץ מעבר תיקון בזמן שימוש ב-ETags. אם עושים זאת, אין צורך לקרוא את ההודעה לפני הכתיבה.

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

PATCH https://www.googleapis.com/demo/v1/324?fields=comment,characteristics
Authorization: Bearer your_auth_token
Content-Type: application/json

{
  "comment": "A new comment",
  "characteristics": {
    "volume": "loud",
    "accuracy": null
  }
}

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

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

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

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

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

סימון חלופי כאשר אין תמיכה בפועל PATCH HTTP

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

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

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

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

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

בקשות אצווה

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

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

סקירה כללית

כל חיבור HTTP שהלקוח יוצר מגדיל במידה מסוימת את התקורה. Google Drive API תומך בקיבוץ באצווה של קריאות כדי לאפשר ללקוח לבצע מספר קריאות ל-API בבקשת HTTP אחת.

דוגמאות למצבים שבהם כדאי להשתמש בקיבוץ באצווה של קריאות:

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

במקרים כאלה, במקום לשלוח כל קריאה בנפרד, אפשר לקבץ את כל הקריאות בבקשת HTTP אחת. כל הבקשות הפנימיות חייבות לעבור לאותו Google API.

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

הערה: מערכת האצווה של Google Drive API משתמשת באותו תחביר כמו מערכת עיבוד אצווה של OData, אבל הסמנטיקה שונה.

מגבלות נוספות כוללות:

בקשות מרובות עם יותר מ-100 קריאות עלולות לגרום לשגיאה.
בכל בקשה פנימית יש מגבלה של 8,000 תווים על אורך כתובת ה-URL.
Google Drive לא תומך בפעולות באצווה עבור מדיה, בין אם עבור העלאה או הורדה או עבור ייצוא קבצים.

פירוט לגבי בקשות באצווה

בקשה באצווה מורכבת מכמה קריאות ל-API המאוגדות לבקשת HTTP אחת, שאותה אפשר לשלוח אל ה-batchPath שצוין במסמך ה-Discovery של ה-API. נתיב ברירת המחדל הוא /batch/api_name/api_version. הקטע הזה מתאר בפירוט את התחביר של קריאות באצווה; בהמשך, יש דוגמה.

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

הפורמט של בקשה באצווה

בקשה באצווה היא בקשת HTTP רגילה יחידה שמכילה כמה קריאות ל-Google Drive API, באמצעות סוג התוכן multipart/mixed. בבקשת ה-HTTP הראשית, כל אחד מהחלקים מכיל בתוכו בקשת HTTP פנימית.

כל חלק מתחיל בכותרת HTTP ‏Content-Type: application/http משלו. אפשר להוסיף לה גם כותרת Content-ID אופציונלית. עם זאת, כותרות החלקים רק נועדו לסמן את תחילת החלק. הם נפרדים מהבקשה הפנימית. אחרי שהשרת מפרק את הבקשה באצווה לבקשות נפרדות, המערכת מתעלמת מכותרות החלקים.

הגוף של כל חלק הוא בקשת HTTP מלאה עם פועל, כתובת URL, כותרות וגוף. בקשת ה-HTTP חייבת להכיל רק את החלק של הנתיב שבכתובת ה-URL. כתובות URL מלאות אינן מותרות בבקשות באצווה.

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

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

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

תשובה לבקשה באצווה

תגובת השרת היא תשובת HTTP רגילה יחידה עם סוג תוכן multipart/mixed; כל חלק הוא התשובה לאחת מהבקשות שבבקשה באצווה, באותו סדר כמו הבקשות.

בדומה לחלקים בבקשה, כל חלק בתשובה מכיל תגובת HTTP מלאה, כולל קוד סטטוס, כותרות וגוף. בדומה לחלקים שבבקשה, לפני כל חלק של תשובה מופיעה כותרת Content-Type שמסמנת את תחילת החלק.

אם לחלק מסוים בבקשה יש כותרת Content-ID, לחלק המתאים בתגובה יש כותרת Content-ID תואמת, כאשר הערך המקורי מופיע לפני המחרוזת response-, כמו בדוגמה הבאה.

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

דוגמה

בדוגמה הבאה מוצג השימוש בקיבוץ באצווה באמצעות Google Drive API.

דוגמה לבקשה באצווה

POST https://www.googleapis.com/batch/drive/v3 Accept-Encoding: gzip User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip) Content-Type: multipart/mixed; boundary=END_OF_PART Content-Length: 963

--END_OF_PART Content-Length: 337 Content-Type: application/http content-id: 1 content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id Authorization: Bearer authorization_token Content-Length: 70 Content-Type: application/json; charset=UTF-8

{ "emailAddress":"example@appsrocks.com", "role":"writer", "type":"user" } --END_OF_PART Content-Length: 353 Content-Type: application/http content-id: 2 content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false Authorization: Bearer authorization_token Content-Length: 58 Content-Type: application/json; charset=UTF-8

{ "domain":"appsrocks.com", "role":"reader", "type":"domain" } --END_OF_PART--

דוגמה לתשובה באצווה

זו התשובה לבקשה לדוגמה שבקטע הקודם.

HTTP/1.1 200 OK Alt-Svc: quic=":443"; p="1"; ma=604800 Server: GSE Alternate-Protocol: 443:quic,p=1 X-Frame-Options: SAMEORIGIN Content-Encoding: gzip X-XSS-Protection: 1; mode=block Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk Transfer-Encoding: chunked X-Content-Type-Options: nosniff Date: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Vary: X-Origin Vary: Origin Expires: Fri, 13 Nov 2015 19:28:59 GMT

--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-1

HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35

{ "id": "12218244892818058021i" }

--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-2

HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35

{ "id": "04109509152946699072k" }

--batch_6VIxXCQbJoQ_AATxy_GgFUk--

החזרת שדות ספציפיים מהבקשה

כברירת מחדל, השרת מחזיר קבוצת ברירת מחדל של שדות משאבים שספציפיים ל- השיטה שבה נעשה שימוש. לדוגמה, השיטה files.list עשויה להחזיר רק את id, name וגם mimeType. ייתכן שהשדות האלה לא יהיו השדות המדויקים צריכים. אם אתם צריכים להחזיר שדות אחרים, קראו את המאמר החזרת שדות ספציפיים בקובץ.