Google의 CardDAV 프로토콜을 사용하여 연락처를 보고 관리할 수 있습니다.
연락처가 사용자의 Google 계정에 저장됩니다. 대부분의 Google 서비스에는 연락처 목록에 액세스할 수 없습니다. 클라이언트 애플리케이션은 CardDAV API를 사용하여 새 연락처 만들기, 기존 연락처 수정 또는 삭제, 연락처 쿼리 광고를 게재할 수 있습니다
사양
전체 사양은 구현되지 않았지만 다음과 같은 많은 클라이언트가 구현되어 있습니다. Apple iOSTM 연락처 macOS는 올바르게 상호 운용되어야 합니다.
각 관련 사양에서 Google의 CardDAV 지원은 다음과 같습니다.
- rfc2518: WebDAV (분산 작성을 위한 HTTP 확장 프로그램)
<ph type="x-smartling-placeholder">
- </ph>
- HTTP 메서드
GET
,PUT
,DELETE
,OPTIONS
및PROPFIND
입니다. - HTTP 메서드
LOCK
,UNLOCK
,COPY
,MOVE
또는MKCOL
- 임의의 (사용자 정의) WebDAV 속성은 지원하지 않습니다.
- WebDAV 액세스 제어 (rfc3744)를 지원하지 않습니다.
- HTTP 메서드
- rfc5995: POST를 사용하여 WebDAV 컬렉션에 구성원 추가
<ph type="x-smartling-placeholder">
- </ph>
- ID를 지정하지 않고 새 연락처를 만들 수 있습니다.
- rfc6352: CardDAV: 웹 분산 작성 및 API에 대한 vCard 확장 프로그램
버전 관리 (WebDAV)
<ph type="x-smartling-placeholder">
- </ph>
- HTTP 메서드
REPORT
을(를) 지원하지만 정의된 보고서 중 일부는 지원하지 않습니다. 있습니다. - 주 구성원 컬렉션 및 연락처 컬렉션 제공을 지원합니다.
- HTTP 메서드
- rfc6578: WebDAV를 위한 컬렉션 동기화
<ph type="x-smartling-placeholder">
- </ph>
- 클라이언트 애플리케이션은 초기 동기화
- rfc6749: OAuth 2.0 승인 프레임워크 및
rfc6750: OAuth 2.0 승인 프레임워크: Bearer 토큰 사용
<ph type="x-smartling-placeholder">
- </ph>
- OAuth 2.0 HTTP를 사용한 CardDAV 클라이언트 프로그램 인증 지원 인증. Google은 다른 인증 방법을 지원하지 않습니다. 연락처 데이터 보안을 위해 CardDAV 연결에서는 HTTPS
- rfc6764: WebDAV (CalDAV) 캘린더 확장 프로그램 및 WebDAV (CardDAV) vCard 확장 프로그램용 서비스 찾기
<ph type="x-smartling-placeholder">
- </ph>
- CardDAV URL의 부트스트랩은 rfc6764를 사용합니다.
- 지원
caldav-ctag-02: CalDAV의 캘린더 컬렉션 항목 태그 (CTag)
CardDAV와 CalDAV 사양 간에 공유됩니다. 연락처
ctag
는 리소스ETag
와 같습니다. 연락처의 어떤 항목이든 주소록이 변경되었습니다. 이렇게 하면 클라이언트 프로그램이 따라서 변경된 연락처를 동기화할 필요가 없습니다. - Google은 연락처 인코딩 형식으로 VCard 3.0을 사용합니다. 다음을 참조하세요. rfc6350: VCard 3.0
Google의 CardDAV를 사용하려면 OAuth 2.0이 필요함
Google의 CardDAV 인터페이스에는 OAuth 2.0이 필요합니다. 자세한 내용은 OAuth 2.0을 사용하여 Google API에 액세스하는 방법에 대한 자세한 내용은 아래 문서를 참조하세요.
Google CardDAV 서버에 연결
CardDAV 프로토콜을 사용하면 주소록과 연락처 리소스를 검색할 수 있습니다. URI. URI는 언제든지 변경될 수 있으므로 하드코딩해서는 안 됩니다.
클라이언트 애플리케이션은 HTTPS를 사용해야 하며 OAuth 2.0
인증을 사용해야 합니다.
사용자 Google 계정에 입력합니다. CardDAV 서버는
OAuth 2.0을 사용하여 HTTPS를 통해 도착하지 않는 한 요청을 인증합니다.
Google 계정 인증을 받았으며 애플리케이션이
DevConsole. 기본 인증 또는
이메일/비밀번호가 Google 계정과 일치하지 않으면 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를 참고하세요.
다음 이벤트에서 PROPFIND
을 통해 HTTP 301
응답에 반환된 리디렉션 경로는
잘 알려진 URI는 영구적으로 캐시되어서는 안 되고
rfc6764)를 사용합니다. 기기에서 잘 알려진 기기를 다시 시도해야 함
주기적으로 URI 검색을 통해 캐시된 경로가 여전히 최신 상태인지 확인하고
경로가 변경되면 다시 동기화합니다. 2~4주마다 요금을 부과하는 것이 좋습니다.
리소스
CardDAV는 REST 개념을 사용합니다. 클라이언트 애플리케이션은 리소스 ID입니다. 현재 URI 구조가 여기에 지정되어 있어 다음 섹션의 개념을 이해하고 있어야 합니다. 구조는 하드코딩되어서는 안 됩니다. 오히려 이러한 리소스는 검색되지 않도록 지정할 수 있습니다
- 주 구성원
<ph type="x-smartling-placeholder">
- </ph>
- https://www.googleapis.com/carddav/v1/principals/
userEmail
- https://www.googleapis.com/carddav/v1/principals/
- 홈 세트
<ph type="x-smartling-placeholder">
- </ph>
- https://www.googleapis.com/carddav/v1/principals/
userEmail
/lists
- https://www.googleapis.com/carddav/v1/principals/
- 주소록
<ph type="x-smartling-placeholder">
- </ph>
- https://www.googleapis.com/carddav/v1/principals/
userEmail
/lists/default
- https://www.googleapis.com/carddav/v1/principals/
- 문의
<ph type="x-smartling-placeholder">
- </ph>
- https://www.googleapis.com/carddav/v1/principals/
userEmail
/lists/default/contactId
- https://www.googleapis.com/carddav/v1/principals/
주소록 동기화
다음은 지원되는 작업에 대한 일반적인 설명입니다. 개발자 관련 RFC에서 세부정보를 찾아야 합니다. 요청과 응답은 대부분 XML로 인코딩되어 있습니다. 이것은 클라이언트가 사용하는 기본 작업이며 동기화용 애플리케이션:
- CTag 사용
<ph type="x-smartling-placeholder">
- </ph>
- 클라이언트 프로그램이 주소록에서
getctag
PROPFIND
요청을 사용함 리소스를 확인하여 서버에서 연락처가 변경되었는지 확인하고 따라서 동기화가 필요한지 여부를 파악할 수 있습니다. 이 속성의 값입니다. 연락처가 변경되면 이것도 변경됩니다. 클라이언트 애플리케이션 이 값을 저장하고 초기 동기화 시에만 사용해야 하며sync-token
가 무효화될 때의 대체 동작입니다. 정기적으로getctag
속성이 있으면 제한이 발생합니다.
- 클라이언트 프로그램이 주소록에서
- 동기화 토큰 사용
<ph type="x-smartling-placeholder">
- </ph>
- 클라이언트 프로그램은 주소에
sync-token
PROPFIND
요청을 사용합니다. 현재 상태를 나타내는sync-token
를 가져오도록 예약합니다. 고객 애플리케이션은 이 값을 저장하고 주기적인sync-collection
를 실행해야 합니다. 마지막 요청 이후 변경사항 확인 요청REPORT
건sync-token
입니다. 발급된 토큰은 29일 동안 유효하며REPORT
응답에는 새로운sync-token
가 포함됩니다.
- 클라이언트 프로그램은 주소에
- ETag 사용
<ph type="x-smartling-placeholder">
- </ph>
- 클라이언트 애플리케이션이 주소에 대해
getetag
PROPFIND
요청을 실행합니다. 예약 리소스 (DEPTH
헤더가DEPTH_1
와 같음). 이를 통해 각 연락처의ETag
값이면 클라이언트 프로그램은ETag
이(가) 변경된 연락처 중 개
- 클라이언트 애플리케이션이 주소에 대해
- 연락처 가져오기
<ph type="x-smartling-placeholder">
- </ph>
- 클라이언트 애플리케이션은
addressbook-multiget
REPORT
요청. 연락처 URI 목록이 주어지면 보고서는 요청된 모든 연락처를 VCard 3.0 값으로 반환합니다. 각 항목에는 연락처에 대한ETag
가 포함됩니다.
- 클라이언트 애플리케이션은
- 연락처 삽입하기
<ph type="x-smartling-placeholder">
- </ph>
- 클라이언트 애플리케이션이 VCard의 새 연락처로
POST
요청을 보냅니다. 3.0 형식 응답에는 새 연락처의 ID가 포함됩니다.
- 클라이언트 애플리케이션이 VCard의 새 연락처로
- 연락처 업데이트
<ph type="x-smartling-placeholder">
- </ph>
- 클라이언트 애플리케이션은 업데이트된 연락처로
PUT
요청을 보냅니다. VCard 3.0 형식 연락처가 이미 있는 경우 연락처가 업데이트됩니다. 찾을 수 없습니다. - 클라이언트 애플리케이션에는 다음과 같은
If-Match
헤더가 포함되어야 합니다. 연락처의 현재 알려진ETag
입니다. 그러면 서버에서PUT
를 거부합니다. 서버의 현재ETag
가 다음과 같은 경우 요청 (HTTP 412
포함) 클라이언트 프로그램에서 보낸ETag
와 다릅니다. 이렇게 하면 업데이트의 낙관적 직렬화를 지원합니다.
- 클라이언트 애플리케이션은 업데이트된 연락처로
- 연락처 삭제
<ph type="x-smartling-placeholder">
- </ph>
- 클라이언트 애플리케이션은
DELETE
요청을 실행하여 연락처를 삭제합니다. 연락처 URI와 대조합니다.
- 클라이언트 애플리케이션은