Warnung: Diese Seite bezieht sich auf die älteren Google Data APIs. Sie ist nur für die APIs relevant, die im Verzeichnis der Google Data APIs aufgeführt sind. Viele davon wurden durch neuere APIs ersetzt. Informationen zu einer bestimmten neuen API finden Sie in der Dokumentation der neuen API. Informationen zum Autorisieren von Anfragen mit einer neueren API finden Sie unter Authentifizierung und Autorisierung von Google-Konten.

Google hat es sich zur Mission gemacht, die Informationen der Welt zu organisieren und allgemein nutzbar und zugänglich zu machen. Dazu gehört auch, dass Informationen nicht im Webbrowser und für Dienste außerhalb von Google zugänglich sind.

Das Google-Datenprotokoll bietet externen Entwicklern eine sichere Möglichkeit, neue Anwendungen zu schreiben, mit denen Endnutzer auf die Daten zugreifen können, die in vielen Google-Produkten gespeichert sind. Externe Entwickler können das Google-Datenprotokoll direkt oder eine der unterstützten Programmiersprachen verwenden, die von den Clientbibliotheken bereitgestellt werden.

Zielgruppe

Diese Dokumente sind für alle gedacht, die das Google-Datenprotokoll verstehen möchten. Auch wenn Sie nur Code schreiben möchten, der die sprachspezifischen Clientbibliotheken verwendet, kann dieser Dokumentsatz hilfreich sein, wenn Sie verstehen möchten, was unter der Abstraktionsebene „Clientbibliothek“ geschieht.

Das Entwicklerhandbuch für eine bestimmte API finden Sie im API-Verzeichnis für Google Data Protocol.

Wenn Sie auf eine API in Ihrer bevorzugten Programmiersprache zugreifen möchten, besuchen Sie die Downloadseite für Clientbibliotheken.

Hintergrund

Einige Google-Produkte wie Google Kalender und Google Tabellen bieten APIs, die auf dem Google-Datenprotokoll basieren. Sie, der Entwickler, können diese APIs nutzen, um Client-Anwendungen zu schreiben, die Endnutzern neue Möglichkeiten für den Zugriff auf und die Bearbeitung von Daten bieten, die in diesen Google-Produkten gespeichert sind.

Hinweis: Google-Produkte, die APIs bereitstellen, werden in diesen und anderen zugehörigen Dokumenten manchmal als Dienste bezeichnet.

Wenn Sie Code schreiben, der das Google Data Protocol direkt verwendet, greift er über HTTP-Anfragen wie GET oder POST auf die API zu. Bei diesen Anfragen werden die vom Google-Produkt gespeicherten Daten in Form von Datenfeeds über das Kabel übertragen. Die Datenfeeds sind einfach strukturierte Listen, die die Daten enthalten. Früher war das Hauptfeedformat AtomPub XML, aber jetzt ist JSON oder JavaScript Object Notation auch als alternatives Format verfügbar.

Wenn Sie keinen Code schreiben möchten, der HTTP-Anfragen direkt sendet, können Sie Ihre Clientanwendung stattdessen mit einer der Programmiersprachen programmieren, die in den bereitgestellten Clientbibliotheken verfügbar sind. Dabei werden die Details der HTTP-Anfragen von der Clientbibliothek verarbeitet. Sie schreiben Ihren Code auf einer konzeptionellen Ebene und verwenden dazu die sprachspezifischen Methoden und Klassen der Clientbibliothek.

Weitere Informationen zu den Sprachen, die für die von Ihnen verwendete API oder API-Version verfügbar sind, finden Sie in der produktspezifischen Dokumentation.

Versionen des Protokolls

Protokollversion 2.0 im Vergleich zu Protokollversion 1.0

Die erste Version des Google-Datenprotokolls wurde entwickelt, bevor das Atom-Publishing-Protokoll abgeschlossen wurde. Die zweite Version des Google-Datenprotokolls ist vollständig mit dem AtomPub-Standard RFC 5023 kompatibel.

Das Google Data Protocol Version 2.0 bietet außerdem Unterstützung für:

• HTTP-ETags. Ein Webstandard, der Ihren Clientanwendungen dabei hilft, HTTP-Caching besser zu nutzen. Die Dienste in den Clientbibliotheken, die Protokoll v2.0 unterstützen, verarbeiten ETags automatisch.
• Teilantwort und Teilaktualisierung (experimentell). Funktionen, mit denen Sie Anfragen mit weniger Daten senden können Wenn Sie nur die Informationen anfordern, die Sie wirklich benötigen, oder wenn Sie Aktualisierungen senden, die nur die Daten enthalten, die Sie tatsächlich ändern möchten, kann Ihre Clientanwendung Netzwerk-, CPU- und Speicherressourcen viel effizienter nutzen. Derzeit sind nur teilweise Antworten und teilweise Updates verfügbar. In der produktspezifischen Dokumentation können Sie nachlesen, ob Ihre API dies unterstützt.

Anwendung aktualisieren

Wenn die von Ihnen verwendete API auf der neuesten Version des Protokolls basiert, finden Sie die Funktionalität der Protokollversion 2.0 in der Dokumentation. Im Allgemeinen empfehlen wir, dass Sie Ihre Client-Anwendung auf die neueste Version aktualisieren, die für Ihre API verfügbar ist.

Clientbibliotheken-basierten Client aktualisieren

Wenn Ihre Clientbibliothek eine Clientbibliothek verwendet, z. B. die Java-Clientbibliothek oder die .NET-Clientbibliothek, enthält sie möglicherweise eine Version der API, die Protokollfunktionen der Version 2.0 unterstützt. In der API-Dokumentation für das von Ihnen verwendete Google-Produkt können Sie herausfinden, ob die folgenden beiden Bedingungen zutreffen:

• Es gibt eine API-Version, die Funktionen von Google Data Protocol v2.0 unterstützt.
• Die von Ihnen verwendete Clientbibliothek unterstützt auch diese API-Version.

Wenn die Clientbibliothek diese unterstützt und Sie Ihre vorhandene Anwendung aktualisieren möchten, laden Sie einfach die neueste Version der Clientbibliothek herunter und verwenden Sie sie. Der gesamte Code funktioniert weiterhin und die Clientbibliothek übernimmt die Änderungen im Protokoll Version 2.0.

Raw-HTTP-Client aktualisieren

Wenn Sie Ihre Clientanwendung direkt mit dem Google Data Protocol geschrieben haben, müssen Sie folgende Änderungen vornehmen:

• Nicht standardmäßige Versionsanfragen. Fügen Sie jeder gesendeten HTTP-Anfrage einen HTTP-Versionsheader (GData-Version: X.0) hinzu, wobei X die API-Version ist, die Funktionen von Google Data Protocol v2.0 unterstützt. Alternativ können Sie der URL jeder Anfrage einen Abfrageparameter (v=X.0) hinzufügen, wobei X wieder die richtige Version der API ist. Wenn Sie keine spätere Version angeben, werden Ihre Anfragen standardmäßig an die früheste unterstützte Version der API gesendet.
• Optimistische Nebenläufigkeit Wenn Sie eine Version einer API verwendet haben, die optimistische Nebenläufigkeit unterstützt, müssen Sie möglicherweise das Update ändern und den Code löschen, um ETags zu verwenden. Weitere Informationen finden Sie in der Google Data Protocol-Referenzdokumentation im Abschnitt ETags und in den Abschnitten zum Aktualisieren und Löschen des Protokollentwicklerhandbuchs für den Dienst, den Ihre Clientanwendung verwendet.
• Selbst- oder Bearbeitungs-URIs. Wenn sich Ihr Kunde die Möglichkeit bietet, URIs für sich selbst zu bearbeiten oder URIs für Feeds oder Einträge zu bearbeiten, müssen sich die URIs möglicherweise geändert haben. Um den neuen URI zu erhalten, fordern Sie das Element noch einmal mit dem alten URI an, aber kennzeichnen Sie die Anfrage als X-Anfrage.Dabei steht X für die Version der API, die Funktionen von Google Data Protocol v2.0 unterstützt. Der Server gibt die neue Darstellung des Eintrags zurück, einschließlich der neuen URIs, die Sie anstelle der alten speichern können.
• Namespace-URIs: Wenn Ihr Client die Namespace-URIs der Google Data Protocol API lokal speichert oder hartcodiert hat, müssen Sie diese aktualisieren:
  • Der AtomPub-Namespace (Präfix app) wurde von http://purl.org/atom/app in http://www.w3.org/2007/app geändert.
  • Der OpenSearch-Namespace (Präfix openSearch) wurde von http://a9.com/-/spec/opensearchrss/1.0/ zu http://a9.com/-/spec/opensearch/1.1/ geändert.