Dies ist der erste Beitrag meiner Serie über die Arbeit mit Google Drive APIs.
Man kann nicht wirklich im Internet leben, ohne jemals damit in Berührung gekommen zu sein. Wenn Sie dies lesen, sind Sie höchstwahrscheinlich ein begeisterter Nutzer.
Aus der Sicht der Nutzer ist es natürlich ein großartiges Produkt. Mit der ersten Veröffentlichung vor mehr als 10 Jahren - als es den heute weit verbreiteten Namen Drive noch gar nicht gab, sondern nur Docs, Sheets und Slides - wurde die Online-Zusammenarbeit weit verbreitet. Aufgrund der engen Integration zwischen den verschiedenen G Suite-Produkten ist der Bedarf an Unternehmenslösungen, die diese nutzen - oder sogar darauf aufbauen -, heutzutage stark gestiegen. Ich hatte das Glück - nun ja, das ist fraglich, und Sie werden später sehen, warum 😉 -, lange Zeit damit arbeiten zu können.
Nun, lange Zeit scheint ein wenig übertrieben, wenn man bedenkt, dass es vor ein paar Monaten erst 5 Jahre her ist, aber aufgrund des Alters des gesamten Produkts fühle ich mich immer noch wie ein Methusalem. Wenn ich zurückblicke, haben wir Lösungen geschaffen, von denen ich nie gedacht hätte, dass wir sie entwickeln würden, aber wir haben dabei auch viel Mist gebaut.
Ich glaube, auch Google war überrascht, wie populär es in nur wenigen Jahren wurde. Sicherlich war es nicht das, was es den Nutzern versprochen hat und was man in den Marketingunterlagen für Google Apps - dem Mädchennamen von G Suite - sehen konnte, aber wenn Sie jemals versucht haben, sich damit zu integrieren, konnten Sie sicherlich die Nachteile und die Hinweise darauf sehen, dass dies nicht als Unternehmensprodukt mit einem solchen Umfang geplant war. Nachdem ich diesen Satz geschrieben hatte, hörte ich bereits viele von Ihnen aufschreien, wie ungerecht ich Drive gegenüber sei - da keiner der Konkurrenten besser sei. Nun, ich glaube nicht, dass ich das bin. Ich meinte nur die Integration auf Unternehmensebene mit einem großen Funktionsumfang und einem enormen Durchsatz, und vorzugsweise Projekte, die schon vor Jahren begonnen wurden, denn die Probleme, die ich jetzt beschreiben werde, ähneln den Regenwäldern. Sie neigen dazu, mit der Zeit abzunehmen. Zumindest ist das in diesem Fall eine gute Nachricht :).
Obwohl ich bereits mit einigen älteren Diensten (wie Documents List API, Spreadsheets API) und einigen neueren (wie Drive API v3, Sheets API v4) gearbeitet habe. Die meiste Erfahrung habe ich mit Drive API v2... und nun ja, vergessen wir einfach die GData-Ära. Es ist für alle besser. Ich habe darüber nachgedacht, die Probleme zu ordnen und zu priorisieren, aber ich konnte keine vernünftige Regel dafür finden. Im Grunde könnte jedes Thema für eine Anwendung genauso wichtig sein wie für eine andere, also mache ich es so, wie es sich richtig anfühlt. Außerdem bin ich mir sicher, dass es schon sehr voreingenommen war, da ich mich an jede einzelne Stunde erinnere, in der ich über meine Berufswahl nachgedacht habe 😀 Also entschuldigt mich im Voraus, wenn ich vielleicht abschweife - oder sogar schimpfe -, aber so "bewältige" ich das... es ist billiger als zu trinken ;). ... und bitte bedenken Sie, dass viele Erfahrungen, die ich hier beschreibe, geschahen, bevor es richtig dokumentiert und/oder behoben wurde.
Eine der wahrscheinlich am häufigsten benötigten Funktionen, die fehlt, ist, dass man über die API nicht in einer Ordnerhierarchie suchen kann. Sie können zwar global oder in einem bestimmten Ordner suchen, aber nicht in Unterordnern. Obwohl diese Funktion in der Drive-Benutzeroberfläche vorhanden ist - sie wurde kürzlich veröffentlicht -, gibt es keine API-Methode dafür.
Wahrscheinlich liegt es auch an der ursprünglichen Architektur. Damals hatten die Dokumente Etiketten statt Ordnern und wurden nicht wie heute in Ordnern dargestellt. Das war ähnlich wie bei Gmail, wo die Etiketten immer noch dargestellt werden. Bei der Umbenennung wurden einige Funktionen hinzugefügt, aber das Kernkonzept ist im Wesentlichen dasselbe.
Wenn Sie Ihre Netzwerkaktivität bei der Verwendung der Drive-Benutzeroberfläche überprüfen, können Sie viele /drive/v2internal/-Aufrufe entdecken. Dabei handelt es sich nicht um die veröffentlichte Version 2, die mehr Funktionen enthält. Leider werden viele von ihnen nicht in die öffentliche API übernommen - oder zumindest nur sehr langsam.
Beispiele:
Die bereits erwähnte Funktion "Suche in Unterordnern".
Kopieren von Kommentaren und Vorschlägen in Google Docs, Sheets und Slides.
Benennen von Versionen eines Dokuments, einer Tabelle oder einer Folie.
Wenn eine Datei für die Domain freigegeben ist, der Nutzer sie aber noch nie geöffnet hat - was z. B. bei neuen Konten und/oder neuen Dateien zu erwarten ist -, dann wird sie nicht in der Standard-Ergebnisliste angezeigt, wenn Sie in Drive danach suchen. Sie müssen den "Speicherort" von "Überall" auf "Sichtbar für jeden in IhrerDomain.com" ändern. Ich kann mir kein Szenario vorstellen, in dem dies aus geschäftlicher Sicht Sinn macht - dass es nicht in der Standardeinstellung enthalten ist - abgesehen von der Möglichkeit, dass es eine direkte Auswirkung einer Architektur ist, die ursprünglich nicht für diesen Zweck gebaut wurde.
Es ist ein recht häufiger Anwendungsfall, Änderungsmeldungen zu abonnieren bzw. zu "beobachten". Wir machen das sehr oft. Es ist auch üblich, die Datei, über die Sie Benachrichtigungen erhalten haben, weiter zu verändern.
Um bei unserem Beispiel zu bleiben: Stellen Sie sich vor, Sie überprüfen nicht immer den aktuellen Status von Drive oder den Inhalt des Patches, den Sie gerade erstellt haben - ob er leer ist oder nicht - Sie führen einfach die Anfrage aus. Das kommt vor. Entwickler sind faul. Was Sie also getan haben, war im Grunde eine Noop-Änderung, aber wir sind auf mehrere Fälle gestoßen, in denen Anfragen wie diese eine neue Änderungsmeldung für dieselbe Datei ausgelöst haben. Die wir bearbeitet haben. Erneut. Eine noop-Anfrage ausgeführt. Erneut. Ich denke, Sie können sehen, worauf das hinausläuft 🙂 Dieses Problem hatte einen noch schwierigeren Hintergrund. Wir wollten eigentlich etwas ändern, aber wir konnten es nicht. Stellen Sie sich vor, dass wir versuchen, den Titel und die Eltern in der gleichen Anfrage zu ändern, aber wir haben keinen Bearbeitungszugriff mehr auf den Ordner, in den wir die Datei verschieben wollen. Die Anfrage schlägt fehl, was eigentlich zu erwarten ist. Was nicht der Fall war, war, dass eine Änderungsbenachrichtigung ausgelöst wurde, die dafür sorgte, dass wir dies erneut versuchten. Es musste gespeichert werden, dass wir bereits auf eine unlösbare Weise gescheitert sind, um eine Schleife zu vermeiden.
Es gibt in der Drive-API keine Methode wie getEmailForId, und selbst getIdForEmail wurde nicht in v3 hinzugefügt und ist nur in v2 vorhanden. Es muss irgendeinen Grund für diese Entscheidung geben, aber ich kann ihn nicht erkennen. Es muss sein, dass sie die Zuordnung id->email als etwas ansehen, das man wissen muss, aber wie kann dieses Wissen ausgenutzt werden? Es könnte verwendet werden, um E-Mails für Spamming aufzulisten, aber angesichts der Länge der IDs gibt es einfache Möglichkeiten, das zu vermeiden, ohne eine nützliche Methode komplett abzuschaffen. In der Zwischenzeit könnte dies die Fehlersuche erheblich erschweren, z. B. wenn ein Konto geändert wird, um eine neue E-Mail-Adresse zu erhalten.
Das war's für heute, aber machen Sie sich keine Sorgen. Ich komme wieder... mit Ratenbegrenzung, Stapelverarbeitung und so weiter.
