CardDAV 프로토콜로 연락처 관리

Google의 CardDAV 프로토콜을 사용하여 연락처를 확인하고 관리할 수 있습니다.

연락처는 사용자의 Google 계정에 저장되며 대부분의 Google 서비스에서 연락처 목록에 액세스할 수 있습니다. 클라이언트 애플리케이션은 CardDAV API를 사용하여 새 연락처를 만들고, 기존 연락처를 수정 또는 삭제하고, 특정 기준과 일치하는 연락처를 쿼리할 수 있습니다.

요건

전체 사양은 구현되지 않았지만 Apple iOSTM 연락처 및 macOS와 같은 많은 클라이언트는 올바르게 상호 운용되어야 합니다.

각 관련 사양에 대해 Google의 CardDAV 지원은 다음과 같습니다.

Google의 CardDAV에는 OAuth 2.0이 필요합니다.

Google의 CardDAV 인터페이스에는 OAuth 2.0이 필요합니다. OAuth 2.0을 사용하여 Google API에 액세스하는 방법은 아래 링크된 문서를 참고하세요.

Google의 CardDAV 서버에 연결

CardDAV 프로토콜을 사용하면 주소록 및 연락처 리소스 URI를 검색할 수 있습니다. URI는 언제든지 변경될 수 있으므로 하드 코딩해서는 안 됩니다.

클라이언트 애플리케이션은 HTTPS를 사용해야 하며, 사용자의 Google 계정에 OAuth 2.0 인증을 제공해야 합니다. Google 계정의 OAuth 2.0 인증을 사용하여 HTTPS를 통해 도착하지 않고 애플리케이션이 DevConsole에 등록되지 않은 경우 CardDAV 서버는 요청을 인증하지 않습니다. 기본 인증 또는 Google 계정과 일치하지 않는 이메일/비밀번호로 HTTP를 통해 연결을 시도하면 HTTP 401 Unauthorized 응답 코드가 반환됩니다.

CardDAV를 사용하려면 먼저 다음에 대해 HTTP PROPFIND를 실행하여 클라이언트 프로그램이 표준 검색 경로에 연결해야 합니다.

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

주소록 리소스로 리디렉션(HTTP 301)되면 클라이언트 프로그램이 여기서 PROPFIND를 실행하여 DAV:current-user-principal, DAV:principal-URL, addressbook-home-set 속성을 검색할 수 있습니다. 그러면 클라이언트 프로그램이 addressbook-home-set에서 PROPFIND를 실행하고 addressbook 및 collection 리소스를 찾아 주 주소록을 검색할 수 있습니다. 이 프로세스에 대한 자세한 설명은 이 문서의 범위를 벗어납니다. 자세한 내용은 rfc6352를 참고하세요.

잘 알려진 URI의 PROPFIND를 통해 HTTP 301 응답에 반환된 리디렉션 경로는 영구적으로 캐시되면 안 됩니다 (rfc6764에 따라). 기기는 잘 알려진 URI 검색을 주기적으로 재시도하여 캐시된 경로가 여전히 최신 상태인지 확인하고 경로가 변경되면 다시 동기화해야 합니다. 2~4주마다 요율을 적용하시기 바랍니다.

자료

CardDAV는 REST 개념을 사용합니다. 클라이언트 애플리케이션은 URI에 의해 지정된 리소스를 대상으로 작동합니다. 현재 URI 구조가 여기에 지정되어 있어 개발자가 다음 섹션의 개념을 이해하는 데 도움이 됩니다. 구조는 변경될 수 있으며 하드코딩해서는 안 됩니다. 대신 RFC에 따라 리소스를 검색해야 합니다.

  1. 주 구성원
    • https://www.googleapis.com/carddav/v1/principals/userEmail
  2. 홈 세트
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists
  3. 주소록
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default
  4. 문의
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default/contactId

연락처 동기화

다음은 지원되는 작업에 대한 일반적인 설명입니다. 개발자는 관련 RFC에서 세부정보를 찾아야 합니다. 요청 및 응답은 대부분 XML로 인코딩됩니다. 다음은 클라이언트 애플리케이션에서 동기화를 위해 사용하는 기본 작업입니다.

  • CTag 사용
    • 클라이언트 프로그램은 주소록 리소스에서 getctag PROPFIND 요청을 사용하여 서버에서 연락처가 변경되었는지, 따라서 동기화가 필요한지 판단합니다. 연락처가 변경되면 이 속성의 값이 변경됩니다. 클라이언트 애플리케이션은 이 값을 저장하고 sync-token를 무효화할 때 초기 동기화 시에만 대체 방법으로 사용해야 합니다. getctag 속성을 주기적으로 폴링하면 제한이 발생합니다.
  • sync-token 사용
    • 클라이언트 프로그램은 주소록에 sync-token PROPFIND 요청을 사용하여 현재 상태를 나타내는 sync-token를 가져옵니다. 클라이언트 애플리케이션은 이 값을 저장하고 정기적인 sync-collection REPORT 요청을 실행하여 마지막 발급 sync-token 이후의 변경사항을 확인해야 합니다. 발급된 토큰은 29일 동안 유효하며 REPORT 응답에 새 sync-token이 포함됩니다.
  • ETag 사용
    • 클라이언트 애플리케이션은 주소록 리소스 (DEPTH 헤더가 DEPTH_1와 같음)에서 getetag PROPFIND 요청을 실행합니다. 각 연락처의 ETag 값을 유지하면 클라이언트 프로그램이 ETag가 변경된 연락처 값을 요청할 수 있습니다.
  • 연락처 검색
    • 클라이언트 애플리케이션은 addressbook-multiget REPORT 요청을 실행하여 연락처를 검색합니다. 보고서는 연락처 URI 목록을 고려하여 요청된 모든 연락처를 VCard 3.0 값으로 반환합니다. 각 항목에는 연락처의 ETag가 포함됩니다.
  • 연락처 삽입
    • 클라이언트 애플리케이션은 VCard 3.0 형식의 새 연락처와 함께 POST 요청을 실행합니다. 응답에는 새 연락처의 ID가 포함됩니다.
  • 연락처 업데이트하기
    • 클라이언트 애플리케이션은 업데이트된 연락처와 함께 VCard 3.0 형식으로 PUT 요청을 실행합니다. 연락처가 이미 주소록에 있는 경우 연락처가 업데이트됩니다.
    • 클라이언트 애플리케이션에는 연락처의 현재 알려진 ETag가 있는 If-Match 헤더가 포함되어야 합니다. 그러면 서버의 현재 ETag가 클라이언트 프로그램이 보낸 ETag와 다른 경우 서버는 PUT 요청을 HTTP 412로 거부합니다. 이렇게 하면 낙관적 업데이트 직렬화가 가능합니다.
  • 연락처 삭제
    • 클라이언트 애플리케이션은 연락처 URI에 대해 DELETE 요청을 실행하여 연락처를 삭제합니다.