Google Health API에서 데이터를 사용하는 것은 기본적으로 클라우드의 Google Health API 데이터 스토어와 자체 앱 또는 백엔드 데이터 스토어 간에 데이터를 동기화하는 주기입니다. 하지만 이 주기는 다음과 같은 다양한 요인에 따라 다른 형태를 취할 수 있습니다.
- Google Health API에 데이터를 쓰고 있나요? 읽기 전용인가요? 아니면 둘 다인가요?
- 데이터 스토어가 앱 또는 기기에 로컬로 있나요? 아니면 자체 클라우드에 있나요?
- 사용자의 앱과 웨어러블 기기 간에 Google Health API 데이터를 동기화해야 하나요? 기기를 얼마나 자주 동기화하나요?
- 어떤 유형의 데이터로 작업하고 있나요? 기본 개수인가요? 측정 단위인가요? 샘플링 속도가 다른 시리즈인가요?
- 앱이 백그라운드에 있는 동안 데이터를 읽을 계획인가요?
- 앱이 사용자 권한을 받기 전에 기록된 과거 데이터로 작업할 계획인가요?
이 모든 것이 어떻게 연결되는지 알아보려면 Google Health API 동기화 수명 주기를 살펴보세요. 이 수명 주기에는 표준 (읽기 및 쓰기)과 읽기 전용의 두 가지 버전이 있습니다.
표준 동기화 수명 주기
Google Health API와 통합한다는 것은 데이터를 앱 또는 백엔드 데이터 스토어에 복사하는 것을 의미합니다. 이 문서에서 쉽게 사용할 수 있도록 이 데이터 스토어를 개발자 데이터 스토어 라고 합니다.
여기서 '복사'는 Google Health API에서 읽기 (개발자 데이터 스토어에 복사) 또는 Google Health API에 쓰기 (Google Health API에 복사)와 같은 개별 활동을 대체할 수 있습니다. 이러한 작업을 특정 순서로 반복적으로 실행하는 것이 동기화 수명 주기입니다.
그림 1은 앞에서 언급한 요인과 관계없이 읽기 및 쓰기 작업이 포함된 표준 동기화 수명 주기를 보여줍니다.
쓰기
- 쓰기를 위한 새 데이터 준비 : 외부 기기 또는 앱에서 데이터를 전송하고 데이터 포인트를 Google Health API 데이터 유형과 호환되는 JSON 표현으로 형식을 지정합니다. 현재 Health API에서는 쓰기를 위한 맞춤 클라이언트 할당 ID가 지원되지 않습니다. 이러한 ID는
POST에서 제공될 수 있지만 무시됩니다. - 레코드 upsert : REST 엔드포인트를 사용하여 데이터 포인트를 Google Health API에 제출합니다. 레코드를 만들려면
POST를 사용하고 기존 레코드를 삽입하고 업데이트하려면PATCH를 사용합니다.PATCH작업에 필요한 ID는 이전POST작업 (이전 주기의 다음 단계)에서 가져온 것입니다. - 반환된 리소스 ID 처리 : 서버에서 생성된 ID를 사용하는 경우 향후 업데이트 (
PATCH) 또는 삭제 (DELETE)를 사용 설정하려면 서버에서 반환된 리소스name또는 ID를 개발자 데이터 스토어에서 추출하고 유지합니다. 두 가지 유형에 관한 자세한 내용은 식별 전략을 참고하세요.
읽음
- 레코드 읽기 : REST 엔드포인트 (
filter쿼리 매개변수 및pageToken페이지 나누기가 있는GET또는rollUp및dailyRollUp과 같은 집계 엔드포인트)를 사용하여 Google Health API에서 새 데이터와 기존 데이터의 변경사항을 가져오거나 웹훅 구독 (projects.subscribers)을 사용하여 실시간 알림을 수신합니다. 알림은 실제 데이터가 무엇인지가 아니라 새 데이터를 사용할 수 있음을 나타냅니다. - 개발자 데이터 스토어 조정 : 새 데이터와 업데이트된 데이터를 개발자 데이터 스토어에 조정합니다.
그러면 이 주기가 외부 기기 또는 앱의 특정 요구사항에 따라 적절한 간격으로 반복됩니다. 일반적으로 자체 데이터 스토어와 Google Health API 간에 데이터를 동기화할 때 권장되는 순서입니다.
식별 전략
Google Health API에 데이터를 쓰려는 경우 Google Health API와의 통합을 빌드하기 전에 데이터 포인트 (데이터의 기본 단위)를 만들 때 리소스 식별 전략을 선택해야 합니다.
현재 Health API에서는 쓰기를 위한 클라이언트 할당 ID가 지원되지 않습니다.
이러한 ID는 POST에서 제공될 수 있지만 무시됩니다. 이 옵션에 관한 세부정보는 정보 제공 목적으로 여기에 제공됩니다.
- 서버에서 생성된 ID (기본 옵션): 클라이언트가 ID 없이 데이터를 제출하면 Google Health API 백엔드가 고유한 시스템 식별자를 생성하고 반환합니다.
- 클라이언트 할당 맞춤 ID (per AIP-133, 아직 지원되지 않음): 클라이언트 앱이 고유 식별자 (예: UUID 또는 로컬 데이터베이스 기본 키)를 생성하고 생성 시 리소스 경로에 제공합니다.
다음 표에서는 두 식별 전략을 비교하여 통합에 적합한 접근 방식을 선택하는 데 도움을 줍니다.
| 기능 | 서버에서 생성된 ID | 클라이언트 할당 맞춤 ID |
|---|---|---|
| ID 생성 | 서버가 임의의 시스템 ID를 POST
실행 중에 생성합니다. |
클라이언트가 쓰기 전에 로컬에서 안정적인 ID (UUID v4 / 내부 PK)를 생성합니다. |
| 리소스 경로 | .../dataPoints/{server_id} (응답으로 반환됨) |
.../dataPoints/{custom_id} |
| 쓰기 후 로컬 단계 | 필수사항. 향후 업데이트/삭제를 사용 설정하려면 반환된 server_id를 로컬
DB에 저장해야 합니다. |
없음. 앱이 이미 ID를 소유하고 있습니다. |
| ID 매핑 테이블 | 필수사항. 클라이언트는 양방향 매핑
(local_id ↔ server_id)을 유지해야 합니다. |
필요하지 않음. 클라이언트가 자체 기본 키를 직접 사용합니다. |
| 재시도 동작 (약한 네트워크) | 중복 위험. 시간이 초과된 POST
를 재시도하면 새 서버 ID가 있는 중복 레코드가 생성됩니다. |
안전하고 멱등성. 동일한
custom_id로 POST를 재시도하면 중복 생성이 방지됩니다 (409
ALREADY_EXISTS 반환). |
| 오프라인 동기화 지원 | 제한됨. 공식 리소스 ID를 참조하기 전에 서버 응답을 기다려야 합니다. | 전체. 안정적인 ID를 사용하여 오프라인에서 항목을 만들고 변경한 후 다시 연결되면 원활하게 동기화할 수 있습니다. |
| 형식 제약조건 | 서버에서 완전히 처리합니다. | ^[a-z0-9-]{4,63}$ (4~63개의 소문자 영숫자 및 하이픈)을 따라야 합니다. |
| 선택 시기 |
다음과 같은 경우 서버에서 생성된 ID를 선택합니다.
|
다음과 같은 경우 맞춤 ID를 선택합니다.
|
읽기 전용 동기화 수명 주기
Google Health API에서만 읽으려는 앱은 데이터를 개발자 데이터 스토어 에 복사하고 수명 주기의 조정 부분을 처리해야 합니다.
읽기 섹션에서 다룬 동일한 작업이 여기에 적용됩니다.
그림 2는 읽기 전용 수명 주기를 보여줍니다.