Zwiększ wydajność

Kompresja za pomocą gzip

Kompresja gzip pozwala łatwo i wygodnie zmniejszyć przepustowość potrzebną do obsługi żądań. Chociaż dekompresja wyników wymaga dodatkowego czasu pracy procesora, zrekompensowanie tego z kosztami sieci zazwyczaj jest bardzo opłacalne.

Aby odebrać odpowiedź zakodowaną w formacie gzip, ustaw nagłówek Accept-Encoding i zmodyfikuj klienta użytkownika tak, aby zawierał ciąg gzip. Oto przykład prawidłowo sformatowanych nagłówków HTTP, które umożliwiają włączenie kompresji gzip:

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

Praca z częściowymi zasobami

Innym sposobem na poprawę skuteczności wywołań interfejsu API jest wysyłanie i odbieranie tylko części danych, które Cię interesują. Pozwala to aplikacji uniknąć przesyłania, analizowania i przechowywania niepotrzebnych pól, dzięki czemu może wydajniej wykorzystywać zasoby, w tym sieć, procesor i pamięć.

Istnieją 2 typy żądań częściowych:

• Odpowiedź częściowa: w tym żądaniu wybierasz, które pola mają znajdować się w odpowiedzi (użyj parametru żądania fields).
• Poprawka: w tym żądaniu aktualizacji wysyłasz tylko te pola, które chcesz zmienić (użyj czasownika HTTP PATCH).

Więcej informacji na temat tworzenia żądań częściowych znajdziesz w kolejnych sekcjach.

Odpowiedź częściowa

Po przetworzeniu żądań serwer domyślnie odsyła pełną reprezentację zasobu. Aby uzyskać lepszą wydajność, możesz poprosić serwer, aby wysłał tylko te pola, których potrzebujesz, i uzyskał odpowiedź częściową.

Aby wysłać takie żądanie, użyj parametru żądania fields i określ pola, które chcesz otrzymać. Tego parametru możesz używać w każdym żądaniu, które zwraca dane odpowiedzi.

Pamiętaj, że parametr fields ma wpływ tylko na dane odpowiedzi. nie ma wpływu na dane, które musisz wysłać. Aby zmniejszyć ilość danych wysyłanych po zmianie zasobów, użyj żądania poprawki.

Przykład

Przykład poniżej pokazuje sposób użycia parametru fields z ogólną (fikcyjną) wartością „Demo” API.

Proste żądanie: to żądanie HTTP GET pomija parametr fields i zwraca pełny zasób.

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

Odpowiedź z pełnym zasobem: pełne dane zasobu obejmują poniższe pola i wiele innych pól pominiętych ze względu na zwięzłość.

{
  "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",
    ...
  },
  ...
  ]
}

Żądanie odpowiedzi częściowej: poniższe żądanie tego samego zasobu używa parametru fields, aby znacznie zmniejszyć ilość zwracanych danych.

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

Odpowiedź częściowa: w odpowiedzi na powyższe żądanie serwer wysyła odpowiedź zawierającą tylko informacje o rodzaju oraz skróconą tablicę elementów, w której każdy element zawiera tylko informacje o tytule HTML i długości danego elementu.

200 OK

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

Pamiętaj, że odpowiedź jest obiektem JSON, który zawiera tylko wybrane pola i ich obiekty nadrzędne.

Szczegółowe informacje o formatowaniu parametru fields znajdziesz poniżej. Opisaliśmy też szczegółowo zawartość odpowiedzi.

Podsumowanie składni parametru pól

Format wartości parametru żądania fields jest oparty na składni XPath. Podsumowanie obsługiwanej składni znajdziesz w dalszej części tego artykułu.

• Użyj listy rozdzielanej przecinkami, aby wybrać wiele pól.
• Użyj a/b, aby wybrać pole b zagnieżdżone w polu a; użyj a/b/c, aby wybrać pole c zagnieżdżone w b.
  

  Wyjątek: w przypadku odpowiedzi interfejsu API zawierających słowo „dane” otoki, gdzie odpowiedź jest zagnieżdżona w obiekcie data, który wygląda jak data: { ... }, nie dodawaj „data”. w specyfikacji fields. Dodanie obiektu danych do specyfikacji pól, takich jak data/a/b, powoduje błąd. Użyj tylko specyfikacji fields, takiej jak a/b.

• Użyj selektora podrzędnego, aby zażądać zbioru konkretnych podrzędnych pól tablic lub obiektów. W tym celu umieść wyrażenia w nawiasach „( )”.

  Przykład: fields=items(id,author/email) zwraca tylko identyfikator elementu i adres e-mail autora każdego elementu tablicy. Możesz też podać jedno pole podrzędne, gdzie fields=items(id) jest równoważne z fields=items/id.

• W razie potrzeby w wybranych polach używaj symboli wieloznacznych.

  Przykład: fields=items/pagemap/* wybiera wszystkie obiekty w elemencie pagemap.

Więcej przykładów użycia parametru pól

W przykładach poniżej opisano, jak wartość parametru fields wpływa na odpowiedź.

Uwaga: tak jak każda wartość parametru zapytania, wartość parametru fields musi być zakodowana na potrzeby adresu URL. Aby ułatwić czytanie, w przykładach w tym dokumencie pominięto kodowanie.

Określ pola, które chcesz zwrócić, lub wybierz odpowiednie pola.

Wartość parametru żądania fields ma postać listy pól rozdzielanej przecinkami. Każde pole jest określane względem elementu głównego odpowiedzi. Oznacza to, że jeśli wykonujesz operację na liście, w odpowiedzi otrzymasz kolekcję, która zwykle zawiera tablicę zasobów. Jeśli wykonujesz operację, która zwraca 1 zasób, pola są określane względem tego zasobu. Jeśli wybrane pole jest tablicą (lub jest jej częścią), serwer zwraca wybraną część wszystkich elementów tablicy.

Oto kilka przykładów na poziomie kolekcji:

Przykłady	Efekt
items	Zwraca wszystkie elementy tablicy, w tym wszystkie pola w każdym elemencie (nie zwraca żadnych innych pól).
etag,items	Zwraca zarówno pole etag, jak i wszystkie elementy tablicy.
items/title	Zwraca tylko pole title każdego elementu tablicy. Gdy jest zwracane zagnieżdżone pole, odpowiedź zawiera obiekty nadrzędne. Pola nadrzędne nie zawierają żadnych innych pól podrzędnych, chyba że zostaną też wybrane bezpośrednio.
context/facets/label	Zwraca tylko pole label każdego elementu tablicy facets, która jest zagnieżdżona w obiekcie context.
items/pagemap/*/title	Zwraca tylko pole title (jeśli jest obecne) każdego elementu tablicy we wszystkich obiektach podrzędnych obiektu pagemap.

Oto kilka przykładów na poziomie zasobu:

Przykłady	Efekt
title	Zwraca pole title żądanego zasobu.
author/uri	Zwraca pole podrzędne uri obiektu author w żądanym zasobie.
links/*/href	Zwraca pole href wszystkich obiektów podrzędnych obiektu links.

Aby żądać tylko fragmentów pól, dokonaj wyborów podrzędnych.

Jeśli żądanie dotyczy określonych pól, serwer zwraca domyślnie całe obiekty lub elementy tablicy. Możesz użyć odpowiedzi, która zawiera tylko niektóre pola podrzędne. W tym celu użyj polecenia „( )” jak w poniższym przykładzie.

Przykład	Efekt
items(title,author/uri)	Zwraca tylko wartości title i uri autora z każdego elementu tablicy.

Obsługa odpowiedzi częściowych

Gdy serwer przetworzy prawidłowe żądanie z parametrem zapytania fields, razem z żądanymi danymi wyśle kod stanu HTTP 200 OK. Jeśli parametr zapytania fields zawiera błąd lub jest nieprawidłowy z innego powodu, serwer zwraca kod stanu HTTP 400 Bad Request i komunikat o błędzie z informacją o błędzie z wybranymi polami (na przykład "Invalid field selection a/b").

Oto przykładowa odpowiedź częściowa, o której mowa powyżej, we wprowadzeniu. Aby określić, które pola zwrócić, żądanie używa parametru fields.

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

Odpowiedź częściowa wygląda tak:

200 OK

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

Uwaga: w interfejsach API, które obsługują parametry zapytania do podziału danych na strony (na przykład maxResults i nextPageToken), te parametry pozwalają zmniejszyć liczbę wyników zapytań do rozmiaru, który ułatwia obsługę. W przeciwnym razie wzrost wydajności wynikający z odpowiedzi częściowej może nie zostać osiągnięty.

Poprawka (częściowa aktualizacja)

Podczas modyfikowania zasobów możesz też uniknąć wysyłania niepotrzebnych danych. Aby wysłać tylko zaktualizowane dane pól, które zmieniasz, użyj czasownika HTTP PATCH. Semantyka poprawki opisana w tym dokumencie jest inna (i prostsza) niż w starszej implementacji częściowej aktualizacji w GData.

Krótki przykład poniżej pokazuje, jak dzięki poprawce można zminimalizować ilość wysyłanych danych w celu przeprowadzenia niewielkiej aktualizacji.

Przykład

Ten przykład przedstawia proste żądanie poprawki, które aktualizuje tylko nazwę ogólnego (fikcyjnego) „Demo” Zasób interfejsu API. Zasób ma też komentarz, zbiór cech, stan i wiele innych pól, ale to żądanie wysyła tylko pole title, ponieważ tylko ono zostało zmienione:

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

{
  "title": "New title"
}

Odpowiedź:

200 OK

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

Serwer zwraca kod stanu 200 OK i pełną reprezentację zaktualizowanego zasobu. Żądanie poprawki dotyczy tylko pola title, dlatego jest to jedyna wartość inna niż we wcześniejszym przykładzie.

Uwaga: jeśli użyjesz parametru fields odpowiedzi częściowej w połączeniu z poprawką, możesz jeszcze bardziej zwiększyć wydajność żądań aktualizacji. Żądanie poprawki zmniejsza tylko rozmiar żądania. Odpowiedź częściowa zmniejsza rozmiar odpowiedzi. Aby zmniejszyć ilość danych wysyłanych w obie strony, użyj żądania poprawki z parametrem fields.

Semantyka żądania poprawki

Treść żądania poprawki zawiera tylko pola zasobów, które chcesz zmienić. Gdy określasz pole, musisz uwzględnić wszystkie obiekty nadrzędne, tak jak obiekty nadrzędne są zwracane w odpowiedzi częściowej. Zmodyfikowane dane, które wysyłasz, są scalane z danymi obiektu nadrzędnego (jeśli istnieje).

• Dodawanie: aby dodać pole, które jeszcze nie istnieje, podaj nowe pole i jego wartość.
• Zmiana:aby zmienić wartość istniejącego pola, podaj jego nazwę i ustaw je na nową wartość.
  
• Usuwanie: aby usunąć pole, podaj jego nazwę i ustaw je na null. Na przykład: "comment": null. Możesz też usunąć cały obiekt (jeśli jest zmienny), ustawiając go na null. Jeśli używasz tagu Biblioteka klienta interfejsu Java API – użyj Data.NULL_STRING; w przypadku szczegółowe informacje znajdziesz na stronie Wartość JSON w przypadku wartości null.

Uwaga na temat tablic: żądania poprawki z tablicami zastępują dotychczasową tablicę tą podaną przez Ciebie. Nie możesz zmieniać, dodawać ani usuwać elementów tablicy stopniowo.

Używanie poprawki w cyklu odczytu, modyfikacji i zapisu

Warto najpierw pobrać odpowiedź częściową z danymi, które chcesz zmienić. Jest to szczególnie ważne w przypadku zasobów używających znaczników ETag, ponieważ musisz podać bieżącą wartość ETag w nagłówku HTTP If-Match, aby zaktualizować zasób. Po pobraniu danych możesz zmienić wartości i wysłać zmienioną częściową reprezentację z żądaniem poprawki. Oto przykład, w którym założono, że zasób Demo używa znaczników ETag:

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

Oto odpowiedź częściowa:

200 OK

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

Żądanie poprawki poniżej oparte jest na tej odpowiedzi. Jak widzisz, użyliśmy też parametru fields, aby ograniczyć ilość danych zwracanych w odpowiedzi poprawki:

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. */
  },
}

Serwer w odpowiedzi przesyła kod stanu HTTP 200 OK i częściową reprezentację zaktualizowanego zasobu:

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. */
  }
}

Bezpośrednie tworzenie żądania poprawki

W przypadku niektórych żądań zastosowania poprawki musisz oprzeć je na wcześniej pobranych danych. Jeśli na przykład chcesz dodać element do tablicy bez utraty żadnych istniejących elementów tablicy, musisz najpierw pobrać istniejące dane. Podobnie, jeśli interfejs API używa znaczników ETag, wraz z żądaniem musisz wysłać poprzednią wartość ETag, aby zaktualizować zasób.

Uwaga: aby wymusić zastosowanie poprawki, gdy są używane znaczniki ETag, możesz użyć nagłówka HTTP "If-Match: *". W takim przypadku nie trzeba będzie wykonywać odczytu przed zapisem.

W innych przypadkach możesz jednak utworzyć żądanie poprawki bezpośrednio bez wcześniejszego pobierania istniejących danych. Możesz na przykład łatwo skonfigurować żądanie poprawki, które aktualizuje pole do nowej wartości lub dodaje nowe pole. Oto przykład:

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
  }
}

W przypadku tego żądania, jeśli pole komentarza zawiera już wartość, zostanie ona zastąpiona przez nową. W przeciwnym razie zostanie ustawiona nowa wartość. Podobnie, jeśli miała cechę głośności, jej wartość jest zastępowana. w przeciwnym razie zostaje utworzony. Pole dokładności (jeśli jest ustawione) zostanie usunięte.

Obsługa odpowiedzi na poprawkę

Po przetworzeniu prawidłowego żądania poprawki interfejs API zwraca kod odpowiedzi HTTP 200 OK i pełną reprezentację zmodyfikowanego zasobu. Jeśli interfejs API używa znaczników ETag, serwer aktualizuje wartości ETag po przetworzeniu żądania poprawki, tak jak w przypadku PUT.

Żądanie poprawki zwraca reprezentację całego zasobu, chyba że użyto parametru fields, aby zmniejszyć ilość zwracanych danych.

Jeśli żądanie poprawki powoduje ustawienie nowego stanu zasobu, który jest składniowo lub semantycznie nieprawidłowy, serwer zwraca kod stanu HTTP 400 Bad Request lub 422 Unprocessable Entity, a stan zasobu pozostaje bez zmian. Jeśli na przykład spróbujesz usunąć wartość pola wymaganego, serwer zwróci błąd.

Alternatywny zapis, gdy czasownik HTTP PATCH nie jest obsługiwany

Jeśli zapora sieciowa nie zezwala na żądania HTTP PATCH, wykonaj żądanie HTTP POST i ustaw nagłówek zastąpienia na PATCH w ten sposób:

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

Różnica między poprawką a aktualizacją

W praktyce, gdy wysyłasz dane żądania aktualizacji, które używa czasownika HTTP PUT, musisz wysłać tylko te pola, które są wymagane lub opcjonalne. Jeśli wyślesz wartości pól ustawionych przez serwer, zostaną one ignorowane. Może się to wydawać inny sposób przeprowadzania częściowej aktualizacji, jednak ma on pewne ograniczenia. W przypadku aktualizacji, które używają czasownika HTTP PUT, żądanie nie powiedzie się, jeśli nie podasz wymaganych parametrów, i wyczyści wcześniej ustawione dane, jeśli nie podasz parametrów opcjonalnych.

Z tego powodu znacznie bezpieczniej jest użyć poprawki. Podajesz tylko dane pól, które chcesz zmienić; Pominięte pola nie są opróżniane. Jedynym wyjątkiem od tej reguły są powtarzające się elementy lub tablice. Jeśli pominiesz je wszystkie, pozostaną bez zmian. Jeśli podasz którykolwiek z nich, cały zestaw zostanie zastąpiony zestawem podanym przez Ciebie.

Omówienie

Każde połączenie HTTP powoduje pewne narzuty. Interfejs Google Drive API obsługuje grupowanie, dzięki czemu klient może umieścić kilka wywołań interfejsu API w jednym żądaniu HTTP.

Przykłady sytuacji, w których warto używać grupowania:

• Pobieram metadane dla dużej liczby plików.
• Zbiorcze aktualizowanie metadanych lub usług.
• zmienianie uprawnień dotyczących dużej liczby plików, na przykład dodawanie nowego użytkownika lub grupy;
• Synchronizuję lokalne dane klienta po raz pierwszy lub gdy jesteś w trybie offline przez dłuższy czas.

W każdym przypadku zamiast wysyłać każde wywołanie osobno, możesz je zgrupować w jedno żądanie HTTP. Wszystkie żądania wewnętrzne muszą trafiać do tego samego interfejsu API Google.

Jedno żądanie zbiorcze może zawierać maksymalnie 100 wywołań. Jeśli musisz wykonać więcej wywołań, użyj wielu żądań zbiorczych.

Uwaga: system wsadowy dla interfejsu Google Drive API ma taką samą składnię jak system przetwarzania wsadowego OData, ale semantyka jest inna.

Dodatkowe ograniczenia:

• Żądania zbiorcze z ponad 100 wywołaniami mogą powodować błąd.
• Długość adresu URL każdego wewnętrznego żądania jest ograniczona do 8000 znaków.
• Dysk Google nie obsługuje operacji wsadowych na multimediach (zarówno przy przesyłaniu, pobieraniu, jak i eksportowaniu plików).

Szczegóły wsadu

Żądanie zbiorcze składa się z kilku wywołań interfejsu API połączonych w jedno żądanie HTTP, które może zostać wysłane do batchPath wskazanego w dokumencie na temat wykrywania interfejsów API. Ścieżka domyślna to /batch/api_name/api_version. W tej sekcji szczegółowo opisujemy składnię wsadu. oto przykład.

Uwaga: zbiór n zbiorczych żądań wlicza się do limitu wykorzystania jako żądania n, a nie jako jedno żądanie. Przed przetworzeniem żądanie zbiorcze jest dzielone na zestaw żądań.

Format żądania zbiorczego

Żądanie zbiorcze to pojedyncze standardowe żądanie HTTP zawierające wiele wywołań interfejsu Google Drive API, używające typu treści multipart/mixed. Każda część tego głównego żądania HTTP zawiera zagnieżdżone żądanie HTTP.

Każda część zaczyna się od własnego nagłówka HTTP Content-Type: application/http. Może też mieć opcjonalny nagłówek Content-ID. Nagłówki części są jednak przeznaczone tylko do oznaczenia początku danej części, są niezależne od żądania zagnieżdżonego. Gdy serwer wyodrębni żądanie zbiorcze na osobne żądania, nagłówki części są ignorowane.

Treść każdej części to kompletne żądanie HTTP z własnym czasownikiem, adresem URL, nagłówkami i treścią. Żądanie HTTP może zawierać tylko ścieżkę adresu URL. w żądaniach zbiorczych nie można używać pełnych adresów URL.

Nagłówki HTTP zewnętrznego żądania zbiorczego, z wyjątkiem nagłówków Content-, takich jak Content-Type, mają zastosowanie do każdego żądania wsadu. Jeśli określony nagłówek HTTP określisz zarówno w żądaniu zewnętrznym, jak i w pojedynczym wywołaniu, wartość nagłówka tego wywołania zastąpi wartość zewnętrznego nagłówka żądania zbiorczego. Nagłówki pojedynczego połączenia odnoszą się tylko do tego połączenia.

Jeśli na przykład podasz nagłówek autoryzacji dla określonego wywołania, będzie on stosowany tylko do tego wywołania. Jeśli podasz nagłówek autoryzacji dla żądania zewnętrznego, będzie on stosowany do wszystkich poszczególnych wywołań, chyba że zastąpią go własnym nagłówkiem autoryzacji.

Po otrzymaniu żądania zbiorczego serwer stosuje do każdej części parametry zapytania i nagłówki żądania zewnętrznego (odpowiednio) do każdej części, a następnie traktuje każdą część jako osobne żądanie HTTP.

Odpowiedź na żądanie zbiorcze

Odpowiedź serwera to pojedyncza standardowa odpowiedź HTTP z typem treści multipart/mixed. każda część to odpowiedź na jedno z żądań w żądaniu zbiorczym, w tej samej kolejności co żądania.

Podobnie jak części żądania, każda odpowiedź zawiera pełną odpowiedź HTTP, w tym kod stanu, nagłówki i treść. Podobnie jak w przypadku części żądania, każda część odpowiedzi jest poprzedzona nagłówkiem Content-Type, który określa jej początek.

Jeśli dana część żądania miała nagłówek Content-ID, odpowiadająca jej część ma pasujący nagłówek Content-ID, w którym pierwotna wartość jest poprzedzona ciągiem response- (jak pokazano w przykładzie poniżej).

Uwaga: serwer może wykonywać połączenia w dowolnej kolejności. Nie licz na ich wykonanie w kolejności, w jakiej zostały one określone. Jeśli chcesz mieć pewność, że w danej kolejności będą wykonywane 2 wywołania, nie możesz ich wysłać w jednym żądaniu. wyślij pierwszy e-mail samodzielnie, a następnie zaczekaj, aż odpowiesz na pierwszy, przed wysłaniem kolejnego.

Przykład

Poniższy przykład pokazuje wykorzystanie grupowania za pomocą interfejsu Google Drive API.

Przykładowe żądanie zbiorcze

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--

Przykładowa odpowiedź zbiorcza

To jest odpowiedź na przykładowe żądanie podane w poprzedniej sekcji.

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--