Migracja z interfejsu Drive Activity API w wersji 1

W tym przewodniku znajdziesz informacje o różnicach między interfejsem Google Drive Activity API w wersji 1 i 2 oraz o tym, jak zmienić aplikację w wersji 1, aby obsługiwała interfejs API w wersji 2.

Upoważnienie

Interfejs API w wersji 1 używał tego zakresu:

  • https://www.googleapis.com/auth/activity

Interfejs API w wersji 2 wymaga jednego z tych zakresów:

  • https://www.googleapis.com/auth/drive.activity
  • https://www.googleapis.com/auth/drive.activity.readonly

Nazwy zasobów

W interfejsie API w wersji 1 identyfikatory obiektów, takich jak elementy na Dysku Google i użytkownicy, były nieprzejrzyste. W interfejsie API w wersji 2 do tych obiektów odwołują się zwykle nazwy zasobów. Więcej informacji znajdziesz w przewodniku po projektowaniu interfejsu Cloud API.

Identyfikatory te można zwykle przekonwertować. Na przykład odwołania do elementów na Dysku w interfejsie API w wersji 2 są określane przy użyciu nazwy zasobu items/ITEM_ID_V1.

Żądania

Format żądania w przypadku wersji 2 jest podobny do tego w wersji 1. W szczególności możesz nadal wysyłać żądania aktywności dotyczącej pliku na Dysku lub elementu nadrzędnego na Dysku, ale pamiętaj, że musisz sformatować te parametry żądania jako nazwy zasobów, dodając do nich prefiks items/.

„Grupowanie” nosi teraz nazwę Konsolidacja i zostały usunięte parametry żądań source oraz userId.

Dostępne są też nowe opcje Filtr, które umożliwiają ograniczenie typów danych o aktywności zwracanych w odpowiedzi.

Działania

W interfejsie API w wersji 1 typ działania i powiązane z nim dane znajdowały się w osobnych polach. Jeśli na przykład pole primaryEventType zawiera wartość move, aplikacje zakładały, że pole move najwyższego poziomu jest wypełnione dodanymi i usuniętymi elementami nadrzędnymi.

W interfejsie API w wersji 2 te pola się już nie różnią. Wiadomość ActionDetail ma ustawione dokładnie jedno pole. Oznacza ono typ działania i zawiera powiązane z nim szczegóły. Na przykład obiekt ActionDetail reprezentujący przeniesienie ustawia tylko pole move, które zawiera listę dodanych i usuniętych elementów nadrzędnych.

Pole primaryEventType w interfejsie API w wersji 1 niemal odpowiada wartości primaryActionDetail w wersji 2.

Actors

W interfejsie API w wersji 1 zwrócona aktywność zawierała wartość User (jeśli użytkownik był znany jako użytkownik) i opcjonalnie zawierał pole najwyższego poziomu, np. fromUserDeletion (w przypadkach specjalnych).

W interfejsie API w wersji 2 dostępny jest bogatszy zestaw typów Actor, a pole user.knownUser jest wypełniane, gdy użytkownik jest znany. Jeśli Twoja aplikacja potrzebuje szczegółowych informacji o użytkownikach, może wysłać do niej zapytanie z poziomu People API, przekazując pole KnownUser personName do metody people.get.

Miejsca docelowe

W interfejsie API w wersji 1 cele były zawsze elementami na Dysku. W interfejsie API w wersji 2 celami mogą być inne typy obiektów na Dysku. Na przykład zmiany na dysku mają typ celu Drive. Folder główny dysku współdzielonego jest nadal zwracany (jako DriveItem w polu root), ale nie jest bezpośrednim celem aktywności. Podobna koncepcja dotyczy zasobu FileComment, którego pole parent odnosi się do elementu na Dysku zawierającego docelowy wątek komentarza.

Skonsolidowana aktywność

W interfejsie API w wersji 1 styl odpowiedzi zmienił się po ustawieniu strategii konsolidacji („grupowania”). Po włączeniu konsolidacji każda aktywność zawierała składnik singleEvents i combinedEvent, które podsumowywały wspólną aktywność tych zdarzeń. Po wyłączeniu konsolidacji pole combinedEvent zawierało pierwotne nieskonsolidowane zdarzenie dla każdej aktywności. Każde z tych zdarzeń może reprezentować więcej niż 1 działanie, np. utworzenie i udostępnienie.

W interfejsie API w wersji 2 styl odpowiedzi nie zmienia się w zależności od strategii konsolidacji, ponieważ zwracany obiekt DriveActivity zawsze zawiera pełny zbiór podmiotów, celów i działań.