Kontakte mit dem CardDAV-Protokoll verwalten

Sie können Ihre Kontakte mit dem CardDAV-Protokoll von Google aufrufen 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.

Für jede relevante Spezifikation gilt Folgendes:

• rfc2518: HTTP Extensions for Distributed Authoring (WebDAV)
  • 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: WebDAV-Sammlungen über POST-Anfragen Mitglieder hinzufügen
  • Unterstützt das Erstellen neuer Kontakte ohne Angabe einer ID.
• rfc6352: CardDAV: vCard-Erweiterungen für Web Distributed Authoring und Versionsverwaltung (WebDAV)
  • Die HTTP-Methode REPORT wird unterstützt, aber nicht alle definierten Berichte sind implementiert.
  • Unterstützt die Bereitstellung einer Hauptkontosammlung und einer Kontaktsammlung.
• rfc6578: Sammlungssynchronisierung für WebDAV
  • Clientanwendungen müssen nach der Erstsynchronisierung in diesen Betriebsmodus wechseln.
• rfc6749: The OAuth 2.0 Authorization Framework und rfc6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage
  • Unterstützt die Authentifizierung von CardDAV-Clientprogrammen mit OAuth 2.0-HTTP-Authentifizierung. Google unterstützt keine andere Authentifizierungsmethode. Zum Schutz von Kontaktdaten müssen CardDAV-Verbindungen HTTPS verwenden.
• rfc6764: Dienste für Kalendererweiterungen an WebDAV (CalDAV) und vCard-Erweiterungen zu WebDAV (CardDAV) lokalisieren
  • Das Bootstrapping von CardDAV-URLs muss gemäß Abschnitt 6 der rfc6764.
• Unterstützt caldav-ctag-02: Calendar Collection Entity Tag (CTag) in CalDAV, das in den CardDAV- und CalDAV-Spezifikationen verwendet 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-Oberfläche 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:

• Mit OAuth 2.0 auf Google APIs zugreifen
• OAuth 2.0 für installierte Anwendungen verwenden

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 einer E-Mail-Adresse/einem Passwort herzustellen, das nicht mit einem Google-Konto übereinstimmt, führt zu einem HTTP-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 würde den Rahmen dieses Dokuments sprengen. Weitere Informationen finden Sie unter rfc6352.

Der Weiterleitungspfad, der in der HTTP 301-Antwort über eine PROPFIND auf dem bekannten URI zurückgegeben wird, darf nicht dauerhaft im Cache gespeichert werden (gemäß rfc6764). Geräte sollten die Suche nach bekannten URIs regelmäßig wiederholen, um zu prüfen, ob der im Cache gespeicherte Pfad noch aktuell ist, und sich neu synchronisieren, falls sich der Pfad ändert. Google empfiehlt eine Häufigkeit von alle zwei bis vier Wochen.

Ressourcen

CardDAV verwendet 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.

1. Hauptkonto
   • https://www.googleapis.com/carddav/v1/principals/userEmail
2. Home Set
   • https://www.googleapis.com/carddav/v1/principals/userEmail/lists
3. Adressbuch
   • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default
4. Kontakt
   • 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
  • Clientprogramme verwenden die getctag PROPFIND-Anfrage im Adressbuch. um festzustellen, ob sich Kontakte auf dem Server geändert haben. ob eine Synchronisierung erforderlich ist. Der Wert dieser Eigenschaft bei Kontaktänderungen. Clientanwendungen sollten diesen Wert speichern und nur bei der Erstsynchronisierung und als Fallback verwenden, wenn ein sync-token ungültig ist. Regelmäßige Abfragen der Property getctag führen zu einer Drosselung.
• Sync-Token verwenden
  • Clientprogramme verwenden die sync-token PROPFIND-Anfrage an das Adressbuch, um den sync-token zu erhalten, der den aktuellen Status darstellt. 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 Tokens sind 29 Tage lang gültig und die REPORT-Antwort enthält eine neue sync-token.
• ETags verwenden
  • Clientanwendungen senden eine getetag PROPFIND-Anfrage an die Adresse Buchressource (mit dem Header DEPTH ist DEPTH_1). Durch die Aufrechterhaltung ETag-Wert jedes Kontakts kann ein Client-Programm den Wert der Kontakte, deren ETag geändert wurde.
• Kontakte abrufen
  • 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. Jeder Eintrag enthält eine ETag für den Kontakt.
• Kontakt einfügen
  • Clientanwendungen senden eine POST-Anfrage mit dem neuen Kontakt im VCard 3.0-Format. Die Antwort enthält die ID des neuen Kontakts.
• Kontakt aktualisieren
  • 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 die PUT-Anfrage (mit HTTP 412) ab, wenn sich die aktuelle ETag auf dem Server von der ETag unterscheidet, die vom Clientprogramm gesendet wurde. So können Sie optimistische Serialisierung von Updates.
• Kontakt löschen
  • Clientanwendungen löschen einen Kontakt durch Senden einer DELETE-Anfrage mit der Kontakt-URI.