Diese Seite wurde von der Cloud Translation API übersetzt.

Kontakte mit dem CardDAV-Protokoll verwalten

Sie können Ihre Kontakte mithilfe des CardDAV-Protokolls von Google abrufen und verwalten.

Kontakte werden im Google-Konto des Nutzers gespeichert. haben die meisten Google-Dienste auf die Kontaktliste zugreifen können. Ihre Clientanwendung kann mithilfe der CardDAV API folgende Aktionen ausführen: neue Kontakte erstellen, vorhandene Kontakte bearbeiten oder löschen und Kontakte abfragen die bestimmte Kriterien erfüllen.

Spezifikationen

Die vollständige Spezifikation ist nicht implementiert, aber viele Clients wie Apple iOSTM Kontakte und macOS sollte korrekt funktionieren.

Der CardDAV-Support von Google für jede relevante Spezifikation ist wie folgt:

rfc2518: HTTP Extensions for Distributed Authoring (WebDAV) <ph type="x-smartling-placeholder">
- Unterstützt die HTTP-Methoden GET, PUT, DELETE, OPTIONS und PROPFIND
- Unterstützt die HTTP-Methoden LOCK, UNLOCK, COPY, MOVE oder nicht MKCOL
- Unterstützt keine beliebigen (benutzerdefinierten) WebDAV-Properties.
- WebDAV-Zugriffssteuerung (rfc3744) wird nicht unterstützt.
rfc5995: Mitglieder mit POST zu WebDAV-Sammlungen hinzufügen <ph type="x-smartling-placeholder">
- Unterstützt das Erstellen neuer Kontakte ohne Angabe einer ID.
rfc6352: CardDAV: vCard-Erweiterungen für Web Distributed Authoring und Versionsverwaltung (WebDAV) <ph type="x-smartling-placeholder">
- Unterstützt die HTTP-Methode REPORT, aber nicht alle definierten Berichte sind implementiert.
- Unterstützt die Bereitstellung einer Hauptkontosammlung und einer Kontaktsammlung.
rfc6578: Sammlungssynchronisierung für WebDAV <ph type="x-smartling-placeholder">
- Client-Anwendungen müssen in diesen Betriebsmodus wechseln, nachdem der ersten Synchronisierung.
rfc6749: The OAuth 2.0 Authorization Framework und rfc6750: Das OAuth 2.0-Autorisierungs-Framework: Nutzung des Bearer-Tokens <ph type="x-smartling-placeholder">
- Unterstützt die Authentifizierung von CardDAV-Clientprogrammen mit OAuth 2.0 HTTP Authentifizierung. Google unterstützt keine anderen Authentifizierungsmethoden. Aus Sicherheitsgründen benötigen wir für die Verwendung von CardDAV-Verbindungen CardDAV-Verbindungen HTTPS
rfc6764: Dienste für Kalendererweiterungen an WebDAV (CalDAV) und vCard-Erweiterungen zu WebDAV (CardDAV) lokalisieren <ph type="x-smartling-placeholder">
- Das Bootstrapping von CardDAV-URLs muss gemäß Abschnitt 6 der rfc6764.
Wird unterstützt caldav-ctag-02: Calendar Collection Entity Tag (CTag) in CalDAV die zwischen der CardDAV- und der CalDAV-Spezifikation geteilt wird. Die Kontakte ctag ist wie die Ressource ETag. Änderungen an den Kontakteinstellungen, Adressbuch hat sich geändert. So kann das Client-Programm schnell feststellen, dass geänderte Kontakte nicht synchronisiert werden müssen.
Google verwendet VCard 3.0 als Kontaktcodierungsformat. Weitere Informationen: rfc6350: VCard 3.0

CardDAV von Google erfordert OAuth 2.0

Für die CardDAV-Schnittstelle von Google ist OAuth 2.0 erforderlich. Weitere Informationen finden Sie in der in der folgenden Dokumentation finden Sie Informationen zum Zugriff auf Google APIs mithilfe von OAuth 2.0:

Verbindung zum CardDAV-Server von Google herstellen

Das CardDAV-Protokoll ermöglicht die Erkennung des Adressbuchs und der Kontaktressourcen URIs. URIs dürfen nicht hartcodiert werden, da sie sich jederzeit ändern können.

Clientanwendungen müssen HTTPS verwenden und die OAuth 2.0-Authentifizierung muss die für das Google-Konto des Nutzers zur Verfügung stehen. Der CardDAV-Server wird Eine Anfrage authentifizieren, wenn sie nicht über HTTPS mit OAuth 2.0 eingeht Authentifizierung eines Google-Kontos und Ihre Anwendung ist auf DevConsole Jeder Versuch, eine Verbindung über HTTP mit Basisauthentifizierung oder mit Wenn eine E-Mail-Adresse/ein Passwort nicht mit einem Google-Konto übereinstimmt, wird eine HTTP-Anfrage ausgegeben. 401 Unauthorized-Antwortcode.

Zur Verwendung von CardDAV muss Ihr Clientprogramm zunächst eine Verbindung zur kanonischen URL Erkennungspfad durch Ausführen eines HTTP-PROPFIND-Vorgangs für:

https://www.googleapis.com/.well-known/carddav

Nach der Weiterleitung (HTTP 301) zu einer Adressbuchressource wird Ihr Clientprogramm kann dann einen PROPFIND-Vorgang ausführen, um zu ermitteln, DAV:current-user-principal, DAV:principal-URL und addressbook-home-set Eigenschaften. Ihr Client-Programm kann dann das Hauptadressbuch finden, indem es eine PROPFIND am addressbook-home-set durchführen und nach addressbook- und collection-Ressourcen. Eine vollständige Beschreibung dieses Prozesses wird in diesem Dokument nicht behandelt. Weitere Informationen finden Sie unter rfc6352 ein.

Der in der HTTP 301-Antwort über einen PROPFIND zurückgegebene Weiterleitungspfad bei Der bekannte URI darf nicht dauerhaft im Cache gespeichert werden (gemäß rfc6764 verfügbar. Geräte sollten einen bekannten Wiederholungsversuch ausführen Die URI wird regelmäßig ermittelt, um zu prüfen, ob der im Cache gespeicherte Pfad noch aktuell ist und falls sich der Pfad ändert. Google empfiehlt einen Steuersatz von alle zwei bis vier Wochen.

Ressourcen

CardDAV nutzt REST-Konzepte. Client-Anwendungen verhalten sich auf Ressourcen, die durch ihre URIs gekennzeichnet sind. Die aktuelle URI-Struktur wird hier angegeben, um die Entwickelnden mit den Konzepten des folgenden Abschnitts. Die Struktur kann geändert werden und dürfen nicht hartcodiert werden. Vielmehr sollten die Ressourcen entdeckt werden, gemäß RFC an.

Hauptkonto <ph type="x-smartling-placeholder">
- https://www.googleapis.com/carddav/v1/principals/userEmail
Set <ph type="x-smartling-placeholder">
- https://www.googleapis.com/carddav/v1/principals/userEmail/lists
Adressbuch <ph type="x-smartling-placeholder">
- https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default
Kontakt <ph type="x-smartling-placeholder">
- https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default/contactId

Kontakte synchronisieren

Im Folgenden finden Sie eine allgemeine Beschreibung der unterstützten Vorgänge. Entwickler*innen sollten Sie in der entsprechenden RFC nach den Details suchen. Anfragen und Antworten sind meistens in XML codiert. Das sind die vom Client verwendeten Hauptvorgänge Anwendungen für die Synchronisierung:

CTag verwenden <ph type="x-smartling-placeholder">
- Clientprogramme verwenden die getctag PROPFIND-Anfrage im Adressbuch. Ressource, um festzustellen, ob sich Kontakte auf dem Server geändert haben, und ob eine Synchronisierung erforderlich ist. Der Wert dieser Eigenschaft bei Kontaktänderungen. Clientanwendungen sollte diesen Wert speichern und nur bei der ersten Synchronisierung und als Fallback, wenn sync-token ungültig wird. Regelmäßige Abfragen des Das Attribut getctag führt zu einer Drosselung.
Synchronisierungstoken verwenden <ph type="x-smartling-placeholder">
- Clientprogramme verwenden die sync-token PROPFIND-Anfrage für die Address Buch, um die sync-token für den aktuellen Status abzurufen. Kunde Apps müssen diesen Wert speichern und regelmäßig sync-collection ausgeben REPORT Anfragen zur Ermittlung von Änderungen seit der letzten Ausgabe sync-token Ausgestellte Token sind 29 Tage lang gültig und die REPORT die Antwort ein neues sync-token enthält.
ETags verwenden <ph type="x-smartling-placeholder">
- Clientanwendungen senden eine getetag PROPFIND-Anfrage an die Adresse Buchressource (mit dem DEPTH-Header DEPTH_1). Durch die Aufrechterhaltung ETag-Wert jedes Kontakts kann ein Client-Programm den Wert der Kontakte, deren ETag geändert wurde.
Kontakte werden abgerufen <ph type="x-smartling-placeholder">
- Client-Anwendungen rufen Kontakte ab, indem sie eine addressbook-multiget REPORT-Anfrage. Bei einer Liste mit Kontakt-URIs gibt der Bericht alle angeforderten Kontakte als VCard 3.0-Werte zurück. Jedes enthält eine ETag für den Kontakt.
Kontakte einfügen <ph type="x-smartling-placeholder">
- Clientanwendungen senden eine POST-Anfrage an den neuen Kontakt in VCard. 3.0-Format. Die Antwort enthält die ID des neuen Kontakts.
Kontakt aktualisieren <ph type="x-smartling-placeholder">
- Clientanwendungen senden eine PUT-Anfrage mit dem aktualisierten Kontakt in VCard 3.0-Format. Der Kontakt wird aktualisiert, wenn der Kontakt bereits vorhanden ist. im Adressbuch.
- Clientanwendungen müssen einen If-Match-Header mit dem Parameter Kontakt ist derzeit bekannt (ETag). Der Server lehnt dann PUT ab. Anfrage (mit HTTP 412), wenn die aktuelle ETag auf dem Server unterscheidet sich vom ETag, das vom Clientprogramm gesendet wurde. So können Sie optimistische Serialisierung von Updates.
Kontakt löschen <ph type="x-smartling-placeholder">
- Clientanwendungen löschen einen Kontakt durch Senden einer DELETE-Anfrage mit der Kontakt-URI.