Administra contactos con el protocolo CardDAV

Puedes ver y administrar tus contactos con el protocolo CardDAV de Google.

Los contactos se almacenan en la Cuenta de Google del usuario. la mayoría de los servicios de Google acceso a la lista de contactos. Tu aplicación cliente puede usar la API de CardDAV para crear contactos nuevos, editar o borrar contactos existentes, y buscar contactos que coinciden con criterios particulares.

Especificaciones

La especificación completa no se implementa, pero muchos clientes como Contactos de Apple iOSTM y macOS deberían interoperar correctamente.

Para cada especificación relevante, la compatibilidad con CardDAV de Google es la siguiente:

• rfc2518: Extensiones HTTP para la creación distribuida (WebDAV)
  • Admite los métodos HTTP GET, PUT, DELETE, OPTIONS y PROPFIND
  • No admite los métodos HTTP LOCK, UNLOCK, COPY, MOVE ni MKCOL
  • No admite propiedades de WebDAV arbitrarias (definidas por el usuario).
  • No es compatible con el control de acceso WebDAV (rfc3744).
• rfc5995: Cómo usar POST para agregar miembros a colecciones de WebDAV
  • Admite la creación de contactos nuevos sin especificar un ID.
• rfc6352: CardDAV: Extensiones de vCard para la autoría distribuida en la Web y Control de versiones (WebDAV)
  • Admite el método HTTP REPORT, pero no se admiten todos los informes definidos cuando se implementa un plan.
  • Admite proporcionar una colección principal y una de contactos.
• rfc6578: Sincronización de colecciones para WebDAV
  • Las aplicaciones cliente deben cambiar a este modo de funcionamiento después del sincronización inicial.
• rfc6749: El marco de trabajo de autorización de OAuth 2.0 y rfc6750: Marco de trabajo de autorización de OAuth 2.0: uso de tokens del portador
  .
  • Admite la autenticación de programas cliente de CardDAV con OAuth 2.0 HTTP. Autenticación. Google no admite ningún otro método de autenticación. Por seguridad de los datos de contacto, solicitamos conexiones CardDAV para usar HTTPS
• rfc6764: Servicios de localización de extensiones de calendario para WebDAV (CalDAV) y extensiones de vCard para WebDAV (CardDAV)
  • El arranque de las URLs de CardDAV debe ocurrir de acuerdo con la sección 6 de rfc6764
• Admite caldav-ctag-02: Etiqueta de entidad de colección de calendario (CTag) en CalDAV, que se comparte entre las especificaciones CardDAV y CalDAV. Los contactos ctag es como un recurso ETag; cambia cuando algo en el contacto la libreta de direcciones cambió. Esto permite que el programa cliente determine rápidamente que no necesite sincronizar ningún contacto modificado.
• Google utiliza VCard 3.0 como formato de codificación de contactos. Consulta lo siguiente: rfc6350: VCard 3.0

CardDAV de Google requiere OAuth 2.0

La interfaz CardDAV de Google requiere OAuth 2.0. Consulta el vínculo a continuación, donde encontrarás información sobre el uso de OAuth 2.0 para acceder a las APIs de Google:

• Usa OAuth 2.0 para acceder a las APIs de Google
• Uso de OAuth 2.0 para aplicaciones instaladas

Conéctate al servidor CardDAV de Google

El protocolo CardDAV permite el descubrimiento de la libreta de direcciones y los recursos de contacto URIs. No debes codificar ningún URI, ya que podría cambiar en cualquier momento.

Las aplicaciones cliente deben usar HTTPS y la autenticación OAuth 2.0 debe ser proporcionados para la Cuenta de Google del usuario. El servidor CardDAV no autenticar una solicitud, a menos que llegue a través de HTTPS con OAuth 2.0 autenticación de una Cuenta de Google, y tu aplicación se registra en Consola del desarrollador. Cualquier intento de conexión a través de HTTP con la autenticación básica o con un correo electrónico o una contraseña que no coincide con una Cuenta de Google genera una solicitud Código de respuesta de 401 Unauthorized.

Para usar CardDAV, tu programa cliente debe conectarse inicialmente a la canónica de descubrimiento mediante una PROPFIND HTTP en:

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

Una vez que se redireccione (HTTP 301) a un recurso de libreta de direcciones, el programa cliente puedes realizar un PROPFIND para descubrir el DAV:current-user-principal, DAV:principal-URL y addressbook-home-set propiedades. Así, tu programa de clientes puede descubrir la libreta de direcciones principal realizar una PROPFIND en addressbook-home-set y buscar la Recursos addressbook y collection. Una descripción completa de este proceso está fuera del alcance de este documento. Consulta rfc6352 para obtener más detalles.

La ruta de redireccionamiento que se muestra en la respuesta de HTTP 301 a través de una PROPFIND en El URI conocido no se debe almacenar en caché de forma permanente (según rfc6764). Los dispositivos deberían volver a intentar ejecutar la configuración de forma correcta el descubrimiento de URI de forma periódica para verificar si la ruta de acceso almacenada en caché sigue actualizada. volver a sincronizarse si la ruta cambia alguna vez. Google recomienda una tarifa cada 2 o 4 semanas.

Recursos

CardDAV usa conceptos de REST. Las aplicaciones cliente actúan sobre recursos designadas por sus URIs. La estructura actual del URI se especifica aquí para ayudarte a los desarrolladores a comprender los conceptos de la siguiente sección. La estructura puede cambian y no deben codificarse. En su lugar, los recursos deben descubrirse según el RFC.

1. Director
   • https://www.googleapis.com/carddav/v1/principals/userEmail
2. Hogar
   • https://www.googleapis.com/carddav/v1/principals/userEmail/lists
3. Libreta de direcciones
   • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default
4. Contacto
   • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default/contactId

Sincronización de contactos

La siguiente es una descripción general de las operaciones admitidas. Desarrolladores debe buscar los detalles en la RFC relevante. Las solicitudes y respuestas se mayormente codificadas en XML. Estas son las operaciones principales utilizadas por el cliente para la sincronización:

• Cómo usar CTag
  • Los programas cliente usan la solicitud getctag PROPFIND en la libreta de direcciones. recurso para determinar si algún contacto cambió en el servidor y por lo tanto, si es necesaria una sincronización. El valor de esta propiedad se garantiza el cambio si cambia algún contacto. Aplicaciones cliente debe almacenar este valor y usarlo solo en la sincronización inicial y como resguardo cuando se invalida un sync-token. Sondeos periódicos para los La propiedad getctag generará una limitación.
• Cómo usar sync-token
  • Los programas cliente usan la solicitud sync-token PROPFIND en la dirección. Reserva para obtener el objeto sync-token que representa su estado actual. Cliente las aplicaciones deben almacenar este valor y emitir sync-collection de forma periódica REPORT solicitudes para determinar los cambios desde la última emisión sync-token Los tokens emitidos son válidos por 29 días, y REPORT contendrá una sync-token nueva.
• Cómo usar ETags
  • Las aplicaciones cliente emiten una solicitud de PROPFIND de getetag en la dirección Reservar recurso (con el encabezado DEPTH igual a DEPTH_1). Manteniendo el valor ETag de cada contacto, un programa cliente puede solicitar el valor de contactos a los que se les cambió ETag
• Cómo recuperar contactos
  • Las aplicaciones cliente recuperan contactos emitiendo un addressbook-multiget solicitud REPORT. Dada una lista de URIs de contacto, el informe devuelve todos los contactos solicitados como valores de VCard 3.0. Cada incluye un ETag para el contacto.
• Cómo insertar un contacto
  • Las aplicaciones cliente envían una solicitud de POST con el nuevo contacto en VCard 3.0. La respuesta contendrá el ID del contacto nuevo.
• Actualiza un contacto
  • Las aplicaciones cliente envían una solicitud PUT con el contacto actualizado en Formato VCard 3.0. El contacto se actualiza si ya existe. de la libreta de direcciones.
  • Las aplicaciones cliente deben incluir un encabezado If-Match con el el ETag conocido actualmente del contacto. El servidor rechazará PUT solicitud (con HTTP 412) si el ETag actual en el servidor se es diferente de la ETag enviada por el programa cliente. Esto permite que una serialización optimista de actualizaciones.
• Cómo borrar un contacto
  • Las aplicaciones cliente borran un contacto mediante una solicitud de DELETE con el URI del contacto.